CloudWatchカスタムメトリクス（PutMetricData・ディメンション）難易度 標準無料
運用チームが、自社のバッチ処理アプリケーションから「キュー内の未処理ジョブ件数」というアプリケーション固有の指標をCloudWatchへ送信し、環境（Environment=prod/stg）とキュー名（QueueName=orders/invoices）の両方で絞り込んで閲覧・アラーム設定できるようにしたい。この要件を満たす実装として最も適切なものを選べ。（単一選択）
- Aアプリケーションから
PutMetricDataを呼び出し、1つのメトリクスデータポイントにEnvironmentとQueueNameの2つのディメンションを付与して送信する - B環境とキュー名の組み合わせごとに、
QueueDepth-prod-ordersのようにメトリクス名自体を分けて送信する - CCloudWatch Logsへログとして未処理ジョブ件数を出力するだけにし、メトリクスとしては扱わない。アラームはLogs Insightsのクエリ結果を都度手動確認して判断する
- DAWS管理の標準メトリクス（AWS/SQS名前空間の
ApproximateNumberOfMessagesVisible）をそのまま流用し、アプリケーション側からの送信は行わない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
AWSの標準サービスが提供しない独自の指標は、CloudWatchカスタムメトリクスとしてアプリケーション側から
PutMetricData APIで送信する。
- 1回の
PutMetricData呼び出しには、名前空間（Namespace）・メトリクス名（MetricName）・値（Value）に加えて、 ディメンション（Dimensions）をキー・バリューのペアとして複数付与できる（1メトリクスあたり最大30ディメンション）。 - 本問のように環境とキュー名の両方で絞り込みたい場合は、
EnvironmentとQueueNameという 2つのディメンションを同じメトリクスデータポイントに付与すればよい。CloudWatchコンソールでは、 ディメンションの組み合わせごとに個別の時系列として自動的に集計・表示され、アラームも特定のディメンションの組み合わせに対して設定できる。 - デフォルトの解像度（標準解像度）は60秒単位で、より高頻度（1秒単位）が必要な場合は
StorageResolution: 1を指定した高解像度カスタムメトリクスにできる。
- B組み合わせが増えるたびにメトリクス数が増殖しコスト・管理性が悪化する。ディメンションを使えば1つのメトリクス名のまま複数軸で絞り込める。
- C手動確認では自動アラームによる即時検知ができず運用性が低い。数値指標として継続監視・アラーム設定したい要件にはメトリクスとして送信する方が適切。
- D設問は自社アプリケーション独自のキュー実装を前提としており、SQSを使っているとは限らない。AWS標準メトリクスが存在しない独自指標にはカスタムメトリクスの送信が必要。
ひっかけ： 「メトリクス名を
QueueDepth-prod-ordersのように連結して1つのメトリクスにする（B）」は一見動きそうだが、
組み合わせが増えるたびにメトリクス数が線形に増加しコスト・管理性が悪化し、CloudWatch側の柔軟な絞り込み（ディメンションでのフィルタ）が使えなくなる。
複数軸で絞り込みたい場合はディメンションを使うのが定石である。公式ドキュメント・関連Amazon CloudWatch User Guide ― Publish custom metrics↗Amazon CloudWatch User Guide ― Dimensions↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）