Movatterモバイル変換

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

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

2#NTTtech https://bit.ly/38w7r9UWhois✓ 金融分野のお客様のクラウド導入支援✓ 興味：Observability（Prometheus, Fluentd, Loki, Jaeger, etc.）✓ Grafana Loki コントリビュータHelm Chart のメンテナンスなどしていますpolar3130Masahiko UtsunomiyaInfrastructure Engineer / Relationship BuilderNTT DATA Corporation

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

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

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

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

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

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

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

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

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

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

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

15#NTTtech https://bit.ly/38w7r9UCloud Native における Observability とはシステムの信頼性を継続的に証明できる能力/性質モニタリング対象が動的に変化し続けるなら、システムはその変化に伴って信頼性を証明し続けられる必要があるよって、Observability には自動化されたテストと継続的なモニタリングの改善が不可欠証明に用いる代表的な 3 つの要素として、Metrics, Tracing, Logging があるMetricsTracingLoggingrequest-scopedmetricsaggregatableeventsvolumerequest-scopedeventsrequest-scoped, aggregatable events参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

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

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

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

19#NTTtech https://bit.ly/38w7r9UCloud Native における Observability（再掲）システムの信頼性を継続的に証明できる能力/性質モニタリング対象が動的に変化し続けるなら、システムはその変化に伴って信頼性を証明し続けられる必要があるよって、Observability には自動化されたテストと継続的なモニタリングの改善が不可欠証明に用いる代表的な 3 つの要素として、Metrics, Tracing, Logging があるMetricsTracingLoggingrequest-scopedmetricsaggregatableeventsvolumerequest-scopedeventsrequest-scoped, aggregatable events参考：https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

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

21#NTTtech https://bit.ly/38w7r9Uデバッグにおける ObservabilityLoggingMetricsTracing!AlertFixDashboard Adhoc QueryLog AggregationDistributed Tracinglead-timeメトリクス、ログ、トレース情報を別々に、ただ取っておくだけでは不十分参照したテレメトリから、別のテレメトリへ移る際のコンテキストを可能な限り維持したい例えば、アドホックに抽出したメトリクスと関連するログを、即座に特定できれば…動的に変化する環境のデバッグでは特にテレメトリ間の関連性を見失わないことが重要参考：https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/

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

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

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

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

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

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

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

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

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

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…chunkchunkStreamID : 2abb13…indexindexGrafana Loki Promtail (target)

32#NTTtech https://bit.ly/38w7r9Usource_labels参考：Promtail のロギングターゲット検出Prometheus と同様の仕組みでターゲットの動的検出が可能各 Promtail は同一ホスト上の Pod のみ検出可能、利用する際は “__host__” ラベルの設定が必要discoverB __host__：BdiscoverA __host__：Arelabel_configs:- source_labels: ['__meta_kubernetes_pod_node_name']target_label: '__host__'PromtailPromtail

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

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

35#NTTtech https://bit.ly/38w7r9URange 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別ログ行数

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

37#NTTtech https://bit.ly/38w7r9Uスイッチングコストの低減Prometheusとのコンポーネント共通化により、コンテキストを維持しながらメトリクスとログを切り替えられるPromtail のターゲット検出やラベル付与の仕組みは Prometheus と同様の文法で記述する同じ設定を使ってメトリクスとログに一貫性のあるメタデータ付与ができるLoggingMetricsAdhoc QueryLog Aggregationapp productionv1relabel_config service discovery本番環境のapp v1に関するメトリクス本番環境のapp v1に関するログapp productionv1

39#NTTtech https://bit.ly/38w7r9ULogCLI を用いた分析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)

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

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

42#NTTtech https://bit.ly/38w7r9Uindexを格納できる外部ストレージ・Amazon DynamoDB・Google Bigtable・Apache Cassandra・BoltDB *収集したログの永続化index と chunk それぞれの蓄積に、外部のストレージを利用可能データ量と書き込み頻度に合わせてコストパフォーマンスを最適化できるGrafana Loki Promtail (target) * 後述の cluster mode では利用不可chunkindexchunkを格納できる外部ストレージ・Amazon DynamoDB・Google Bigtable (?)・Apache Cassandra・Amazon S3・Google Cloud Storage・Filesystem *例： Cloud StorageBigtable &

43#NTTtech https://bit.ly/38w7r9UPipeline によるログの転送前処理各 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: RFC3339Nanosource: timestamp

44#NTTtech https://bit.ly/38w7r9Uログに基づくアラートPipeline の Metrics Stage を、ログに基づくアラートに応用できるinfo を除く some-app アプリケーションのログが「panic」を含む場合に、Counterのメトリクス panic_total を発行するAlertmanager Prometheus PromtailPrometheus が Promtail の開示しているメトリクスをスクレイプし、アラートルールに基づいてAlertmanager へ連携pipeline_stages:- match:selector: '{app="some-app"} != "info"'stages:- regex:expression: ".*(?P<panic>panic: .*)"- metrics:- panic_total:type: Counterdescription: "total count of panic"source: panicconfig:action: inc

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

46#NTTtech https://bit.ly/38w7r9ULoki / Promtail のモニタリングLoki や Promtail は Prometheus 形式のメトリクス開示をサポートPipeline の Metrics Stage で設定したメトリクスもこのエンドポイントで開示されるまずは Loki 公式の Mixin を使うところから始めるのがおすすめ基本のDashboard, Recording rules, Alerting rulesがまとめて提供されている- https://github.com/grafana/loki/tree/master/production/loki-mixinPromtailLokiPrometheusscrape/metrics/metrics

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

48#NTTtech https://bit.ly/38w7r9UOverview : Loki on Kubernetes（再掲）Grafana LokiLogCLI Loki-canaryPromtailFluentd / Fluent Bitlogsquerylogs & metrics querymetricsquery(websocket)Logshipshiptailtail(target)alertPrometheusmetricsqueryDashboardSearchDashboard ExploreData Collection（+ Aggregation& Processing ）Indexing & StoringExplore & Visualization

49#NTTtech https://bit.ly/38w7r9Ufrom Binary(prebuilt binaries / manual build)参考：その他の展開方法The Installation docs を参考に、お好みの方法で展開：- https://github.com/grafana/loki/blob/master/docs/installation/README.mdGrafana Labsが開発しているksonnet 後継のマニフェスト管理ツールGrafanaからLokiへの接続手順はこちら：- https://github.com/grafana/loki/blob/master/docs/getting-started/grafana.md

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

Movatterモバイル変換

Change Language

Grafana LokiではじめるKubernetesロギングハンズオン（NTT Tech Conference #4 ハンズオン資料）

Embed presentation

Recommended

More Related Content

What's hot

More from NTT DATA Technology & Innovation

Grafana LokiではじめるKubernetesロギングハンズオン（NTT Tech Conference #4 ハンズオン資料）