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

Slide 1

Slide 1 text

[Hands on – C4] Grafana Loki ではじめる Kubernetes ロギングハンズオン Masahiko Utsunomiya 2020/1/31 NTT Tech Conference #4

Slide 2

Slide 2 text

1 #NTTtech https://bit.ly/38w7r9U 掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものではありません

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

4 #NTTtech https://bit.ly/38w7r9U Agenda ⚫ 環境構築 ⚫ Observability とは ⚫ Cloud Native における Observability ⚫ ロギングの目的と課題 ⚫ Grafana Loki 入門 ⚫ ハンズオン＆解説：基本構成と LogQL 基礎 ⚫ Appendix

Slide 6

Slide 6 text

5 #NTTtech https://bit.ly/38w7r9U チュートリアルはこちらから bit.ly/38w7r9U https://github.com/polar3130/grafana-loki-getting-started

Slide 7

Slide 7 text

Observabilityとは

Slide 8

Slide 8 text

7 #NTTtech https://bit.ly/38w7r9U 単語から捉える Observability（可観測性）観測に関して“ある”能力を備えているということ Observability

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

9 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native Definition にそう書いてあるから...？ * https://github.com/cncf/toc/blob/master/DEFINITION.md

Slide 11

Slide 11 text

10 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native Definition にそう書いてあるから...？ * https://github.com/cncf/toc/blob/master/DEFINITION.md

Slide 12

Slide 12 text

11 #NTTtech https://bit.ly/38w7r9U なぜ Cloud Native に Observability が必要か Cloud Native な環境においては、「いまシステムで何が起きていて、サービスにどう影響しているか把握できること」「事象の原因を素早く特定するために必要な情報に的確にアクセスできること」が、従来のモニタリングの仕組み/方法論だけでは実現できないからなぜ実現できないのか？その背景には「なぜモニタリングという行為が必要とされてきたのか」、そして「アーキテクチャの変化」がある

Slide 13

Slide 13 text

12 #NTTtech https://bit.ly/38w7r9U そもそもなぜモニタリングをするのか

Slide 14

Slide 14 text

13 #NTTtech https://bit.ly/38w7r9U モニタリングの目的システムの信頼性を確保することシステムは期待どおりに動いているか、でなければ何が起きているのか、何が原因なのかを知りたいロールによって見るべき値や計測の手段は異なるが、それぞれのものさしで信頼性を測るためにモニタリングは行われる・Dev の場合例えば、アプリケーションが正常に動作しているか、期待される UX が提供できているか・Sec の場合例えば、システムが健常性を維持しているか、脅威が発生すればそれを迅速に特定できるか・Ops の場合例えば、クラウドインフラ、CI/CD、プラットフォームが正常に動作しているか参考：https://assets.sumologic.jp/resources/brief/kubernetes_observability_ebook.pdf

Slide 15

Slide 15 text

14 #NTTtech https://bit.ly/38w7r9U アーキテクチャの変化 Cloud Native な環境では、徹底した自動化や、プラットフォームの持つ回復性などにより、システムは動的かつ頻繁に変化するようになる常に変化し続ける環境では、これまでのモニタリングの考え方だけで「いまシステムで何が起きていて、サービスにどう影響しているか把握」したり、「事象の原因を素早く特定するために必要な情報に的確にアクセス」することは非常に困難

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

16 #NTTtech https://bit.ly/38w7r9U 補足：Observability の定義は人によって異なる？ how で捉えると、そうとも言える信頼性を証明するための尺度がロールや環境によって異なるからなので人によって Profiling を含んだり、Service Mesh を含んだり、Visualization を含んだりする根底にある目的が「信頼性の継続的な確保」ということに変わりはない参考：https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431

Slide 18

Slide 18 text

17 #NTTtech https://bit.ly/38w7r9U チュートリアルを再開します

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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/

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Grafana Loki 入門基本構成と LogQL 基礎

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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)

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

33 #NTTtech https://bit.ly/38w7r9U チュートリアルを再開します

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Appendix

Slide 40

Slide 40 text

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)

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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 &

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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: ".*(?Ppanic: .*)" - metrics: - panic_total: type: Counter description: "total count of panic" source: panic config: action: inc

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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 は同一ストリームで順不同のログエントリをサポートしていないため）

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

おわりに

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Thank you for your attention!