本記事は 2026 年 4 月 3 日 に公開された「Introducing OpenTelemetry & PromQL support in Amazon CloudWatch」を翻訳したものです。

Kubernetes やマイクロサービスのワークロードを AWS で実行している場合、メトリクスには namespace、pod、container、node、deployment、replica set、カスタムのビジネスディメンションなど、多数のラベルが付いているでしょう。環境全体を把握するために、メトリクスパイプラインを分割しているケースも多いはずです。AWS メトリクスには Amazon CloudWatch を使い、高カーディナリティ (多数のラベルの組み合わせを持つ) なコンテナやアプリケーションのメトリクスには別の Prometheus 互換バックエンドを使う、といった具合です。さらに進んだチームでは、Prometheus CloudWatch エクスポーターで GetMetricData API を呼び出し、AWS リソースメトリクスを Prometheus バックエンドに取り込んでいることもあります。運用負荷とコストは増えますが、すべてを一箇所でクエリできるようになります。

Amazon CloudWatch で OpenTelemetry メトリクスのネイティブ取り込みと、Prometheus Query Language (PromQL) によるクエリがサポートされました。このプレビュー機能では、メトリクスあたり最大 150 ラベルをサポートする高カーディナリティメトリクスストアが導入され、ラベルの多いメトリクスを変換や切り捨てなしで CloudWatch に直接送信できます。AWS Vended メトリクスの自動エンリッチメントと組み合わせることで、CloudWatch がインフラストラクチャ、コンテナ、アプリケーションメトリクスの一元的な送信先になり、すべて PromQL でクエリできるようになりました。

本記事では、以下の内容を説明します。

• AWS アカウントで OpenTelemetry メトリクスの取り込みと AWS リソースの自動エンリッチメントを有効化する方法
• Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに Amazon CloudWatch Container Insights をデプロイする方法
• Amazon CloudWatch と Amazon Managed Grafana で PromQL を使ってインフラストラクチャと AWS リソースのメトリクスをクエリする方法
• OpenTelemetry SDK でカスタムアプリケーションメトリクスを作成し、AWS コンテキストで自動エンリッチメントされる様子

CloudWatch における OpenTelemetry サポートが何を意味するか

OpenTelemetry Protocol (OTLP) は、OpenTelemetry (OTel) プロジェクトの標準ワイヤープロトコルです。メトリクス、トレース、ログを含むテレメトリデータのエンコードとコンポーネント間の転送方法を定義しています。このプレビューにより、CloudWatch は OpenTelemetry 互換のコレクターや SDK がメトリクスを送信できるリージョナル OTLP エンドポイントを公開します。

CloudWatch はメトリクスを受信し、新たな高カーディナリティのメトリクスストアに保存します。カウンター、ヒストグラム、ゲージ、アップダウンカウンターなどの OpenTelemetry メトリクスタイプは変換なしでそのまま保持されます。今回のリリースで、CloudWatch はオブザーバビリティの 3 本柱すべてで OpenTelemetry をサポートするようになりました。CloudWatch はすでに OTLP エンドポイント経由でトレースとログを受け付けており、ネイティブ OTLP メトリクス取り込みが加わったことで、すべてのテレメトリをオープンスタンダードで、単一のプロトコルを通じて CloudWatch に送信できるようになりました。3 つの機能がこのことを重要にしています。

拡張されたラベルとカーディナリティのサポート OTLP で取り込まれたメトリクスは最大 150 ラベルをサポートし、CloudWatch カスタムメトリクスの 30 ディメンション制限を超えています。Kubernetes、マイクロサービス、OpenTelemetry ワークロードでフィルタリングや集計に高カーディナリティラベルを使う際の主要な制約が解消されます。制限は今後も進化するため、最新情報はクォータページをご確認ください。

PromQL クエリのサポート OTLP 経由で取り込んだメトリクスを PromQL でクエリできます。すでに Prometheus を使っている場合、同じクエリ言語を CloudWatch や Amazon Managed Grafana で直接使えます。新しい構文を覚える必要はありません。

AWS リソースの自動エンリッチメント この機能により、AWS インフラストラクチャ全体でメトリクスをクエリ・フィルタリングする方法が根本的に変わります。CloudWatch は取り込んだすべてのメトリクスに AWS リソースコンテキスト (アカウント ID、リージョン、クラスター Amazon Resource Name (ARN)、AWS Resource Explorer からのリソースタグ) を付与します。このエンリッチメントは追加の計装なしで自動的に行われます。Container Insights、カスタムアプリケーション、AWS サービスのいずれから来たメトリクスでも、AWS アカウント、リージョン、環境タグ、アプリケーション名でフィルタリングやグループ化ができます。エクスポーター不要、カスタムラベル不要、追加の API 呼び出し不要です。

OTLP 取り込みと AWS リソースエンリッチメントの有効化

OTLP メトリクスを取り込んでクエリする前に、2 つのアカウントレベルの設定を有効にします。1 つ目は、AWS Resource Explorer で確認できるものと同じリソースタグをテレメトリに伝播させる設定です。2 つ目は、CloudWatch の OTLP 取り込みを有効にする設定です。

両方のエンリッチメント設定は、Amazon CloudWatch コンソールまたは AWS CLI から有効にできます。

コンソールを使用する場合

CloudWatch コンソールでエンリッチメントを有効にする手順は以下のとおりです。

1. Amazon CloudWatch コンソールを開きます。
2. ナビゲーションペインで 設定 を選択します。
3. リソースタグのテレメトリへの伝播を有効にします。
4. AWS メトリクスの OTel エンリッチメントを有効にします。

両方の設定を有効にすると、アカウントでリージョナルエンドポイントへの OTLP メトリクス受信の準備が整います。

AWS CLI を使用する場合

AWS CLI で両方のエンリッチメントレイヤーを有効にすることもできます。以下のコマンドを実行します。

# Enable resource tags on telemetry
aws observabilityadmin start-telemetry-enrichment
# Enable OTel enrichment for CloudWatch
aws cloudwatch start-o-tel-enrichment

両方のエンリッチメント設定がアクティブであることを確認するには、以下のコマンドを実行します。

aws cloudwatch describe-o-tel-enrichment-status

エンリッチメントを有効にすると、OTLP エンドポイント経由で取り込まれたすべてのメトリクスに AWS リソースコンテキストが自動的にタグ付けされます。CloudWatch が追加する属性は以下のとおりです。

これらの属性は CloudWatch によって追加され、手動の計装は不要です。カスタムパイプラインの構築やエクスポーターの実行なしに、AWS アカウント、リージョン、リソースタグをまたいでクエリできるのはこのためです。

OpenTelemetry メトリクスを使った Amazon CloudWatch Container Insights

OpenTelemetry と CloudWatch の連携を実際に確認するため、Container Insights から始めましょう。Amazon EKS 向け Amazon CloudWatch Container Insights で Prometheus と OpenTelemetry メトリクスがサポートされました。コンテナメトリクスが OpenTelemetry attribute で標準化され、PromQL でクエリできるようになります。Container Insights は、コンソールまたは AWS CLI から Amazon EKS アドオンを使って有効化できます。

Container Insights ダッシュボード

Container Insights をデプロイすると、CloudWatch は CPU 使用率、メモリ使用量、Pod 数などのクラスターレベルのメトリクスを表示するダッシュボードを自動的に作成します。ダッシュボードを表示するには、CloudWatch コンソールを開き、ナビゲーションペインから Container Insights を選択し、ドロップダウンからクラスターを選択します。クラスター、namespace、Pod レベルのビューを切り替えて、特定のワークロードを詳しく確認できます。

CloudWatch Query Studio で PromQL を使ってメトリクスをクエリする

OTLP で取り込んだメトリクスは、CloudWatch コンソール、Amazon Managed Grafana、または PromQL と AWS Signature Version 4 (SigV4) をサポートするクエリインターフェースで PromQL を使ってクエリできます。CloudWatch Query Studio には、コンソールで直接メトリクスを探索・可視化するための PromQL エディターが組み込まれています。PromQL クエリモードを選択して開始します。

エンリッチされた AWS リソースコンテキストを使ったクエリ

エンリッチメントが有効になっているため、CloudWatch が自動的に追加するタグを使って AWS リソースの境界を越えてクエリできます。エクスポーター不要、カスタムラベル不要です。

# AWS Lambda function duration for functions tagged with application "order-pipeline"
Duration{"@aws.tag.appname"="order-pipeline"}

# Amazon EC2 CPU utilization for production delivery workloads
CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"}

# Running pods grouped by AWS account and namespace
sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"})

最後のクエリは、カスタム計装なしで AWS アカウントと Kubernetes namespace ごとにグループ化された実行中の Pod 数を返します。aws_account_id ラベルはエンリッチメントレイヤーによって自動的に追加されます。

Grafana で PromQL を使ってメトリクスをクエリする

Amazon Managed Grafana で OTLP 取り込みメトリクスを可視化するには、CloudWatch PromQL エンドポイントを指す Prometheus データソースを追加します。このセクションでは、AWS Signature Version 4 (SigV4) 認証でデータソースを設定する手順を説明します。

1. Amazon Managed Grafana ワークスペースを開きます。
2. Data Sources を選択します。
3. Add data source を選択します。
4. データソースタイプとして Prometheus を選択します。
5. URL には、リージョンの CloudWatch PromQL エンドポイントを入力します: https://monitoring.<AWS Region>.amazonaws.com/v1/metrics
6. Authentication で SigV4 を選択します。
7. SigV4 認証用の適切な IAM ロールを設定します。
8. Save & Test を選択して接続を確認します。

Save & Test が成功すると、「Data source is working」という確認メッセージが表示されます。失敗した場合は、IAM ロールに cloudwatch:GetMetricData と cloudwatch:ListMetrics の権限があること、SigV4 署名が正しく設定されていることを確認してください。

データソースを設定すると、Grafana ダッシュボードで同じ PromQL クエリを使用できます。

カスタムアプリケーションメトリクス

CloudWatch OTLP 取り込みはカスタムアプリケーションメトリクスもサポートしています。OpenTelemetry SDK で計装されたアプリケーションは、クラスターで実行中の CloudWatch エージェント経由でメトリクスを送信でき、計装コードの変更は不要です。

実際の動作を確認するため、aws-otel-community リポジトリからサンプル Python アプリケーションをデプロイします。このアプリケーションは OpenTelemetry Python SDK を使用して、カウンター、ヒストグラム、ゲージ、アップダウンカウンターなど、すべての OTel メトリクスタイプをカバーするカスタムメトリクスを出力します。例えば、アプリは API レスポンス時間を測定する latency_time ヒストグラムを定義しています。

from opentelemetry import metrics
meter = metrics.get_meter(__name__)

# Histogram --- measures API latency distribution
latency_time = meter.create_histogram(
  name="latency_time",
  description="Measures latency time",
  unit="ms",
)

サンプルアプリケーションのデプロイ

サンプルアプリケーションとすべてのデプロイマニフェストは、GitHub の aws-otel-community リポジトリにあります。先ほどデプロイした Container Insights アドオンには、OpenTelemetry コレクターとして機能する CloudWatch エージェントが含まれています。OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定して、サンプルアプリをエージェントに向けます: http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317

このウォークスルーでは CloudWatch エージェントを使用していますが、OTLP/HTTP をサポートする任意の OpenTelemetry 互換コレクターや SDK を使用して、CloudWatch OTLP エンドポイントに直接メトリクスを送信できます。

PromQL でアプリケーションメトリクスをクエリする

アプリケーションをデプロイしたら、CloudWatch Query Studio を開くか、Amazon Managed Grafana ワークスペースで Explore に移動し、CloudWatch PromQL データソースを選択します。

以下のクエリは、Amazon Managed Grafana でデモアプリの p99 レイテンシーを、自動エンリッチされた @aws.region ラベルでグループ化して表示します。

histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))`

エンリッチメントが有効になっているため、すべてのアプリケーションメトリクスに AWS リソースコンテキストが自動的に付与されます。例えば、cpu_usage をクエリすると、追加の計装なしで以下のラベルが返されます。

料金

OTLP 取り込み機能と PromQL クエリは、プレビュー期間中は追加料金なしで利用できます。現在の料金の詳細については、Amazon CloudWatch の料金ページをご覧ください。

このウォークスルーで使用した Amazon EKS と Amazon Managed Grafana のリソースは、標準料金で課金されます。継続的な課金を避けるため、ウォークスルー終了後は次のセクションのクリーンアップ手順に従ってください。

クリーンアップ

• サンプルアプリケーションを削除します。

kubectl delete -f demo-app.yaml

• EKS クラスターから Amazon CloudWatch Observability アドオンを削除します。

aws eks delete-addon \
 --cluster-name \
 --addon-name amazon-cloudwatch-observability

• Grafana ワークスペースから Prometheus データソースを削除します (Grafana コンソールにログインし、Data Sources に移動して、設定した CloudWatch PromQL データソースを削除します)。

• Amazon Managed Grafana ワークスペースを削除します (このウォークスルー用に作成した場合のみ)。

aws grafana delete-workspace --workspace-id 

• Amazon EKS クラスターを削除します (このウォークスルー用に作成した場合のみ)。

aws eks delete-cluster --name 

• OTel エンリッチメントを無効にします (アカウントで不要になった場合)。

# Disable OTel enrichment
aws cloudwatch stop-o-tel-enrichment

# Disable telemetry enrichment
aws observabilityadmin stop-telemetry-enrichment

• このウォークスルー用にアタッチした IAM ポリシーをデタッチします。

aws iam detach-role-policy \
 --role-name \
 --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

まとめ

本記事では、Amazon CloudWatch でのネイティブ OpenTelemetry メトリクス取り込みについて説明しました。エンリッチメントレイヤーの有効化、Amazon EKS への Container Insights のデプロイ、OpenTelemetry SDK でのカスタムアプリケーションメトリクスの送信、PromQL でのクエリを紹介しました。

このプレビュー機能により、メトリクスパイプラインを CloudWatch に統合できます。拡張されたラベル制限を持つ高カーディナリティメトリクス、PromQL クエリ、AWS リソースの自動エンリッチメントが連携し、インフラストラクチャメトリクス、コンテナメトリクス、アプリケーションメトリクスがすべて同じパイプラインを流れ、同じ AWS リソースコンテキストを持つようになります。別々のバックエンド、エクスポーター、AWS メトリクスを統合ビューに取り込むための追加 API 呼び出しは不要です。

OpenTelemetry を使ったアプリケーションレベルの計装の実践例については、以下のリソースをご覧ください。

• AWS Observability Best Practices Guide: OpenTelemetry SDK でアプリケーションを計装するパターン
• One Observability Workshop: AWS でのメトリクス、トレース、ログのハンズオンラボ
• AWS Observability Accelerator: テレメトリ収集とクエリを自動化する CDK パターンと Terraform モジュール

プレビューは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で追加料金なしで利用できます。開始するには、アカウントでエンリッチメントレイヤーを有効にし、Amazon EKS クラスターに CloudWatch Observability アドオンをデプロイしてください。

翻訳はソリューションアーキテクトの大西朔が担当しました。原文はこちらです。

著者について