広範な OTLP 対応に向けて: Cloud Monitoring が OpenTelemetry Protocol 指標をサポート

※この投稿は米国時間 2026 年 2 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、オープン標準への取り組みの一環として、OpenTelemetry をテレメトリー データ用のユニバーサル クライアント、データ形式、標準セットとするために尽力しています。

昨年は、Cloud Observability が OpenTelemetry Protocol（OTLP）を使用したトレースの送信に対応したことを発表いたしました。そして今回、あらゆるソリューションで OpenTelemetry を活用できるようにするという目標に向けた次のステップとして、Cloud Observability における Cloud Monitoring の指標向け OTLP への対応を発表いたしました。

指標向け OTLP: 「新標準」以上の意味

OpenTelemetry と OTLP を使用すると、プロバイダに完全に依存しないパイプラインで指標データを生成して Google Cloud に送信できます。OpenTelemetry SDK を使用して OTLP 指標を作成し、OpenTelemetry コレクタを使用して収集、変換してから、そのデータを OpenTelemetry 形式で Cloud Monitoring に直接送信できます。

デフォルトでは、このデータは Managed Service for Prometheus のデータと同じ形式で保存され、費用も同様に低く抑えることができます。このデータは、Cloud Monitoring の他のデータをクエリする場合と同じインターフェースを使用してクエリできます。

OTLP を使用すると、次のような新機能も利用できます。これらは、お客様からのご要望の多かった機能です。

• デルタタイプの指標: 前回のエクスポートから今回のエクスポートまでの間にモノトニック カウンタで変化した量を送信します。メモリ内のすべてのカウンタをトラッキングして、常にカウンタの最新の値を送信することはありません。これにより、クライアントはエクスポートの合間にメモリをフラッシュできるため、クライアントサイドのリソース消費が大幅に削減され、有効期間が短い、または増分が少ない時系列データをより適切に収集できるようになります。

• 指数（動的）ヒストグラム: 従来のヒストグラムでは、予測されるデータの分布に基づいてバケット幅を明示的に設定する必要があります。その予測が実際のデータ分布と一致しない場合、すべての観測結果が少数の低バケットにまとめられたり、注目すべき観測結果が「無限より低い」バケットに入れられて情報の精度が下がったりする可能性があります。これに対して、OpenTelemetry の指数ヒストグラムでは、実際に確認された値の範囲に基づいてバケットの境界が動的に変更されるため、ヒストグラムのバケットを推測して確認する必要がなくなります。一度設定すれば、後は自動で処理されます。

• 指標名のドットとスラッシュ、ラベルキーのドット: Cloud Monitoring で、PromQL を使用した URL スタイルの名前のクエリに完全対応いたしました。さらに、Cloud Monitoring のラベルキーで . 文字も使用できるようになりました。これにより、OpenTelemetry のセマンティック規約に対応できます。

• SDK から Cloud Monitoring へのコレクタ不要の指標の直接送信: Pod 間および Service 間のトラフィックを報告する Envoy やお客様が実行するロードバランサ プロセスなど、非常に大量でカーディナリティの高い指標ソースの場合、パイプラインに OpenTelemetry コレクタを配置すると、費用が非常に高くなる可能性があります。コレクタは、指標の量が多すぎる場合に過負荷になる傾向があり、コレクタを水平方向または垂直方向にスケールするには、デベロッパーが多くの作業を行う必要があります。OTLP を使用すると、OpenTelemetry SDK によってエクスポートされた指標を Cloud Observability の指標用 Telemetry API に直接ポイントできるため、中間プロセスを自分で実行してスケールする必要がなく、Google にボリュームの処理を任せることができます。

• 指標とトレースのゼロコード自動計測: OpenTelemetry を使用して互換性のあるワークロードを自動的に計測し、コードを使用せずに標準化されたトレースとゴールデン シグナル指標を生成してから、データを OTLP 形式で Cloud Observability に送信できます。ゴールデン シグナルの指標を取得するために、アプリケーション コードと計測のコードを混在させる必要はなくなりました。ただし、コード内のすべての RPC を忘れずに一貫して計測する必要があります。

Google Kubernetes Engine 向けマネージド OpenTelemetry

OpenTelemetry コレクタを自分で実行しようとすると、手動でデプロイ、構成、スケールする必要があるため、多くの手間がかかります。しかし、一般的なオブザーバビリティ プロファイルの一般的なワークロードの場合、通常は、OTLP シグナルを受信して拡充するためのシンプルなクラスタ内エンドポイントがあれば十分です。

そこで、Google は GKE 用マネージド OpenTelemetry も導入することにしました。これは、Google Kubernetes Engine で OTLP トレース、指標、ログを生成および収集するためのフルマネージドの「ワンクリック」パイプラインです。Google がコレクタのライフサイクル、アップグレード、スケーリングを処理するため、デベロッパーはオブザーバビリティ インフラストラクチャではなくアプリケーション コードに集中できます。

マネージド OpenTelemetry は、GKE 向けの初のフルマネージド トレース ソリューションです。トレースはアプリケーションのパフォーマンス モニタリングに不可欠であり、アプリケーションの依存関係の動的かつ実用的なビューであるアプリケーション トポロジマップなどの機能の基盤となります。

また、GKE 用マネージド OpenTelemetry を使用すると、OpenTelemetry SDK を使用するワークロードを自動的に構成および計測することもできます。1 つのカスタム リソースで、Agent Development Kit（ADK）といった OpenTelemetry をサポートするフレームワークで構築された AI エージェントなど、OpenTelemetry 対応のアプリケーションすべてのゴールデン シグナルを Cloud Observability で取得できます。

ご利用方法

指標向け OTLP は現在プレビュー版で、すべてのお客様にご利用いただけます。ただし、OpenTelemetry バージョン 0.140.0 以降を使用する必要があります。OpenTelemetry SDK または OpenTelemetry コレクタを使用した OTLP 指標の利用を開始する場合は、OTLP 指標取り込みに関するドキュメントをご覧ください。独自のコレクタを実行する場合は、可能であれば Google が構築した OpenTelemetry コレクタを使用することをおすすめします。

GKE 用マネージド OpenTelemetry は現在プレビュー版で、すべてのお客様にご利用いただけます。ただし、GKE クラスタ バージョン 1.34.1-gke.2178000 以降、gcloud CLI バージョン 551.0.0 以降を使用する必要があります。ご利用にあたっては、GKE 用マネージド OpenTelemetry のドキュメントをご覧ください。

最後に、セルフデプロイされた OpenTelemetry コレクタを使用して GKE 上の Java ワークロードのゼロコード自動計測を開始する場合は、ゼロコードに関するドキュメントをご覧ください。

- シニア プロダクト マネージャー、Lee Yanco

- シニア プロダクト マネージャー、James Maffey