Grafana LokiではじめるKubernetesロギングハンズオン （NTT Tech Conference #4 ハンズオン資料） 2020年1月31日 株式会社NTTデータ / NTT DATA Masahiko Utsunomiya

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 AggregationDistributed 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"
ラベルを指定して grepgrep
|= ログが指定文字列を含む
!= ログが指定文字列を含まない
|~ ログが正規表現に合致する
!~ ログが正規表現に合致しない
= 合致
!= 合致しない（否定）
=~ 正規表現で合致
!~ 正規表現で合致しない

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 productionv1
relabel_config service discovery
本番環境のapp v1
に関するメトリクス
本番環境のapp v1
に関するログ
app productionv1

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 では利用不可
chunkindex
chunkを格納できる
外部ストレージ
・Amazon DynamoDB
・Google Bigtable (?)
・Apache Cassandra
・Amazon S3
・Google Cloud Storage
・Filesystem *
例： Cloud StorageBigtable &

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 に問い合わせ、スタックの正常性を継続的に検証する
PromtailLoki
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
PromtailLoki
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 & StoringExplore & 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!