マイクロサービスの障害で胃を痛めないための「シン・オブザーバビリティ基盤」をOpenTelemetryで作る：Cloud Nativeチートシート（25）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、トレース、ログ、メトリクスを関連付け、Grafana、Promtail、Prometheusを利用した横断的なオブザーバビリティ基盤を紹介します。

[逆井啓佑, 岡本隆史, 正野勇嗣，株式会社NTTデータ]

勘や経験に頼るマイクロサービスのトラブル調査で胃を痛めないために

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回は、OpenTelemetryやObservabilityの概要について紹介し、簡単なサンプルアプリケーションを使った分散トレーシングの方法を紹介しました。トレースを収集、可視化することによって、マイクロサービスをまたがるリクエストの追跡が容易になりました。

　しかし、分散トレーシングだけではOpenTelemetryの真の力を発揮できません。トレースによって「どの処理に時間がかかっているのか」「どの処理にエラーが発生しているのか」を知ることはできても、その原因を特定するには不十分なケースは多々あります。そのような場合、問題があるトレースやスパンに対応するログやメトリクスを調べることで原因の特定に役立つことがありますが、異なるテレメトリーを関連付けながら調査するのは容易ではありません。

　OpenTelemetryを用いることで、これらのテレメトリーを関連付けることができます（下図の「OpenTelemetry Collection」）。それによって、問題のあるトレースに対応するログやメトリクスを調べることができ、トラブルシューティングを効率化できます。

　今回は、OpenTelemetryやオープンソースソフトウェア（OSS）のモニタリングツールを用いてテレメトリーを関連付けることで、Grafanaダッシュボード上でログ、トレース、メトリクス間を行き来できるような三位一体の、いわば「シン・オブザーバビリティ基盤」を紹介します。

目次

• テレメトリーを関連付けることのメリット
• テレメトリーの関連付け
  • テレメトリーの“関連付け”――OpenTelemetryのコンセプト
  • 本稿で構築するアーキテクチャの紹介
• ログとトレースの関連付け
  • OpenTelemetryにおけるログの収集
  • ログへのトレースID、スパンIDの付与と、ログの収集／分析手法
  • コラム　OpenTelemetryのログ仕様やステータスについて
  • アプリケーションのログ出力方式
• メトリクスとトレースの関連付け
  • スパンメトリクスについて
  • スパンメトリクスへのトレースID、スパンIDの付与と、ログの収集／分析手法
• 各種コンポーネントのデプロイ
  • デプロイの全体像
  • 作業用namespaceの作成
  • OpenTelemetry Collectorのデプロイ
  • コラム　 Prometheusをプッシュ型で使う「Prometheus Remote Write」
  • Grafana Loki、Grafana、Promtailのデプロイ
  • コラム　Filelog Receiverによるログ収集
  • Grafana Tempoのデプロイ
  • Prometheusのデプロイ
  • サンプルアプリケーションのデプロイ
• Grafana上での各テレメトリーのトレースIDの関連付け
  • ログ→トレースの関連付け方法
  • メトリクス→トレースの関連付け方法
• まとめ

テレメトリーを関連付けることのメリット

　前回紹介したOpenTelemetry Collection（下図）では、テレメトリーを横串で探索できる情報（例えば、テレメトリー取得時間やクラスタ、Pod、コンテナなどのリソース情報、トレースIDやスパンIDなどのトレース情報）を付与します。

（再掲）

　このようにログ、トレース、メトリクスといったテレメトリーを“関連付ける”ことによって、さまざまな恩恵、特にトラブルを生じた際の解析性向上に寄与できます。下記はトラブルシューティングの一例です。

• エラーログから関連したトレースを見ることで、一連のリクエスト処理を追うことができ、エラーログ前後のイベントを把握する
• レイテンシの大きい異常メトリクスから関連したトレースを見ることで、「マイクロサービスのどの箇所で障害が起きているか」を確認する

　テレメトリー同士が関連していない場合、ログコンソールやダッシュボードを用いながら、勘や経験を頼りにテレメトリー間を関連付けることもしばしばあることでしょう。しかし一刻を争う有事の際に、原因特定までのリードタイムは最小化できることが望ましいです。

　テレメトリー間を関連付け、テレメトリーから対応するテレメトリーを即座に特定できることは、上記のような場合大きなアドバンテージになります。特に動的にリソースが変化するクラウドネイティブ環境において、テレメトリー間の関連性を保ち続ける（見失わない）ことが非常に重要です。

テレメトリーの関連付け

　各テレメトリー間を関連付けるためにはどのようにすればいいのでしょうか？　OpenTelemetryのコンセプトに触れながら説明します。

テレメトリーの“関連付け”――OpenTelemetryのコンセプト