のメトリクスを に送って PromQL で見てみた からそのまま使える？ OpenTelemetry CloudWatch 計測コードとクエリは Prometheus 2026/09/11 JAWS-UG 山梨 #13 太田 暢 @iorandd Copyright © 3-shake, Inc. All Rights Reserved. 

自己紹介 太田 暢 株式会社スリーシェイク Sreake事業部 アプリケーション開発支援チーム バックエンド、CI/CDまわりを担当 好きな AWS サービスは Amazon ECS 2026 Japan AWS Jr. Champions 𝕏 @iorandd 2 

CloudWatch OpenTelemetry が の native OTel metrics のメトリクスを専用形式への変換なしで保存できるようになった クエリ対応のネイティブ メトリクスと 単位の料金体系を導入 Amazon CloudWatch PromQL OpenTelemetry GB https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-cloudwatch-otel-metrics/ 3 

メトリクス保存先の切替 保存先を替えても計測コードとクエリはそのまま使える？ 公開デモ OpenTelemetry Demo の配送 API shipping を題材として、 リクエストを受けてから応答するまでを計測 値を Prometheus に保存し Grafana で見る アプリと毎秒 1 件のリクエストを変えずに 保存先を Prometheus から CloudWatch へ切り替えてみる の OpenTelemetry Demo 3.0.0 shipping https://github.com/open-telemetry/opentelemetry-demo/tree/3.0.0/src/shipping 4 

想定する Prometheus への保存経路 （ ・ ・ ） の各ドキュメント OpenTelemetry SDK OTLP Collector / Prometheus / Grafana https://opentelemetry.io/docs/ / https://prometheus.io/docs/ / https://grafana.com/docs/ 5 

Collector OTLP 以降の送信先と参照先 と PromQL が共通なら送信先の変更だけで済む？ Prometheus OTLP receiver / Send OpenTelemetry metrics to CloudWatch https://prometheus.io/docs/guides/opentelemetry/ / https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-otel-send.html 6 

上の検証環境 ECS Fargate ※ タスクは複数のコンテナをまとめて起動する単位 検証環境 Ota1022/cloudwatch-otel-metrics-ecs-fargate https://github.com/Ota1022/cloudwatch-otel-metrics-ecs-fargate 7 

変わること① 設定方法 観点 Prometheus 経路（Demo 3.0.0 の設定） アプリ計装 OTel SDK アプリから Collector OTLP Collector から保存先 Prometheus OTLP receiver メトリクス名 http_server_request_duration_seconds_* 属性名 http_route / service_name Prometheus CloudWatch 経路 OTel SDK OTLP OTLP endpoint + SigV4 + IAM http.server.request.duration http.route / @resource.service.name 切替時 維持 維持 変更 変更 変更 側の名前の変換と属性の扱いは OTLP receiver の設定で変わる ※ SigV4 は AWS への API リクエストに IAM の認証情報で署名する方式 8 

変わること② ヒストグラムの保存形式 同じ集計結果でも保存先で系列の分かれ方が変わる OTel SDK が応答時間をヒストグラムに集計 値を区間ごとの件数にまとめる形式。区間をバケットと呼ぶ 計測例 0.12 / 0.24 / 0.48 / 1.20 / 5.00 秒 → 件数 5・合計 7.04 秒 バケット別件数 0.5 秒以下 3件 ｜ 0.5〜1秒 0件 ｜ 1〜2.5秒 1件 ｜ 2.5〜5秒 1件 Prometheus 合計・件数・バケット別件数を 別々の系列に分けて保存 は の設定 CloudWatch 合計・件数・バケット別件数を 1つのヒストグラムとして保存 ※ 系列は同じ名前と属性を持つ測定値の時系列 Prometheus Demo 3.0.0 OpenTelemetry Metrics Data Model https://opentelemetry.io/docs/specs/otel/metrics/data-model/#histogram 9 

平均応答時間の PromQL 平均応答時間 = 合計時間の増加量 ÷ 件数の増加量 Prometheus CloudWatch 合計時間の増加量 合計時間の増加量 件数の増加量 件数の増加量 別々の系列から合計と件数を読む で1つのヒストグラムから取り出す ※ rate は1秒あたりの増加量を求める関数 PromQL in CloudWatch https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-PromQL.html 10 

クエリを書き換えれば、ちゃんと同じ現象を観測できるか 配送 API に 5 秒の遅延を入れて 3 指標を確認 毎秒 1 件のリクエストに 5 秒の待機を追加 リクエスト 1 リクエスト 2 リクエスト 3 リクエスト 4 リクエスト 5 リクエスト 6 0 1 応答時間 約5秒 2 3 4 5 完了レート 約 1 件/秒 6 7 切替後 5 分待機 → 続く 3 分間を 15 秒刻みで評価 8 9 同時実⾏数 10 秒 約5 11 

Prometheus 経路の実測 実測 5.002 秒 判定範囲 5.0〜5.2 秒 実測 実測 判定範囲 0.95〜1.05 件/秒 判定範囲 4〜6 0.997〜1.000 件/秒 3 指標とも全 13 点が判定範囲内 5 12 

CloudWatch 経路の実測 保存先に合わせてクエリを書き換えても同じ遅延状態を観測できた 実測 5.002〜5.003 秒 判定範囲 5.0〜5.2 秒 実測 実測 判定範囲 0.95〜1.05 件/秒 判定範囲 4〜6 0.979〜1.018 件/秒 3 指標とも全 13 点が判定範囲内 ※ 別時刻の実行のため保存先の性能の優劣は比較しない CloudWatch の完了レートが細かく揺れるのは 15 秒刻みの再標本化でウィンドウに入る標本数が変わるため 5 13 

まとめ 計測コードを変えずに保存先を CloudWatch へ置き換えられるようになった そのまま使える アプリの OTel 計装コード Collector までの OTLP 送信 保存先に合わせて変更 の送信先設定 Collector OTLP endpoint / SigV4 / IAM （ ） メトリクス名・属性・ヒストグラ ム表現に合わせた PromQL 14