Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
次世代のログ基盤 Grafana Lokiを始めよう! / prometheus-meetup...
Search
uesyn
January 15, 2020
Technology
15k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
次世代のログ基盤 Grafana Lokiを始めよう! / prometheus-meetup-tokyo-3-lets-start-the-loki
uesyn
January 15, 2020
More Decks by uesyn
See All by uesyn
PodSecurityPolicyの安全な移行の道のり / On the safe migration of PodSecurityPolicy
uesyn
1
1.2k
PodSecurityPolicyの廃止に備えて、 一足先にPodSecurity Admissionを試してみよう! / from-psp-to-podsecurity
uesyn
4
1.9k
Kubernetes v1.19 変更点調査のまとめ / k8s-v119-updates
uesyn
1
300
そのクラスタ本当にアップグレードして大丈夫? Storage Version の更新も忘れずにしよう! / k8s-storage-version-migration
uesyn
2
4k
kindでも"type LoadBalancer"を使いたい! / kubernetes-meetup-tokyo-24-kind-with-type-loadbalancer
uesyn
0
1.8k
Loki入門
uesyn
8
2.8k
Cortexの話をKubeConで聞きたかったっていう話
uesyn
4
2.1k
kubernetesでGPUを 管理するために スケジューラをいじってみた
uesyn
2
3k
Other Decks in Technology
See All in Technology
インフラと開発の垣根を超えていき!〜元AWSインフラエンジニアがAWS開発で奮闘している話〜
hatahata021
3
300
SoccerMaster: A Vision Foundation Model for Soccer Understanding
kzykmyzw
0
150
Amplify Gen2でbackend.tsにCDKを定義する/しない事によるCDKの挙動の違いとユースケース
smt7174
1
420
マルチアカウント環境でSecurity Hubの運用、その後どうなった? / SRE NEXT 2026 miniLT会
genda
0
110
OpenTelemetryにおけるGoのゼロコード・コンパイル時計装について #fukuokago
quiver
0
120
Playwright × AI Agent でE2Eテストはどう変わるか AI駆動テストの可能性と実用検証の結果
taiga7543
1
440
変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則
kawauso
0
210
AmplifyHostingConstructからSSRフレームワークのためのホスティング設計を考察する/amplify-hosting-construct
fossamagna
1
240
企業でAWS Organizationsを動かすための組織設計の考え方
nrinetcom
PRO
1
110
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
670
世界、断片、モデル。そして理解
ardbeg1958
1
130
ゴールデンパスは敷いただけでは道にならない ─ 企画部門のエンジニアが技術標準を事業価値に変えるまで
mhrtech
1
230
Featured
See All Featured
For a Future-Friendly Web
brad_frost
183
10k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Side Projects
sachag
455
43k
Building AI with AI
inesmontani
PRO
1
1.1k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
190
We Are The Robots
honzajavorek
0
280
A designer walks into a library…
pauljervisheath
211
24k
Navigating Weather and Climate Data
rabernat
0
380
Agile that works and the tools we love
rasmusluckow
331
22k
Between Models and Reality
mayunak
4
370
Transcript
次世代のログ基盤 Grafana Loki を始めよう! Loki : @uesyn Promtail: @kameneko1004
Profile 上村 真也 • 所属: ゼットラボ株式会社 • Twitter: @uesyn •
今回からこのMeetupの運営へ入りました
ゼットラボ株式会社 / Z Lab Corporation • 2015年に設立されたヤフー株式会社の100%子会社 • ヤフーのインフラ課題に対して R&D
でソリューション提供 • Kubernetes as a Service を開発・提供
Lokiとは? • Log Aggregation System ◦ Horizontally-Scalable ◦ Highly-Available ◦
Multi-tenant • Grafana Labsが主体となって開発 ◦ Grafana連携 • OSS ◦ https://github.com/grafana/loki ◦ 最新はv1.2.0(2020/1/14時点)
デモ 動かなかったら この動画再生します https://www.youtube.com/watch?time_continue=5&v=7n342UsAMo0
Lokiについて • Like Prometheus, but for logs ◦ ログ検索には以下のように行う ▪
ログに付与されたラベルによるフィルタリング ▪ さらに結果をgrepのように絞り込み • ログをシンプルに扱う ◦ ログを保存時する時、形態素解析のようなテキスト処理はしない ◦ Prometheusのようにラベルを付与してログを保存
Lokiを動かす https://github.com/grafana/loki/blob/master/production/README.md#running-loki
Lokiの概要 Ω Promtail App Log Service Discovery Systemd Journal Node
ラベル+ログ Log Log Cortexっぽい アーキテクチャ Prometheusっぽい コンフィグ Label + Logを送信
Ω Lokiの概要 Promtail App Log Service Discovery Systemd Journal Node
ラベル+ログ Log Log Cortexっぽい アーキテクチャ Prometheusっぽい コンフィグ 前半パート(@uesyn) 後半パート(@kameneko1004) Label + Logを送信
Grafana loki
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients • 受信したログをIngesterへ送信 • 冗長化構成の時は複数のIngesterへ • どのIngesterへ送信するかはConsul(or etcd)を参照 Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients • ログを永続ストレージへ保存 • Ingester毎に受け付けるログが決まっている ◦ Consul(or etcd)に情報を保持 • セミステートフルなコンポーネント ◦ 直近のログを持つ Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients • IndexとChunkの2種類のストレージ ◦ 外部(または内部)のストレージを利用 Consul or etcd
Chunk Storeの補足 • loki自体はDBではない • 2種類のChunk Store ◦ Index: ログ検索のための転置インデックス
◦ Chunk: 実際のログを保持 • 利用可能なDB Index ◦ Local ◦ DynamoDB ◦ Bigtable ◦ Cassandra Chunk ◦ Local ◦ Cloud Storage ◦ S3 Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients • ログの検索に応じる • IngesterやChunk Storeからログを取得 Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients • 保存するログのretentionを管理 • 一部Chunk Storeには非対応 Consul or etcd
lokiのアーキテクチャ • ほぼCortexのアーキテクチャ ◦ https://github.com/cortexproject/cortex • 主なコンポーネント ◦ Distributor ◦
Ingester ◦ Chunk Store ◦ Querier ◦ Table Manager Distributor Ingester Querier Chunk Store (Index) Chunk Store (Chunks) Promtail Table Manager fluentd その他 Clients Consul or etcd
lokiのコンポーネントについて • 様々なコンポーネントがあるが、全て同一の実行バイナリ ◦ シングルプロセスで全てのコンポーネントを動かすことも可能
Lokiとは? • Log Aggregation System ◦ Horizontally-Scalable ◦ Highly-Available ◦
Multi-tenant • Grafana Labsが主体となって開発 ◦ Grafana連携 • OSS ◦ https://github.com/grafana/loki ◦ 最新はv1.2.0(2019/1/14時点) 再掲
マルチテナント • テナントを識別するHTTPヘッダを付与することで実現 ◦ X-Scope-OrgID: <tenant ID> • Loki自体にテナントの認証の仕組みは含まれていない ◦
Nginx + Basic AuthやOAuth2 Proxyのようなリバースプロキシを用意する必要がある ◦ 上記のヘッダは認証リバースプロキシでセットされるべき(と書いてありました) Reverse Proxy Promtail Distributor Ingester Querier
Lokiとは? • Log Aggregation System ◦ Horizontally-Scalable ◦ Highly-Available ◦
Multi-tenant • Grafana Labsが主体となって開発 ◦ Grafana連携 • OSS ◦ https://github.com/grafana/loki ◦ 最新はv1.2.0(2019/1/14時点) 再掲
Grafanaからログの検索 • ExploreでデータソースをLokiに指定すると利用可能
Grafana連携~ダッシュボードでログを表示~ • Log Panelが Grafana v6.4+ で利用可能 ◦ document: https://grafana.com/docs/grafana/latest/features/panels/logs/
Grafana連携~Automatic Annotations~ • ログを動的にPanelへAnnotationとして付与可能 https://grafana.com/blog/2019/12/09/how-to-do-automatic-annotations-with-grafana-and-loki/
かめねこ SAKURA internet Inc. Evangelist, Infrastracture @kameneko1004
Promtailとは?
https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/
https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/ これ
Promtailとは? • 各Node上でPodなどのログを収集するエージェント • Kubernetes以外やコンテナ以外もOK
Promtailとは? 特徴 Like Prometheus, but for logs.
Promtailとは? Like Prometheus, but for logs. ScrapeConfigs Relabeling 特徴 ServiceDiscovery
Promtailとは? Like Prometheus, but for logs. ScrapeConfigs Relabeling Prometheusのノウハウがそのまま使える 特徴
ServiceDiscovery
Promtailとは? 役割 1. ターゲットからログを収集してLokiに転送 2. ログからアラートを生成
1. ターゲットからログを収集してLokiに転送
1. ターゲットからログを収集してLokiに転送 promtail.yaml
promtail.yaml • ServiceDiscovery で自動的にターゲットのログを追跡 ◦ ScrapeConfigs で定義 • Relabeling でログストリームにラベルを付与する
promtail.yaml server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients:
- url: http://localhost:3100/loki /api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log
promtail.yaml server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients:
- url: http://localhost:3100/loki /api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log Promtail本体に関する設定
promtail.yaml server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients:
- url: http://localhost:3100/loki /api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log Positionファイルに関する設定
promtail.yaml server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients:
- url: http://localhost:3100/loki /api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log Lokiのインスタンスへの 接続に関する設定
promtail.yaml server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients:
- url: http://localhost:3100/loki /api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log ターゲットの検出に関する設定
scrape_configs: scrape_configs: - job_name: system static_configs: - targets: - localhost
labels: job: varlogs __path__: /var/log/*log もっともシンプルな構成
scrape_configs: scrape_configs: - job_name: system static_configs: - targets: - localhost
labels: job: varlogs __path__: /var/log/*log もっともシンプルな構成 __path__に指定したパスを参照する localhost の /var/log/*log な ログをスクレイプ
scrape_configs: scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod ServiceDiscovery
も当然利用可能
scrape_configs: scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs:
- source_labels: - __meta_kubernetes_pod_label_app target_label: app - source_labels: - __meta_kubernetes_pod_node_name target_label: hostname relabel_configs でラベルを加工
scrape_configs: scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs:
- source_labels: - __meta_kubernetes_pod_uid - __meta_kubernetes_pod_container_name replacement:/var/log/pods/*$1/*.log separator: / target_label: __path__ PodのUIDやコンテナ名から ログファイルをスクレイプ
ログからアラートを生成
ログからアラートを生成 • pipeline_stages • 取得したログの値を加工・参照する ◦ LogLevel をラベルのValueに ◦ HTTPのステータスコードを
ラベルのValueに pipeline_stages - match: selector: '{name="jaeger-agent"}' stages: - json: expressions: level: level components: components - labels: level: components:
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1 selector で元となるログを指定 → LogQuery
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1 各Stageごとに加工を行う
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1 regex: ログストリームに対して正規表現で値を取得
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 regex: ログストリームに対して正規表現で値を取得
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 level を参照して…
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 かっこ内の正規表現に一致する値を 変数 <level> に格納
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 ts を参照して…
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 かっこ内の正規表現に一致する値を 変数 <timestamp> に格納
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1 label: 変数の値はラベルに置換可能
# 正規表現 expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' # ログ level=info ts=2020-01-14T23:44:05.12674019Z caller=tailer.go:77 component=tailer
msg="start tailing file" path=/var/log/pods/monitoring_prometheus-k8s-0_a993e0a4-e7a2-44bb-8716-c92d4 d24a1e5/prometheus-config-reloader/0.log 例1 label: level=info timestamp=2020-01-14T2… が格納される
- job_name: kubernetes-pods-name kubernetes_sd_configs: .... pipeline_stages: - match: selector: '{name="promtail"}'
stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*)' - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp 例1 timestamp: 指定の方法でタイムスタンプを指定
- match: selector: '{name="sample-app"}' stages: - json: expressions: remote: remote_ip
status: status - labels: remote: status: 例2
- match: selector: '{name="sample-app"}' stages: - json: expressions: remote: remote_ip
status: status - labels: remote: status: 例2 正規表現以外にも、 - json - docker - cri などを指定可能
- match: selector: '{name="sample-app"}' stages: - json: expressions: remote: remote_ip
status: status - labels: remote: status: {"time":"2020-01-15T09:33:38.375111489Z","id":"","remote_ip":"10.42.29.199","host" :"10.42.38.19:8080","method":"GET","uri":"/health","user_agent":"Go-http-client/1. 1","status":200,"error":"","latency":42187,"latency_human":"42.187 µs","bytes_in":0,"bytes_out":2} 例2 json であれば、 ログ上のKeyを直接指定可能
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 ‘panic’ が含まれるログを抽出
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 metrics: カスタムメトリクスを定義
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 メトリクス名
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 メトリクスのタイプ
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 説明
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 メトリクスを変化させる 変数を指定
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 対象の変数にマッチしたら 行うアクションを指定 ← inc: インクリメント
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 promtail/metricsで ‘promtail_custom_’ から始まる メトリクスが生成される
- match: selector: '{app="some-app"} != "info"' stages: - regex: expression:
".*(?P<panic>panic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc 例3 promtail/metricsで ‘promtail_custom_’ から始まる メトリクスが生成される promtail_custom_panic_total
カスタムメトリクスを元にアラート • Prometheusから [promtail-host]:3101/metrics をスクレイプする • スクレイプしたメトリクスを元に、アラートを生成する
DEMO 可能であれば…( ˘ω˘)
ドキュメント https://github.com/grafana/loki/tree/master/docs/clients/promtail
Thank you! Let’s Logging.