Grafana Lokiで Cloud Nativeなロギングを はじめよう！ Masahiko Utsunomiya 2019/11/28 CloudNative Days Kansai 2019 Day2, B2-1

2 #CNDK2019 掲載内容は個人の見解であり、 所属する企業や組織の立場、戦略、意見を 代表するものではありません

3 #CNDK2019 Whois Masahiko Utsunomiya Infrastructure Engineer / Relationship Builder NTT DATA Corporation ✓ 金融分野のお客様のクラウド導入支援 ✓ 興味：Observability周辺（Prometheus, Loki, Jaeger, etc.） ✓ Grafana Loki コントリビュータ Helm Chartのメンテナンスなどしています polar3130

4 #CNDK2019 制作に参加した書籍がでました “Kubernetes ポケットリファレンス” ISBN : 978-4-297-10957-8 2019/11/16発売 技術評論社より 主にレビュアとして参加、 本編・コラムの一部執筆も担当させて頂きました

5 #CNDK2019 Agenda • 背景と課題 • Cloud Nativeな環境とObservability • ロギングの目的 • Kubernetesのロギングにおける課題 • Grafana Loki • 基本概念とアーキテクチャ • Lokiを使ったトラブルシューティング • Cloud Native な設計思想 • おわりに

#CNDK2019 背景と課題

7 #CNDK2019 Cloud Native な環境の特性 ✓ “インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行う” - CNCF Cloud Native Definition v1.0 * より ✓ “回復性、管理力、および可観測性のある疎結合システム” - Cloud Native な環境には Observability（可観測性）が必要 ✓ “アプローチの代表例に、コンテナ、サービスメッシュ、マイクロ サービス、イミュータブルインフラストラクチャ、および宣言型API” - Kubernetes はそのアプローチを実現する代表的な技術のひとつ *：https://github.com/cncf/toc/blob/master/DEFINITION.md

8 #CNDK2019 Observability（可観測性） Cloud Native な環境の Observability とは システムの信頼性を . 継続的に証明できる性質 そもそもシステムをモニタリングするのは、 対象となるシステムの信頼性を証明するため* モニタリングの対象が動的に変化し続けるなら、 変化に伴って信頼性を証明し続けられる性質を 備える必要がある 証明に用いる代表的な3要素として、 Metrics, Tracing, Loggingがある Metrics Tracing Logging request-scoped metrics aggregatable events volume request-scoped events request-scoped, aggregatable events *：https://assets.sumologic.jp/resources/brief/kubernetes_observability_ebook.pdf 参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

9 #CNDK2019 ロギングの目的 改変できない、されていないと 証明できることが必要 プロセスの透明性が重視される 何らかのアクティビティの 証跡となるもの 軽量性、高可用性が必要 できるだけ多くの生ログと、 簡便なgrepツールが求められる Grafana Loki が得意とする領域 Logging 短期的目線 長期的目線 監査・実績管理 傾向分析・予測 複雑な二次加工が必要（傾向） 多角的な集計・フィルタリング ができるツールが求められる EFK や Splunk が得意とする領域 全文検索を可能にするため、 メタデータが膨大になる傾向あり デバッグ 傾向分析・予測 複雑な二次加工が必要（傾向） 多角的な集計・フィルタリング ができるツールが求められる EFK や Splunk が得意とする領域 全文検索を可能にするため、 メタデータが膨大になる傾向あり

10 #CNDK2019 デバッグにおける 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/

11 #CNDK2019 Kubernetes のロギング • ノードレベル • いつもの ” kubectl logs … ” • コンテナのI/Oの基本は stdout / stderr であり、コンテナ / ポッド / ノードが落ちるとログを見失う • クラスタレベル • Kubernetes 自体はクラスタレベルのロギングソリューションを提供していない • デザインパターンは大別して3種類 * エージェントをサイドカーで配置 エージェントをノード単位で配置 アプリケーションから直接公開 *：https://kubernetes.io/docs/concepts/cluster-administration/logging/

12 #CNDK2019 既存のデバッグ用途クラスタレベルロギングツール • Easy to use • いずれも Viewer に特化しており、ログの収集・蓄積は行わない • 多くは Kubernetesリソースベースの検索に限定されている kail ：https://github.com/boz/kail stern：https://github.com/wercker/stern Kubetail ：https://github.com/johanhaleby/kubetail

13 #CNDK2019 Kubernetes のロギングにおける課題 • ログは Observability の3要素の中で最もデータ量が多い が、個々が独立したイベントであるため間引くことができない かと言ってデバッグのためにはログ出力を絞りたくもない、大量のログを軽量に扱いたい • スケーリングと操作が簡単であってほしい 難解なクエリを書いたり、重厚なログ管理インフラを整備する必要なく、 監視対象の柔軟性に応じて容易に拡張でき、かつクラスタレベルでログを簡単にgrepしたい • メトリクスとログの関連性を見つけ出したい メトリクスに関連するログを容易に抽出できる仕組みが欲しい 既存のクラスタレベルログビューアではログを収集しないためメタデータは付与できない

#CNDK2019 Grafana Loki 1. 基本概念とアーキテクチャ

15 #CNDK2019 • 圧縮された非構造化ログとメタデータのインデックスのみを扱うことで軽量に動作 • Prometheusにインスパイアされた設計： 時系列データベース、サービスディスカバリ、ラベルによる多次元データモデル • 水平スケーラビリティ、高可用性、マルチテナンシーをデフォルトで組み込み Grafana Labsが開発している、 OSSのロギングツール（以降、Lokiと記載） - KubeCon + CloudNativeCon NA 2018で発表 - v1.0.0 (先週のKubeCon + CloudNativeCon NA 2019にて) - Github Star 7,742（11/19、v1.0.0リリース時点） - Go言語で開発 like Prometheus, but for logs. Grafana Loki とは Grafana Loki：https://github.com/grafana/loki

16 #CNDK2019 Loki ベースのロギングスタック 基本形は以下の3つのコンポーネントで構成 Promtail：自身のノード上のログファイルを検出し、ラベルに基づき Loki に転送する Loki：クライアントから受け取ったログにインデックスを付与し、保管する Grafana：Loki をネイティブサポートしている時系列データ可視化ツール（v6.0 以降が必要） Grafana Loki Daemonset で展開するのが基本だが サイドカーとして Pod 内に展開も可能 (target) Promtail

17 #CNDK2019 ラベルベースのインデックス付与 ラベルセット単位でログデータのチャンクを作成し、インデックスを付与する 全文インデックスを作成しないことで、メタデータの量が非常に少なく済む { 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)

18 #CNDK2019 Grafana を用いたログ検索（ Explore ） コンテキストに応じた ラベルを選択し、 grep感覚でフィルタリング Loki は 単一行のログのみを扱う ログ検索の基本形 Grafana Loki Promtail (target)

19 #CNDK2019 Grafana を用いたログ検索（ Explore ） コンテキスト検索 本当に欲しい情報は、 特定したログ行の前後に 存在する場合がある “ grep -A/B/C ” オプション の発想を Loki + Grafana で 実装したもの Grafana Loki Promtail (target)

20 #CNDK2019 Grafana を用いたログの可視化（ Dashboard ） ログもメトリクスも 1枚の Dashboard で 共通のタイムスケールで 複数のテレメトリを一括表示 （Grafana v6.4 から対応） アノテーションの追加や、 Exploreへの切り替えも可能 Grafana Loki Promtail (target)

21 #CNDK2019 補足：Dashboard に可視化しておくべきログ 事象の再現待ちや、特定の error の狙い撃ち、性能関連の通知など つまり、メトリクスの特徴に応じて出力されるログにあたりが付いている場合に有効 障害発生 調査・復旧 原因分析 再現待ち用の ダッシュボード作成 Explore 分析結果を元に、事象の再現を捉えるための メトリクスの可視化と併せて、 関連するログをダッシュボードに可視化

22 #CNDK2019 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)

23 #CNDK2019 LogQL：Log Query Language ストリームセレクタとフィルタ式でログを抽出する独自のクエリ言語 Prometheus のクエリ言語である PromQL を参考に設計されている ストリームセレクタ フィルタ式 条件に合致するログを 時系列で出力 { job=“mysql“ } |= "error" != "timeout" ラベルを指定して grep grep |= ログが指定文字列を含む != ログが指定文字列を含まない |~ ログが正規表現に合致する !~ ログが正規表現に合致しない = 合致 != 合致しない（否定） =~ 正規表現で合致 !~ 正規表現で合致しない

24 #CNDK2019 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別ログ行数

25 #CNDK2019 ログのメトリクスを可視化する ログの量・頻度を 捉える Loki v0.4 で追加された機能 現状は、ログデータソースと メトリクスデータソースで 同一の Loki を別途登録する 必要がある （Grafana v6.6 で解消予定） Grafana Loki Promtail (target)

26 #CNDK2019 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 &

27 #CNDK2019 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[a-zA-Z]... - labels: level: component: - timestamp: format: RFC3339Nano source: timestamp

28 #CNDK2019 ログに基づくアラート 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: ".*(?Ppanic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc

29 #CNDK2019 Loki-canary による欠落検出 個々が独立したイベントであるため、欠落に気付ける仕組みが必要 Loki-canary が自身の出力したログを Loki に問い合わせ、スタックの正常性を継続的に検証する Promtail Loki ship (websocket) Loki-canary tail write Log

30 #CNDK2019 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

31 #CNDK2019 Promtail 以外の選択肢 ・Fluentd / Fluent Bit の Output プラグインで Loki にログを転送可能 ログに対して複雑なパースを行う場合や、ログからメトリクスを抽出する場合におすすめ ・Kubernetes 以外の環境で Loki を利用したい場合 Docker Logging Driver for Lokiも用意されている（今回は Kubernetes を前提としているので割愛） ship tail Loki (target) Multi-workerで利用する際はWorker IDの付与が必要 （Loki は同一ストリームで順不同のログエントリをサポートしていないため）

32 #CNDK2019 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

33 #CNDK2019 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

#CNDK2019 Grafana Loki 2. Lokiを使ったトラブルシューティング

35 #CNDK2019 “Like Prometheus” ? Loki は Prometheus と多くの共通点を持つ Prometheus Loki 多次元データモデル 共通点 相違点 Pull型 Push型 収集方式 動的ラベル付与の仕組み サービスディスカバリ Grafanaでネイティブサポート 時系列データを扱う 単一バイナリ メトリクス ログ 収集対象

36 #CNDK2019 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

37 #CNDK2019 スイッチングコストの低減 Prometheusとのコンポーネント共通化により、 コンテキストを維持しながらメトリクスとログを切り替えられる Promtail のターゲット検出やラベル付与の仕組みは Prometheus と同様の文法で記述する 同じ設定を使ってメトリクスとログに一貫性のあるメタデータ付与ができる Logging Metrics Adhoc Query Log Aggregation app production v1 relabel_config service discovery 本番環境のapp v1 に関するメトリクス 本番環境のapp v1 に関するログ app production v1

38 #CNDK2019 デモ環境とトラブルシューティングの流れ • アラートをトリガにダッシュボードを参照 • メトリクスに対するアドホッククエリで原因の仮設を立てる • ラベルに基づくコンテキストは維持したまま、メトリクスからログにスイッチング • ログから事象の詳細を特定する

39 #CNDK2019 デモ

#CNDK2019 Grafana Loki 3. Cloud Native な設計思想

41 #CNDK2019 Prometheus エコシステムからの影響 Loki の内部は Thanos と Cortex の両方に影響を受けて設計されている Prometheus で水平スケール、マルチテナンシー、データ永続化などをサポートするための OSS いずれも CNCF Sandbox project ローカルでも実行できるシンプルな依存関係で、 必要なコンポーネントが 個別にスケールできるコンセプトはThanosから ログの収集と圧縮、リモートストレージの管理、 分散処理による効率的なクエリ処理のための 具体的な実装は Cortex から Thanos：https://github.com/thanos-io/thanos Cortex：https://github.com/cortexproject/cortex Thanos と Cortex の比較資料：https://promcon.io/2019-munich/slides/two-households-both-alike-in-dignity-cortex-and-thanos.pdf

42 #CNDK2019 Loki の設計思想 Loki はユニークなシングルバイナリのまま、複数の実行モードを持つ monolithic mode (gRPC) target: all single process mode cluster mode クラウドストレージ (or Cassandra) read / write read / write read / write write read NG ローカルストレージ target: all target: all target: target: : すべて同一のシングルバイナリ microservices mode

43 #CNDK2019 Loki の内部アーキテクチャ マイクロサービス アーキテクチャで構成 Loki は多くのソースコードを Cortex から流用している 実装の詳細を把握したければ Cortex のソースコードを参照 するのがおすすめ 参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

44 #CNDK2019 Loki のスケーラビリティ Loki は Cloud Native な対象をモニタリングするために、 自身も Cloud Native なアーキテクチャでできている 監視対象の規模・性能要件などの環境特性に応じて水平スケール可能なアーキテクチャ Promtail Grafana Loki Querier Ingester scale out read write

#CNDK2019 おわりに

46 #CNDK2019 Loki と Grafana のこれから KubeCon + CloudNativeCon NA 2019 にてコミッタ達にヒアリングしてきました （公式にアナウンスされたものではありませんのでその点ご留意ください） ・Alerting (Loki) 現状は Promtail からメトリクスを発行する方式だが、 将来は Loki でネイティブにサポートしたい ・Storage (Loki) 現状、Cluster mode でローカルストレージは非サポートだが、 できるだけ早期にこれをサポートしたいと考えている ・Tracing (Loki, Grafana) ログのトレースIDからレイテンシを可視化（Grafana v7, may/2020 予定） まず Jaeger から、追って他のトレースツールもサポート予定

47 #CNDK2019 利用パターン ・ゼロから Kubernetes のロギングを整備してゆく場合 Helm Chart などを活用、必要リソースも少ないため導入は容易 GAになったので今後は導入事例も増えてゆくのでは ・すでにモニタリング SaaS を導入している場合 モニタリング SaaS のバックアップとして Loki を導入する システムは生きているがモニタリング SaaS が死んでいる、という状況は想定しておくべき ・すでに EFK（ Fluentd / Fluent Bit ）を導入している場合 障害解析用のログ（Debugなど）は送付先を Elasticsearch から Loki に変える 用途に応じて使い分けることで、Elasticsearch の肥大化を防げる このケースは既存の構成に変更が入る点に注意

48 #CNDK2019 NTT DATA における Loki の導入状況 金融分野のいくつかのプロジェクトで導入を検討している うち1件は本番環境への導入が決まっており、現在設計中 Grafana Loki Promtail Fluentd logs & metrics query ship tail tail (target) alert Prometheus metrics query ログ起因のアラート生成に 複雑な条件を要するため Fluentdを併用

49 #CNDK2019 まとめ Loki はラベルベースのインデックスにより、軽量かつ直感的なフィルタ リングで Kubernetes にクラスタレベルのロギングを提供する Loki は Prometheus と互換性のあるラベリングにより、主にデバッグの 文脈においてメトリクスとログのスイッチングコストを低減できる Loki は小さなフットプリントとシングルバイナリで構成され、かつ必要 に応じてスケールできる Cloud Native なアーキテクチャを持つ

Thank you for your attention!