Grafana Loki ではじめる Kubernetes ロギング ハンズオン / Grafana Loki getting started

NTT Tech Conference #4
「Grafana Loki ではじめる Kubernetes ロギング ハンズオン」のスライド資料です

Transcript

1. [Hands on – C4] Grafana Loki ではじめる Kubernetes ロギング ハンズオン Masahiko Utsunomiya 2020/1/31 NTT Tech Conference #4
2. 1 #NTTtech https://bit.ly/38w7r9U 掲載内容は個人の見解であり、 所属する企業や組織の立場、戦略、意見を 代表するものではありません
3. 2 #NTTtech https://bit.ly/38w7r9U Whois ✓ 金融分野のお客様のクラウド導入支援 ✓ 興味：Observability（Prometheus, Fluentd, Loki, Jaeger, etc.） ✓ Grafana Loki コントリビュータ Helm Chart のメンテナンスなどしています polar3130 Masahiko Utsunomiya Infrastructure Engineer / Relationship Builder NTT DATA Corporation
4. 3 #NTTtech https://bit.ly/38w7r9U 制作に参加した書籍がでました “Kubernetes ポケットリファレンス” ISBN : 978-4-297-10957-8 2019/11/16発売 技術評論社より 主にレビュアとして参加、 本編・コラムの一部執筆も担当させて頂きました
5. 4 #NTTtech https://bit.ly/38w7r9U Agenda ⚫ 環境構築 ⚫ Observability とは ⚫ Cloud Native における Observability ⚫ ロギングの目的と課題 ⚫ Grafana Loki 入門 ⚫ ハンズオン ＆ 解説：基本構成と LogQL 基礎 ⚫ Appendix
6. 5 #NTTtech https://bit.ly/38w7r9U チュートリアルはこちらから bit.ly/38w7r9U https://github.com/polar3130/grafana-loki-getting-started
7. Observabilityとは
8. 7 #NTTtech https://bit.ly/38w7r9U 単語から捉える Observability（可観測性） 観測に関して“ある”能力を備えている ということ Observability
9. 8 #NTTtech https://bit.ly/38w7r9U 語源から捉える Observability（可観測性） 本来、Observability は制御工学の用語 システムの外部出力の観測に基づき、内部状態を推測可能であることを示す “On the General Theory of Control Systems”(R. E. KALMAN, 1960) が初出とされる * https://www.sciencedirect.com/science/article/pii/S1474667017700948
10. 9 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native Definition にそう書いてあるから...？ * https://github.com/cncf/toc/blob/master/DEFINITION.md
11. 10 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native Definition にそう書いてあるから...？ * https://github.com/cncf/toc/blob/master/DEFINITION.md
12. 11 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native な環境においては、 「いまシステムで何が起きていて、サービスにどう影響しているか把握できること」 「事象の原因を素早く特定するために必要な情報に的確にアクセスできること」 が、従来のモニタリングの仕組み/方法論だけでは実現できないから なぜ実現できないのか？その背景には 「なぜモニタリングという行為が必要とされてきたのか」、そして 「アーキテクチャの変化」がある
13. 12 #NTTtech https://bit.ly/38w7r9U そもそもなぜモニタリングをするのか
14. 13 #NTTtech https://bit.ly/38w7r9U モニタリングの目的 システムの信頼性を確保すること システムは期待どおりに動いているか、でなければ何が起きているのか、何が原因なのかを知りたい ロールによって見るべき値や計測の手段は異なるが、 それぞれのものさしで信頼性を測るためにモニタリングは行われる ・Dev の場合 例えば、アプリケーションが正常に動作しているか、期待される UX が提供できているか ・Sec の場合 例えば、システムが健常性を維持しているか、脅威が発生すればそれを迅速に特定できるか ・Ops の場合 例えば、クラウドインフラ、CI/CD、プラットフォームが正常に動作しているか 参考：https://assets.sumologic.jp/resources/brief/kubernetes_observability_ebook.pdf
15. 14 #NTTtech https://bit.ly/38w7r9U アーキテクチャの変化 Cloud Native な環境では、徹底した自動化や、プラットフォームの持つ 回復性などにより、システムは動的かつ頻繁に変化するようになる 常に変化し続ける環境では、これまでのモニタリングの考え方だけで 「いまシステムで何が起きていて、サービスにどう影響しているか把握」したり、 「事象の原因を素早く特定するために必要な情報に的確にアクセス」することは 非常に困難
16. 15 #NTTtech https://bit.ly/38w7r9U Cloud Native における Observability とは システムの信頼性を 継続的に証明できる能力/性質 モニタリング対象が動的に変化し続けるなら、 システムはその変化に伴って信頼性を証明し 続けられる必要がある よって、Observability には自動化されたテストと 継続的なモニタリングの改善が不可欠 証明に用いる代表的な 3 つの要素として、 Metrics, Tracing, Logging がある Metrics Tracing Logging request-scoped metrics aggregatable events volume request-scoped events request-scoped, aggregatable events 参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
17. 16 #NTTtech https://bit.ly/38w7r9U 補足：Observability の定義は人によって異なる？ how で捉えると、そうとも言える 信頼性を証明するための尺度がロールや環境によって異なるから なので人によって Profiling を含んだり、Service Mesh を含んだり、Visualization を含んだりする 根底にある目的が「信頼性の継続的な確保」ということに変わりはない 参考：https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431
18. 17 #NTTtech https://bit.ly/38w7r9U チュートリアルを再開します
19. 18 #NTTtech https://bit.ly/38w7r9U Cloud Native な環境の特性 ✓ “インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行う” - CNCF Cloud Native Definition v1.0 * より ✓ “回復性、管理力、および可観測性のある疎結合システム” - Cloud Native な環境には Observability（可観測性）が必要 ✓ “アプローチの代表例に、コンテナ、サービスメッシュ、マイクロ サービス、イミュータブルインフラストラクチャ、および宣言型API” - Kubernetes はそのアプローチを実現する代表的な技術のひとつ *：https://github.com/cncf/toc/blob/master/DEFINITION.md
20. 19 #NTTtech https://bit.ly/38w7r9U Cloud Native における Observability（再掲） システムの信頼性を 継続的に証明できる能力/性質 モニタリング対象が動的に変化し続けるなら、 システムはその変化に伴って信頼性を証明し 続けられる必要がある よって、Observability には自動化されたテストと 継続的なモニタリングの改善が不可欠 証明に用いる代表的な 3 つの要素として、 Metrics, Tracing, Logging がある Metrics Tracing Logging request-scoped metrics aggregatable events volume request-scoped events request-scoped, aggregatable events 参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
21. 20 #NTTtech https://bit.ly/38w7r9U ロギングの目的 改変できない、されていないと 証明できることが必要 プロセスの透明性が重視される 何らかのアクティビティの 証跡となるもの 軽量性、高可用性が必要 できるだけ多くの生ログと、 簡便なgrepツールが求められる Grafana Loki が得意とする領域 Logging 短期的目線 長期的目線 監査・実績管理 傾向分析・予測 複雑な二次加工が必要（傾向） 多角的な集計・フィルタリング ができるツールが求められる EFK や Splunk が得意とする領域 全文検索を可能にするため、 メタデータが膨大になる傾向あり デバッグ 傾向分析・予測 複雑な二次加工が必要（傾向） 多角的な集計・フィルタリング ができるツールが求められる EFK や Splunk が得意とする領域 全文検索を可能にするため、 メタデータが膨大になる傾向あり
22. 21 #NTTtech https://bit.ly/38w7r9U デバッグにおける Observability Logging Metrics Tracing ! Alert Fix Dashboard Adhoc Query Log Aggregation Distributed Tracing lead-time メトリクス、ログ、トレース情報を別々に、 ただ取っておくだけでは不十分 参照したテレメトリから、 別のテレメトリへ移る際のコンテキストを 可能な限り維持したい 例えば、アドホックに抽出したメトリクスと 関連するログを、即座に特定できれば… 動的に変化する環境のデバッグでは特に テレメトリ間の関連性を 見失わないことが重要 参考：https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/
23. 22 #NTTtech https://bit.ly/38w7r9U Kubernetes のロギング ノードレベル いつもの ” kubectl logs … ” コンテナのI/Oの基本は stdout / stderr であり、コンテナ / ポッド / ノードが落ちるとログを見失う クラスタレベル Kubernetes 自体はクラスタレベルのロギングソリューションを提供していない デザインパターンは大別して3種類 * エージェントをサイドカーで配置 エージェントをノード単位で配置 アプリケーションから直接公開 *：https://kubernetes.io/docs/concepts/cluster-administration/logging/
24. 23 #NTTtech https://bit.ly/38w7r9U 既存のデバッグ用途クラスタレベルロギングツール Easy to use いずれも Viewer に特化しており、ログの収集・蓄積は行わない 多くは Kubernetesリソースベースの検索に限定されている kail ：https://github.com/boz/kail stern：https://github.com/wercker/stern Kubetail ：https://github.com/johanhaleby/kubetail
25. 24 #NTTtech https://bit.ly/38w7r9U Kubernetes のロギングにおける課題 ログは Observability の3要素の中で最もデータ量が多い が、個々が独立したイベントであるため間引くことができない かと言ってデバッグのためにはログ出力を絞りたくもない、大量のログを軽量に扱いたい スケーリングと操作が簡単であってほしい 難解なクエリを書いたり、重厚なログ管理インフラを整備する必要なく、 監視対象の柔軟性に応じて容易に拡張でき、かつクラスタレベルでログを簡単にgrepしたい メトリクスとログの関連性を見つけ出したい メトリクスに関連するログを容易に抽出できる仕組みが欲しい 既存のクラスタレベルログビューアではログを収集しないためメタデータは付与できない
26. Grafana Loki 入門 基本構成と LogQL 基礎
27. 26 #NTTtech https://bit.ly/38w7r9U • 圧縮された非構造化ログとメタデータのインデックスのみを扱うことで軽量に動作 • Prometheusにインスパイアされた設計： 時系列データベース、サービスディスカバリ、ラベルによる多次元データモデル • 水平スケーラビリティ、高可用性、マルチテナンシーをデフォルトで組み込み Grafana Labs が開発している OSS のロギングツール（以降、Lokiと記載） - latest: v1.3.0 - KubeCon NA 2018 で発表、翌年同イベントでGA - Go 言語で開発 like Prometheus, but for logs. Grafana Loki とは https://github.com/grafana/loki
28. 27 #NTTtech https://bit.ly/38w7r9U Loki ベースのロギングスタック 基本形は以下の3つのコンポーネントで構成 Promtail：自身のノード上のログファイルを検出し、ラベルに基づき Loki に転送する Loki：クライアントから受け取ったログにインデックスを付与し、保管する Grafana：Loki をネイティブサポートしている時系列データ可視化ツール（v6.0 以降が必要） Grafana Loki Daemonset で展開するのが基本だが サイドカーとして Pod 内に展開も可能 (target) Promtail
29. 28 #NTTtech https://bit.ly/38w7r9U Grafana を用いたログ検索（ Explore ） コンテキストに応じた ラベルを選択し、 grep感覚でフィルタリング Loki は 単一行のログのみを扱う ログ検索の基本形 Grafana Loki Promtail (target)
30. 29 #NTTtech https://bit.ly/38w7r9U Grafana を用いたログ検索（ Explore ） コンテキスト検索 本当に欲しい情報は、 特定したログ行の前後に 存在する場合がある “ grep -A/B/C ” オプション の発想を Loki + Grafana で 実装したもの Grafana Loki Promtail (target)
31. 30 #NTTtech https://bit.ly/38w7r9U LogQL：Log Query Language ストリームセレクタとフィルタ式でログを抽出する独自のクエリ言語 Prometheus のクエリ言語である PromQL を参考に設計されている ストリームセレクタ フィルタ式 条件に合致するログを 時系列で出力 { job=“mysql“ } |= "error" != "timeout" ラベルを指定して grep grep |= ログが指定文字列を含む != ログが指定文字列を含まない |~ ログが正規表現に合致する !~ ログが正規表現に合致しない = 合致 != 合致しない（否定） =~ 正規表現で合致 !~ 正規表現で合致しない
32. 31 #NTTtech https://bit.ly/38w7r9U ラベルベースのインデックス付与 ラベルセット単位でログデータのチャンクを作成し、インデックスを付与する 全文インデックスを作成しないことで、メタデータの量が非常に少なく済む { application = “alpha”, level = “error” } “ component A is not available ” { application = “alpha”, level = “error” } “ component B is not available ” { application = “alpha”, level = “info” } “ service Alpha is restarted ” StreamID : 2abb13… StreamID : b4f788… chunk chunk StreamID : 2abb13… index index Grafana Loki Promtail (target)
33. 32 #NTTtech https://bit.ly/38w7r9U source_labels 参考：Promtail のロギングターゲット検出 Prometheus と同様の仕組みでターゲットの動的検出が可能 各 Promtail は同一ホスト上の Pod のみ検出可能、利用する際は “__host__” ラベルの設定が必要 discover B __host__：B discover A __host__：A relabel_configs: - source_labels: ['__meta_kubernetes_pod_node_name'] target_label: '__host__' Promtail Promtail
34. 33 #NTTtech https://bit.ly/38w7r9U チュートリアルを再開します
35. 34 #NTTtech https://bit.ly/38w7r9U ログのメトリクスを可視化する ログの量・頻度を 捉える Loki v0.4 で追加された機能 現状は、ログデータソースと メトリクスデータソースで 同一の Loki を別途登録する 必要がある （Grafana v6.6 で解消予定） Grafana Loki Promtail (target)
36. 35 #NTTtech https://bit.ly/38w7r9U Range Vector セレクタとアグリゲーション Prometheus のPromQLと同様に、Range Vector でアグリゲーションが可能 現在サポートされているクエリは2種類 rate：秒あたりのエントリの割合 count_over_time：レンジ内の各ログストリームのエントリ数 さらに以下のオペレータを使ってログのグルーピングも可能 sum：合計値 min ：最大値 max：最小値 avg：平均値 etc. sum ( count_over_time ( { job="mysql“ } [5m] ) ) by ( level ) 直近5分における MySQLジョブの level別ログ行数
37. 36 #NTTtech https://bit.ly/38w7r9U “Like Prometheus” ? Loki は Prometheus と多くの共通点を持つ Prometheus Loki 多次元データモデル 共通点 相違点 Pull型 Push型 収集方式 動的ラベル付与の仕組み サービスディスカバリ Grafanaでネイティブサポート 時系列データを扱う 単一バイナリ メトリクス ログ 収集対象
38. 37 #NTTtech https://bit.ly/38w7r9U スイッチングコストの低減 Prometheusとのコンポーネント共通化により、 コンテキストを維持しながらメトリクスとログを切り替えられる Promtail のターゲット検出やラベル付与の仕組みは Prometheus と同様の文法で記述する 同じ設定を使ってメトリクスとログに一貫性のあるメタデータ付与ができる Logging Metrics Adhoc Query Log Aggregation app production v1 relabel_config service discovery 本番環境のapp v1 に関するメトリクス 本番環境のapp v1 に関するログ app production v1
39. Appendix
40. 39 #NTTtech https://bit.ly/38w7r9U LogCLI を用いた分析 Loki プロジェクトで提供している CLI のクエリツール ターミナル上でクラスタレベルのログをgrepしたい、といった場合に手軽に使える $ logcli query '{job="cortex-ops/consul"}’ https://logs-dev-ops-tools1.grafana.net/api/prom/query?query=%7Bjob%3D%22cortex-ops... Common labels: {job="cortex-ops/consul", namespace="cortex-ops"} 2018-06-25T12:52:09Z {instance="consul-8576459955-pl75w"} 2018/06/25 12:52:09 [INFO] ... 2018-06-25T12:52:09Z {instance="consul-8576459955-pl75w"} 2018/06/25 12:52:09 [INFO] ... ・・・ クエリの内容 共通のラベル 抽出したログ LogCLI Loki Promtail (target)
41. 40 #NTTtech https://bit.ly/38w7r9U Grafana を用いたログの可視化（ Dashboard ） ログもメトリクスも 1枚の Dashboard で 共通のタイムスケールで 複数のテレメトリを一括表示 （Grafana v6.4 から対応） アノテーションの追加や、 Exploreへの切り替えも可能 Grafana Loki Promtail (target)
42. 41 #NTTtech https://bit.ly/38w7r9U 補足：Dashboard に可視化しておくべきログ 事象の再現待ちや、特定の error の狙い撃ち、性能関連の通知など つまり、メトリクスの特徴に応じて出力されるログにあたりが付いている場合に有効 障害発生 調査・復旧 原因分析 再現待ち用の ダッシュボード作成 Explore 分析結果を元に、事象の再現を捉えるための メトリクスの可視化と併せて、 関連するログをダッシュボードに可視化
43. 42 #NTTtech https://bit.ly/38w7r9U indexを格納できる 外部ストレージ ・Amazon DynamoDB ・Google Bigtable ・Apache Cassandra ・BoltDB * 収集したログの永続化 index と chunk それぞれの蓄積に、外部のストレージを利用可能 データ量と書き込み頻度に合わせてコストパフォーマンスを最適化できる Grafana Loki Promtail (target) * 後述の cluster mode では利用不可 chunk index chunkを格納できる 外部ストレージ ・Amazon DynamoDB ・Google Bigtable (?) ・Apache Cassandra ・Amazon S3 ・Google Cloud Storage ・Filesystem * 例： Cloud Storage Bigtable &
44. 43 #NTTtech https://bit.ly/38w7r9U Pipeline によるログの転送前処理 各 Stage を組み合わせることでログの加工やメトリクスの発行が可能 Parsing stages 各形式でログをパースする [ docker, cri, regex, json ] Transform stages テンプレートで抽出データを修正する [ template ] Action stages エントリに基づき各項目を作成/変更する [ timestamp, output, labels, metrics, tenant ] Filtering stages ラベルセットに基づいて後続のStageを適用する [ match ] 例： Grafana Loki Promtail (target) pipeline_stages: - match: selector: '{name="promtail"}' stages: - regex: expression: '.*level=(?P<level>[a-zA-Z]... - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp
45. 44 #NTTtech https://bit.ly/38w7r9U ログに基づくアラート Pipeline の Metrics Stage を、ログに基づくアラートに応用できる info を除く some-app アプリケーションの ログが「panic」を含む場合に、 Counterのメトリクス panic_total を発行する Alertmanager Prometheus Promtail Prometheus が Promtail の開示しているメトリクスを スクレイプし、アラートルールに基づいて Alertmanager へ連携 pipeline_stages: - 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
46. 45 #NTTtech https://bit.ly/38w7r9U Loki-canary による欠落検出 個々が独立したイベントであるため、欠落に気付ける仕組みが必要 Loki-canary が自身の出力したログを Loki に問い合わせ、スタックの正常性を継続的に検証する Promtail Loki ship (websocket) Loki-canary tail write Log
47. 46 #NTTtech https://bit.ly/38w7r9U Loki / Promtail のモニタリング Loki や Promtail は Prometheus 形式のメトリクス開示をサポート Pipeline の Metrics Stage で設定したメトリクスもこのエンドポイントで開示される まずは Loki 公式の Mixin を使うところから始めるのがおすすめ 基本のDashboard, Recording rules, Alerting rulesがまとめて提供されている - https://github.com/grafana/loki/tree/master/production/loki-mixin Promtail Loki Prometheus scrape /metrics /metrics
48. 47 #NTTtech https://bit.ly/38w7r9U Promtail 以外の選択肢 ・Fluentd / Fluent Bit の Output プラグインで Loki にログを転送可能 ログに対して複雑なパースを行う場合や、ログからメトリクスを抽出する場合におすすめ ・Kubernetes 以外の環境で Loki を利用したい場合 Docker Logging Driver for Lokiも用意されている（今回は Kubernetes を前提としているので割愛） ship tail Loki (target) Multi-workerで利用する際はWorker IDの付与が必要 （Loki は同一ストリームで順不同のログエントリをサポートしていないため）
49. 48 #NTTtech https://bit.ly/38w7r9U Overview : Loki on Kubernetes（再掲） Grafana Loki LogCLI Loki-canary Promtail Fluentd / Fluent Bit logs query logs & metrics query metrics query (websocket) Log ship ship tail tail (target) alert Prometheus metrics query Dashboard Search Dashboard Explore Data Collection （+ Aggregation& Processing ） Indexing & Storing Explore & Visualization
50. 49 #NTTtech https://bit.ly/38w7r9U from Binary (prebuilt binaries / manual build) 参考：その他の展開方法 The Installation docs を参考に、お好みの方法で展開： - https://github.com/grafana/loki/blob/master/docs/installation/README.md Grafana Labsが開発している ksonnet 後継のマニフェスト管理ツール GrafanaからLokiへの接続手順はこちら： - https://github.com/grafana/loki/blob/master/docs/getting-started/grafana.md
51. おわりに
52. 51 #NTTtech https://bit.ly/38w7r9U まとめ Loki はラベルベースのインデックスにより、軽量かつ直感的なフィルタ リングで Kubernetes にクラスタレベルのロギングを提供する Loki は Prometheus と互換性のあるラベリングにより、主にデバッグの 文脈においてメトリクスとログのスイッチングコストを低減できる Loki は小さなフットプリントとシングルバイナリで構成され、かつ必要 に応じてスケールできる Cloud Native なアーキテクチャを持つ
53. Thank you for your attention!