OpenTelemetry オブザーバビリティ¶

オブザーバビリティを構築するために解決すべき課題¶

1. 分散型トレーシング（トレース）をフロントエンドとバックエンドでどのように連携させるか？

2. トレースとそれに対応するログやメトリクスをどのように関連付けるか？

1. OpenTelemetry はさまざまな言語の SDK を実装しており、フロントエンドのトレースは主に opentelemetry-js で実現されています。バックエンドにも Java、Go、Python など、各言語に対応した実装があります。各言語のトレース情報は統一して opentelemetry-collector（以下 otel-collector）に報告されます。

2. Java 言語を例にとると、opentelemetry-java（以下「Agent」）は javaagent 方式でアプリケーションに注入されます。アプリケーションがトレース情報を生成すると、MDC を設定することで traceId と spanId をログにパラメータとして渡すことができ、ログ出力時に traceId と spanId が付与されます。

マッピング診断コンテキスト（MDC）は、

異なるソースからのインターリーブされたログ出力を区別するためのツールです。— log4j MDC ドキュメント

MDC はスレッドローカルなコンテキスト情報を保持し、後でログライブラリがキャプチャする各ログイベントにコピーされます。

OTel Java エージェントは、現在のスパンに関するいくつかの情報を各ログレコードイベントの MDC コピーに注入します。

• trace_id - 現在のトレース ID（Span.current().getSpanContext().getTraceId() と同じ）
• span_id - 現在のスパン ID（Span.current().getSpanContext().getSpanId() と同じ）
• trace_flags - 現在のトレースフラグ。W3C トレースフラグ形式（Span.current().getSpanContext().getTraceFlags().asHex() と同じ）でフォーマットされます。

これら 3 つの情報は、パターン/フォーマットで指定することにより、ログライブラリが生成するログステートメントに含めることができます。

ヒント：logback を使用する Spring Boot 構成の場合、logging.pattern.level を上書きするだけで MDC をログ行に追加できます。

logging.pattern.level = trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

これにより、アプリケーションログを解析するあらゆるサービスやツールが、トレース/スパンとログステートメントを関連付けることができます。

1. OpenTelemetry はメトリクスの収集もサポートしています。otel-collector を介してメトリクスを Prometheus などの適切なエクスポーターに出力し、Grafana で表示できます。otlpExporter はメトリクスの出力をサポートしており、メトリクスとログおよびトレースの関連付けは、tag に server.name を指定することで行えます。

OpenTelemetry の本来の目的はデータ形式を統一することです。つまり、長期間にわたって OpenTelemetry が可観測性製品に注力するつもりはなく、引き続き OpenTelemetry をデータ中継局として使用したり、OpenTelemetry のデータ標準を利用して自社の可観測性製品を定義したりすることが想定されています。

OpenTelemetry によるエンドツーエンドのフルリンクオブザーバビリティ構築¶

以下では、OpenTelemetry に基づく 3 つのエンドツーエンドフルリンクオブザーバビリティ構築方法を紹介します。

1. 従来のモニタリングをベースにした大規模統合¶

主に otel-collector を使用して、ログ、メトリクス、トレースをそれぞれ ELK、Prometheus、および Jaeger などの APM ベンダーにプッシュします。

2. Grafana ファミリーをベースにした方法¶

近年、Grafana も可観測性分野に参入し、Grafana-Cloud と Grafana Labs を設立し、独自の可観測性ソリューションをリリースしました。Grafana Tempo は、オープンソースで使いやすく、大規模な分散トレーシングバックエンドです。Tempo はコスト効率が高く、実行にはオブジェクトストレージのみが必要で、Grafana、Prometheus、Loki と深く統合されています。Tempo は Jaeger、Zipkin、OpenTelemetry を含むあらゆるオープンソーストレーシングプロトコルと連携できるため、OpenTelemetry からのトレースデータを直接受信できます。Loki は OpenTelemetry からのログデータを収集し、Grafana は引き続き Prometheus を使用してメトリクスデータを受信します。

上記 2 つの方法はデータ形式の問題を解決しますが、ある意味ではテクノロジーと呼ぶことはできても製品とは言えず、基本的にはオープンソースツールの寄せ集めです。ビジネス上の問題が発生した場合、依然として異なるツールにアクセスして問題を調査・分析する必要があり、ログ、メトリクス、トレースがうまく統合されておらず、運用保守や開発者の運用・コミュニケーションコストを軽減できていません。ログ、メトリクス、トレースを統合したデータ分析プラットフォームの重要性は明らかであり、Grafana もこの方向で努力を続けていますが、データのサイロ化を完全に解決できておらず、異なる構造のデータには異なるクエリ言語が使用されています。Grafana は現在、ログデータとトレースデータの関連付けを実現していますが、トレースデータからログデータへの逆方向の関連付けはできません。Grafana チームは、データ間の相互関連クエリと分析を引き続き改善する必要があります。

3. Guance（商用可観測性製品）に基づく方法¶

Guance は、メトリクスデータ、ログデータ、APM、RUM、インフラストラクチャ、コンテナ、ミドルウェア、ネットワークパフォーマンスなど、さまざまなデータを統一的に収集・管理するプラットフォームです。Guance を使用することで、ログとトレースの連携だけでなく、アプリケーションを全方位から観測できます。

DataKit は Guance のフロントエンドゲートウェイです。データを Guance に送信するには、DataKit を正しく設定する必要があります。DataKit を利用すると以下の利点があります。

1. ホスト環境では、各ホストに DataKit が存在し、データはまずローカルの DataKit に送信され、DataKit がキャッシュ、前処理、そして報告を行います。これによりネットワークジッターを回避し、エッジ処理能力を付加することで、バックエンドのデータ処理負荷を軽減します。
2. Kubernetes 環境では、各ノードに DataKit の DaemonSet が存在します。Kubernetes の local traffic メカニズムを利用することで、各ノードの Pod のデータはすべてローカルノードの DataKit に送信されます。これによりネットワークジッターを回避するとともに、APM データに Pod とノードのラベルが追加され、分散環境での位置特定が容易になります。

DataKit の設計思想は OpenTelemetry から学んでおり、OLTP プロトコルと互換性があります。そのため、collector を経由せずに直接 DataKit にデータを送信することも、collector のエクスポーターを OLTP (DataKit) に設定することもできます。

ソリューション比較¶