66. メトリクスは名前つきの時系列である — 名前空間×名前×ディメンションが1本の線を決める
CloudWatchの「メトリクス」という言葉に身構える必要はありません。その正体は時系列データベースのデータモデル——「どうやって1本の線を一意に決めるか」というルールの集まりです。名前空間・名前・ディメンションの3つがどう組み合わさって1本の時系列を指し示すのか、そこから何が引けて何が引けないのかを、図で追っていきます。
① メトリクスは時間順の値の列
- 公式表現「A metric represents a time-ordered set of data points」
- データポイント = タイムスタンプ + 値 +(任意で)単位(Bytes / Seconds / Count / Percent など)
- 単位を省くと CloudWatch は None を使う
メトリクスとは「監視したい1つの変数」であり、その中身は時間順に並んだ (タイムスタンプ, 値, 任意の単位) の列です。EC2インスタンスのCPU使用率が「1つのメトリクス」で、時々刻々の測定値が「データポイント」——この時系列という土台をまず押さえます。
② 複合キーが1本の線を決める
- 公式表現「Metrics are uniquely defined by a name, a namespace, and zero or more dimensions」
- ディメンションは「name/value pair that is part of the identity of a metric」——1メトリクスに最大30個
- 「whenever you add a unique name/value pair … you are creating a new variation of that metric」
- 例の名前空間は DataCenterMetric、メトリクス名は ServerStats
- 時系列DB一般では「メトリクス名+タグの組=シリーズのキー」と呼ぶ。CloudWatchの3要素はその一実装
1本のメトリクスは「名前空間+メトリクス名+0〜30個のディメンション(名前/値ペア)」の組で一意に決まります。ディメンションは飾りではなくアイデンティティの一部なので、ペアが1つ違えばそれは別のメトリクス——DynamoDB編で見た「パーティションキー+ソートキーで1項目が一意に決まる」複合キーとまったく同じ構図です。
③ 部分一致では引けない
- 「You can only retrieve statistics using combinations of dimensions that you specifically published」
- 「CloudWatch does not aggregate across dimensions for your custom metrics」
- 唯一の抜け道は metric math の SEARCH 関数
- 「あとで Server だけで合計したい」なら、そのための集計済みメトリクスを別途自分で発行しておく
ディメンションの組は複合キーの一部なので、Server=Prod,Domain=Frankfurt で発行したデータは Server=Prod だけでは取り出せません。DynamoDBで「パーティションキーだけ、ソートキーだけ」では項目を引けなかったのと同じ理屈で、キーの一部を指定してもそれは「別のキー」を指しているだけ——部分一致という概念がそもそも存在しません。
④ 高カーディナリティは線を爆発させる
- 根拠は②のルール「creating a new variation of that metric」の帰結(公式の直接の警告文ではなく、ルールから導かれる帰結)
- 判断基準: そのディメンションで「グラフを引きたい/アラームを張りたい」軸になるか? YES→ディメンションにする / NO→しない
「ペアが1つ違えば別メトリクス」というルールは、値の種類が多いディメンション(requestId、ユーザーID、URLパスなど)を入れるとメトリクス数が爆発することを意味します。ディメンションは「後で集計・比較の軸にしたい、値の種類が少ない属性」に限定するのが原則です。
⑤ 名前空間は隔離の壁
- 「There is no default namespace. You must specify a namespace for each data point you publish」
- 「Metrics in different namespaces are isolated from each other」
- 公式は「typically use the following naming convention: AWS/{service}」(EC2→AWS/EC2, S3→AWS/S3, Lambda→AWS/Lambda)
名前空間はメトリクスの入れ物であり、隔離の境界線です。デフォルトは存在せず発行のたびに必ず指定が要り、AWSサービスは通常 AWS/{service} の規約で自分の名前空間を持つので、あなたのアプリのメトリクスが AWS/EC2 の統計に紛れ込むことはありません。API Gateway編で見た「境界が違えば互いに干渉しない」という隔離の考え方と同じで、名前空間は統計の集約単位であると同時に、他人のデータと混ざらないための壁でもあります。
⑥ 時間・寿命・場所・向き — 4つの境界
- タイムスタンプ: 「up to two weeks in the past and up to two hours into the future」
- 「Metrics cannot be deleted, but they automatically expire after 15 months if no new data is published」(古いデータポイントはローリングで15ヶ月で脱落)
- 2週間データが来ないとコンソール一覧・list-metrics からは消える(get-metric-data / get-metric-statistics では取得可)
- 「Metrics exist only in the Region in which they are created」
- 「CloudWatch doesn't pull metrics … it only receives what is pushed to it」
1本の線を決めるキーの話が済んだら、残りは4つの境界です——受け付ける時間の窓(過去2週間〜未来2時間)、寿命(削除不可・15ヶ月無投入で自動失効)、場所(リージョンに閉じる)、向き(プル型ではなくプッシュ型で、送られたものだけを記録)。
⑦ 補足: OpenTelemetryメトリクス
- 「OpenTelemetry metrics support up to 150 labels per metric」
- ラベル(key-value)はディメンションと似た役割だが、OpenTelemetry のセマンティック規約に従う
- PromQL照会は Query Studio / Prometheus互換API 経由
- 新規実装には OpenTelemetry が推奨される(publishingMetrics.html 冒頭 Note)
本編で扱った「名前空間+ディメンション」は従来モデルの語彙です。CloudWatchはこれとは別に、OTLPで送られメトリクス名+最大150ラベルで識別されPromQLで照会するOpenTelemetryメトリクスも受け付けるようになりました——データモデルの詳細は別レッスンに譲りますが、まとめると、CloudWatchメトリクスの正体は時系列DBのデータモデルであり、「名前空間+名前+ディメンションの組」という複合キーが1本の線を一意に決める——だから部分一致では引けず、高カーディナリティなディメンションは線を爆発させ、キーは時間・寿命・リージョン・プッシュという4つの境界の中で生きるのです。