OpenTelemetryで変わった 新時代のCloudWatchメトリクス監視

1. OpenTelemetryで変わった 新時代のCloudWatchメトリクス監視 2026/11/15 JAWS-UG千葉⽀部 x 東葛.dev コラボLT⼤会
2. ⾃⼰紹介 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. バックエンドエンジニア：2年 • • 部署 ◦ クラウド事業本部 ◦ モダンアプリコンサルチーム ニックネーム ◦ • • つくぼし SNS/ブログ ◦ X(@tsukuboshi0755) ◦ DevelopersIO(つくぼし) ⼀⾔ ◦ 取⼿の王道家よく⾏ってました 2
3. 導⼊ ここ最近のCloudWatchの変化を知ってますか？ 3
4. ⼀番⼤きな変化 CloudWatch独⾃のメトリクス‧アラームがClassic扱いになり、 OSSであるOpenTelemetry準拠のメトリクス‧アラームが推奨になった事 4
5. つまり 5 CloudWatchメトリクスのベストプラクティスが 以前から⼤きく変わったので把握する必要があります！
6. 対象者 • ClassicのCloudWatchのメトリクス‧アラームしか知らな い⼈ • ここ最近のCloudWatchアップデートがよくわからない⼈ • CloudWatchネイティブな構成でオブザーバビリティに関 して検討したい⼈ 6
7. ⽬次 1. Classic metricsとOpenTelemetry metricsの違い 2. OpenTelemetry metricsを使う際のパターン別構成 3. まとめ 7
8. Classic metricsとOpenTelemetry metricsの違い
9. 9 そもそもOpenTelemetry metricsに 切り替えるべきか？
10. OpenTelemetry対応済のCloudWatch主要機能 10 シグナル 送り先(OTLP) 保存先 ⾒る機能 メトリクス https://monitoring.{regi on}.amazonaws.com/v1 /metrics OpenTelemetry metrics PromQL(Query Studio) ログ https://logs.{region}.ama zonaws.com/v1/logs CloudWatch Logs ロググループ Logs Insights‧Live Tail トレース https://xray.{region}.ama zonaws.com/v1/traces CloudWatch Logs ロググループ aws/spans Transaction Search Application Signals
11. Classic metricsとOTel metricsの主な違い 観点 Classic Metrics OTel Metrics 送り⽅ PutMetricData‧EMF OTLP クエリ Metrics Insights(SQL) PromQL アラーム 標準アラーム PromQLアラーム 分類 ディメンション ラベル 料⾦形態 メトリクス数 取り込みGB 11
12. 最新のAWSメトリクスデータの流れ 12 AWS標準メトリクス カスタムメトリクス (AWS SDK / EMFライブラリ) PutMetricData / EMF Classic metrics 標準アラーム‧ Metrics Insights(SQL) OTelエンリッチメント(任意) カスタムメトリクス (OTel SDK/ Collector) OTLP OpenTelemetry metrics PromQLアラーム‧ PromQL
13. Query StudioにおけるPromQLの例 13
14. メトリクス分類における考え⽅の違い Classic Metrics： ディメンションごとに別のメトリクス 14 OTel Metrics： 1つのメトリクスをラベルで分ける メトリクス名 ディメンション メトリクス名 Invocations FunctionName=A Invocations ＝ 1メトリクス 12 8 メトリクス名 ディメンション Invocations FunctionName=B ＝ 1メトリクス 3 5 ラベル … … ＝ 1メトリクス データポイント 系列① FunctionName=A 12 8 … 系列② FunctionName=B 3 5 … sum(Invocations) で A と B を合計できる → メトリクスを2としてメトリクス数で課⾦ → メトリクスは1のままデータポイントの量(GB)で課⾦ ディメンションは1メトリクスに30個まで ラベルは1データポイントに150個まで
15. カスタムメトリクス料⾦例 15 Classic：メトリクス数 × $0.30/⽉ OTel：取り込みGB × $0.50 パターン Classic OTel 有利 5,000メトリクスを60秒ごと ⽉$1,497 ⽉$54 OTel ⽉$27 ⽉$1.08 OTel ⽉$0.30 ⽉$0.12 OTel 10メトリクス以内を60秒ごと 無料枠内 ⽉$0.11 Classic (取り込み108GB想定) 100メトリクスを60秒ごと (取り込み2.16GB想定) 11メトリクスを60秒ごと (取り込み0.24GB想定) (取り込み0.22GB想定) 1データポイント500バイト‧1か⽉30⽇、バージニア北部の単価で計算。PutMetricDataのAPI料⾦は含まない。 出典: Amazon CloudWatch 料⾦
16. AWS標準メトリクスも⾒るなら：OTelエンリッチメントの有効化 リージョン毎にOTelエンリッチメントをONにするだけで、SDK/Collector なしでAWS標準メトリクスがPromQLで確認可能。 16
17. Classicメトリクスは移⾏するべきか？ • 既存のカスタムメトリクス：数が多いならOTel metricsに移すと得 ◦ 無料枠を超えるなら試算し、移⾏の⼿間と⽐較すると良さげ。 ◦ 移すならアプリにOTel SDKを⾜して両⽅に送り、確かめてから切り 替える • 新しく作るカスタムメトリクス：最初からOTel metricsがオススメ ◦ カスタムメトリクスの数が増えると料⾦の⾯で有利になりやすい • AWS標準メトリクス：移⾏しなくて良い ◦ PromQLで⾒たいならOTelエンリッチメントをONにするだけ ◦ ただしエンリッチメントした分はGB単位で追加課⾦ 出典: Amazon CloudWatch ユーザーガイド「Migrate from Classic to OTel metrics」 17
18. 18 AWS標準メトリクスはClassic版で問題なし 新しく作るカスタムメトリクスはOTel版にしよう
19. OpenTelemetry metricsを使う際のパターン別構成
20. 20 OpenTelemetry metricsを使う場合、 送信⽅法は何をつかうべきか？
21. OpenTelemetry送信経路のパターン別全体像 送信元 送信⽅法 受信⼝ Collectorあり 21 保存 活⽤ AWS標準メトリクス EC2 CloudWatch agent OTelエンリッチメント(任意) ECS OpenTelemetry Collector (Contrib / ADOT) EKS 独⾃構成のCollector AWSの外 (オンプレ‧他クラウド) Collectorなし Lambda (ADOTレイヤー) ADOT SDK(直接) CloudWatch OTLP エンドポイント OpenTelemetry metrics PromQLで問い合わせ (Query Studio) アラーム ダッシュボード 異常検知
22. 送信パターンA：CloudWatch agent • AWSが作って保守しているCollector。公式の推奨 ◦ Collector＝アプリのデータを受け取りCloudWatchへ送る中継役 • agentの設定ファイルに数⾏⾜すだけで使える ◦ AWSへの認証や送信先の設定はagentに任せられる • 置き⽅は実⾏環境で変わる ◦ EC2：インスタンスに⼊れる ◦ ECS：Fargateならサイドカーコンテナ、Managed Instancesなら Managed Daemons、EC2ならデーモン戦略で置く ◦ EKS：Fargateならサイドカーコンテナ、Auto ModeやEC2なら CloudWatch Observabilityアドオンで⼊れる 22
23. 送信パターンB：OpenTelemetry Collector • コミュニティやAWSが配布しているOSSのCollectorをそのまま使う ◦ Contrib：コミュニティが配布。モジュールがほぼ全部⼊り ◦ ADOT Collector：AWSが配布。AWSのサポートを受けられる • 送信先とAWSへの認証を、⾃分で設定ファイルに書く ◦ どちらの配布版にもAWS認証のモジュールが⼊っている • すでにCollectorやPrometheusを使っているとき向け ◦ AWSでもオンプレでも他クラウドでも同じ設定で動く ◦ Application SignalsやContainer Insightsとは連携しない 23
24. 送信パターンC：独⾃構成のCollector • 必要なモジュールを選んで、⾃分専⽤のCollectorを組み⽴てる ◦ 公式のビルドツールにCloudWatch向けのモジュールを指定して作る • パターンBではできないApplication Signals連携ができる ◦ Container Insightsは対象外 • 配布版に⼊っていないモジュールや処理が要るとき向け ◦ ビルドとバージョン追従を⾃分で続ける必要がある 24
25. 送信パターンD：ADOT SDK(直接) • Collectorを置かず、アプリから直接CloudWatchへ送る ◦ ADOT SDK＝AWSが配っているOpenTelemetryのライブラリ ◦ Java‧Node.js‧Python‧.NETに対応 • 置くものが少なく、⼀番早く試せる ◦ 加⼯や絞り込みはアプリ側でしかできない • 常駐のagentを置けないLambdaはこの形が推奨 ◦ ADOTのレイヤーを関数に追加して使う 25
26. どの送り⽅を選ぶか 26 観点 CloudWatch agent OpenTelemetry Collector 独⾃構成の Collector ADOT SDK(直接) 運⽤の⼿間 agentの運⽤ Collectorの運⽤ ビルド＋運⽤ ⼩さい Application Signals ◦ × ◦ ◦ Container Insights ◦ × × × 送れるデータ ログ‧メトリクス‧ トレース ログ‧メトリクス‧ トレース ログ‧メトリクス‧ トレース メトリクス‧トレー ス 向いている場⾯ 優先して検討 既存のCollector資産 配布版にないモ ジュールが要る PoC‧Lambda
27. 27 まずCollectorを置くかを決めよう Collectorで迷ったらCloudWatch agent経由
28. 最後に
29. まとめ • AWS標準メトリクスはClassic版で問題なし。新しく作るカスタムメトリ クスはOTel版にしよう • まずCollectorを置くかを決めよう。迷ったらCloudWatch agent経由 29
30. 今⽇⾔いたかった事 30 CloudWatchの監視ベストプラクティスが変わりつつあるのでキャッチアップしよう！