CloudWatch が OpenTelemetry メトリクスをサポートし、OTLP エンドポイント経由でのメトリクス送信や PromQL を利用したクエリやアラーム設定が可能になりました (Public Preview)
アップデート概要
CloudWatch が OpenTelemetry メトリクスをサポートしました。
これまでもトレース、ログ用の OTLP エンドポイントは提供されていましたが、今回メトリクス用のエンドポイントが追加され、主要 3 シグナルすべてを OTLP エンドポイント経由で CloudWatch に送信可能になりました。
| シグナル | エンドポイント URL パターン | ステータス |
|---|---|---|
| Traces | https://xray.{Region}.amazonaws.com/v1/traces |
既存 (GA) |
| Logs | https://logs.{Region}.amazonaws.com/v1/logs |
既存 (GA) |
| Metrics | https://monitoring.{Region}.amazonaws.com/v1/metrics |
今回追加 (Public Preview) |
OTLP Endpoints - Amazon CloudWatch
合わせて、下記機能が追加されています。
- PromQL でクエリを行うことができるようになった (Query Studio という専用のエディタが追加)。
- PromQL でアラームを定義することができるようになった。
- AWS 提供のメトリクスを OpenTelemetry 標準に沿った形で扱えるようになった。
2026 年 4 月 5 日時点ではパブリックプレビューとなり、対象リージョンは下記の通りです。
| リージョン名 | リージョンコード |
|---|---|
| US East (N. Virginia) | us-east-1 |
| US West (Oregon) | us-west-2 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Europe (Ireland) | eu-west-1 |
本ブログでは、これらの機能を実際に試してみます。
やってみた
OTLP エンドポイントを利用してメトリクス、ログ、トレースを送信してみる
us-east-1 リージョンを利用し、下記構成で試してみます。
※ 一応 CloudWatch と X-Ray を書き分けていますが、X-Ray は CloudWatch のトレース機能として統合されているため、まとめて CloudWatch と表現した方が正確かもしれません。
Docker コンテナのメトリクスは、Docker Stats Receiver を利用して OpenTelemetry Collector に取得させます。
otel-collector-config.yaml 全体としては下記のようになります。
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
docker_stats:
endpoint: unix:///var/run/docker.sock
collection_interval: 60s
exporters:
otlphttp/logs:
compression: gzip
logs_endpoint: https://logs.us-east-1.amazonaws.com/v1/logs
headers:
x-aws-log-group: otel-test # ロググループ名
x-aws-log-stream: default # ログストリーム名
auth:
authenticator: sigv4auth/logs
otlphttp/traces:
compression: gzip
traces_endpoint: https://xray.us-east-1.amazonaws.com/v1/traces
auth:
authenticator: sigv4auth/traces
otlphttp/metrics:
compression: gzip
metrics_endpoint: https://monitoring.us-east-1.amazonaws.com/v1/metrics
auth:
authenticator: sigv4auth/metrics
processors:
transform/metrics:
error_mode: ignore
metric_statements:
- context: resource
statements:
# CloudWatch OTLPは配列型属性を受け付けないため除去
- delete_key(attributes, "process.command_args")
extensions:
sigv4auth/logs:
region: "us-east-1"
service: "logs"
sigv4auth/traces:
region: "us-east-1"
service: "xray"
sigv4auth/metrics:
region: "us-east-1"
service: "monitoring"
service:
extensions: [sigv4auth/logs, sigv4auth/traces, sigv4auth/metrics]
pipelines:
logs:
receivers: [otlp]
exporters: [otlphttp/logs]
traces:
receivers: [otlp]
exporters: [otlphttp/traces]
metrics:
receivers: [otlp, docker_stats]
processors: [transform/metrics]
exporters: [otlphttp/metrics]
各シグナルに対応するエンドポイントを指定しつつ、SigV4 を利用して認証を行う形で、シンプルに設定できます。
注意が必要なケースとして、配列型の属性を含むメトリクスを送信する場合は、下記のようなエラーが発生します。
otel-collector-1 | 2026-04-05T06:35:05.874Z error internal/queue_sender.go:50 Exporting failed. Dropping data. {"resource": {"service.instance.id": "845d6e07-7dfe-46e2-b31c-ac105fc5585a", "service.name": "otelcol-contrib", "service.version": "0.143.0"}, "otelcol.component.id": "otlphttp/metrics", "otelcol.component.kind": "exporter", "otelcol.signal": "metrics", "error": "not retryable error: Permanent error: rpc error: code = InvalidArgument desc = error exporting items, request to https://monitoring.us-east-1.amazonaws.com/v1/metrics responded with HTTP Status Code 400, Message=Attribute value type is invalid [ResourceMetrics.1]., Details=[]", "dropped_items": 59}
CloudWatch において配列型の属性はサポートされていないため、最初は process.command_args を送信しようとしてエラーになりました。
otel-collector-1 | 2026-04-05T06:38:53.320Z info ResourceMetrics #0
otel-collector-1 | Resource SchemaURL:
otel-collector-1 | Resource attributes:
otel-collector-1 | -> host.name: Str(7814cd6749ef)
otel-collector-1 | -> host.arch: Str(arm64)
otel-collector-1 | -> process.pid: Int(1)
otel-collector-1 | -> process.executable.name: Str(node)
otel-collector-1 | -> process.executable.path: Str(/usr/local/bin/node)
otel-collector-1 | -> process.command_args: Slice(["/usr/local/bin/node","/app/dist/index.js"])
必要に応じて processors 等で処理する必要があり、今回はシンプルに process.command_args 属性を削除するようにしました。
OTLP メトリクスエンドポイントの話からは逸れますが、OTLP トレースエンドポイントを利用する際は Transaction Search を有効にする必要があったり、OTLP ログエンドポイントを利用する際は CloudWatch Logs のロググループとログストリームを事前に作成する必要があったりします。
この辺りは下記ブログに記載したので、もし興味があればご参照下さい。
その他、今回利用したコードは下記リポジトリで公開しています。
PromQL でクエリしてみる
Query Studio という専用のエディタが追加されており、PromQL メトリクスをクエリできました。
デフォルトだと、Metric や function、Label などを GUI で選択してクエリを組み立てる形になります。
エディタを切り替えることで、直接 PromQL を入力することも可能です。
属性を利用した集約クエリも可能です。
例えば下記では、ステータスコードごとのレイテンシを表示しています。
ラベル付きメトリクスを PromQL でクエリすると、表現力が高くてとても便利ですね。
OTel メトリクスエンドポイントを利用することで、埋め込みメトリクスフォーマット (EMF) を利用しなくてもカスタムメトリクスを送信可能です。
例えば下記では Node.js のランタイムメトリクスも取得できています。
EMF も便利ではありますが、全てのシグナルを同じスキームで扱うことができるのは魅力的です。
アップデート前から可能でしたが、もちろんログとトレースも OTLP エンドポイント経由で送信できています。
AWS 提供のメトリクスに対して OpenTelemetry エンリッチメントを有効化する
OpenTelemetry エンリッチメントを有効化することで、AWS 提供のメトリクスを OpenTelemetry 標準に沿った形で扱えるようになります。
下記構成をデプロイして、メトリクスを確認してみます。
ECS サービスの CPU 利用率を PromQL でクエリできました。
AWS 提供のメトリクスだと自動でリージョンやアカウント ID などの属性が付与されます。
また、リソースタグを利用したクエリも可能でした。
アカウント設定で「テレメトリでリソースタグを有効にする」を有効にするとタグを利用した集計ができますが、それと同じことが PromQL でもできるようです。
PromQL でアラームを定義する
続いて、PromQL でアラームを定義します。
アラームを作成する際、最初にクラシックか PromQL かを選択できるようになっています。
PromQL を選択すると、下記のようなエディタが表示されます。
PromQL でアラート定義を行って、アラート状態にすることもできました。
上記の例では、ラベル違いで複数系列に別れて表示されてしまっており、この辺は少し扱い辛かったです。
私の設定の仕方が悪いのかもしれないですが、avg by <ラベル> 等を指定しても、集約に利用したもの以外のラベル違いで系列が別れてしまいました。
この辺りは追って深堀ってみたいと思います。
最後に
OTel メトリクスエンドポイントが追加され、PromQL ベースでのクエリやアラート定義が可能になりました。
単に AWS 提供のメトリクスを扱うだけであれば現状 PromQL ベースでクエリできるメリットは薄いかもしれませんが、AWS 外から OpenTelemetry 形式で取得したメトリクスと AWS が提供するメトリクスの両方を同じように PromQL でクエリできるというのはとても良いです。
この辺りは What's New でも「Amazon EKS とオンプレミス サーバーでマイクロ サービスを実行しているチームは、両方の環境から OTel メトリクスを CloudWatch に直接送信できるようになりました」と表現されており、明確なメリットです。
昨年末の CloudWatch ログ周りのアップデートもそうですが、最近の CloudWatch は AWS 外のテレメトリもしっかりと取り込んで分析できるように機能を強化しているように見えます。
また、OTel メトリクスエンドポイントの追加と PromQL ベースでのクエリやアラーム定義が可能になったことで、今後はラベル付きメトリクスを CloudWatch で扱うことも増えそうです。
CloudWatch でもテレメトリ間の連携がより行いやすくなることが期待されます。
今後、PromQL ベースでのクエリやアラーム設定が推奨されるのかも気になります。
Google Cloud だと、既に旧来の方式 (MQL) が非推奨となり、PromQL でのクエリが推奨されています。
CloudWatch でもクラシックと書かれると早めに PromQL に移行した方が良い気がしちゃいますね...
まだパブリックプレビューということもあるので、この辺りの動向は追っておいた方が良いと思います。
個人的には OpenTelemetry 標準に寄っていくのはウェルカムなので、どんどんキャッチアップして情報を発信できたらなと思っています。
