メトリクス

概要

メトリクスは、システムの状態を「時刻付きの数値」として一定間隔で記録し続けたデータです。毎秒のリクエスト数、CPU使用率、応答時間、エラー件数 — どれも「名前 + ラベル + 時刻 + 数値」という小さな組の連なり、つまり時系列データとして表現されます。運用のダッシュボードに並ぶ折れ線グラフの正体は、ほぼすべてこのメトリクスです。

出来事を一件ずつ文章として残すログと比べると、メトリクスは最初から集計された数値なので圧倒的に軽く、何か月分でも安価に保存でき、「先週と比べてどうか」「異常な傾向はないか」という問いに即座に答えられます。その代わり、集計の過程で個別のリクエストの事情は失われます。この「軽くて俯瞰に強いが、詳細は語らない」という性格が、監視や可観測性の中でメトリクスが担う役割を決めています。

なぜ生まれたか

数値による計測そのものは、SNMPで機器の状態を取得していた時代から存在します。しかし当時の関心は「サーバやルータという機械が生きているか」でした。Webサービスの規模が拡大し、分散システム化が進むと、問いは「機械が生きているか」から「サービスとしてユーザーに価値を提供できているか」へ移ります。数百台のサーバの1台が落ちても誰も困らないが、決済のエラー率が0.1%から2%に上がったら大問題 — この問いに答えるには、機械ではなくアプリケーション自身が「リクエスト数・エラー数・処理時間」を数値として吐き出し、それを横断的に集計・保存・検索できる基盤が必要でした。

さらに、コンテナやKubernetesの普及で「観測対象が数分で生まれては消える」環境になると、ホスト名ベースの旧来の監視は破綻します。対象をラベル（サービス名・環境・バージョンなど）で多次元的に識別し、任意の軸で集計し直せるデータモデルが求められ、Google内部のBorgmonを源流とするPrometheus（2012年〜）がこのモデルを広めました。現在の「ラベル付き時系列」というメトリクスの標準形は、この系譜の産物です。

詳細

3つの基本型 — カウンタ・ゲージ・ヒストグラム

メトリクスには数値の性質によって基本型があります。カウンタは「増える一方の累積値」で、リクエスト総数や総エラー数など。値そのものではなく、時間あたりの増分（レート）に変換して「毎秒何件か」を見ます。再起動でゼロに戻っても、増分で見ていれば影響を受けません。ゲージは「上下する現在値」で、CPU使用率・メモリ使用量・キューの長さなど、その瞬間のスナップショットに意味がある値です。ヒストグラムは「値の分布」で、応答時間のように1つの数値に潰すと嘘になるものに使います。応答時間を平均で見ると、大多数の速いリクエストに隠れて一部の極端に遅いリクエストが見えなくなるため、実務では「95パーセンタイル（p95、遅い方から5%目の値）」「p99」といった分位点で語るのが定石です。

収集と保存 — Pull/Push と時系列データベース

メトリクスの収集方式には二派あります。Pull型は監視サーバ側が定期的に各対象の公開エンドポイント（Prometheusなら /metrics）へ取りに行く方式で、監視対象の一覧を監視側が把握しているため「取りに行ったのに応答がない = 死んでいる」という死活判定が自然にできます。Push型は各対象がメトリクスを送りつける方式で、実行が終わると消えてしまうサーバレスの関数やバッチ処理のように「取りに行くタイミングでは既に存在しない」対象に向きます。実際の基盤は両方式を併用することが多く、OpenTelemetryのコレクタのように中継役を置いてどちらの経路も受けられる構成が一般的です。

集めたデータの保存先が時系列データベース（TSDB）です。「時刻順に追記され、ほぼ更新されず、直近ほど頻繁に読まれる」という時系列特有のアクセスパターンに最適化されており、汎用のRDBMSよりも桁違いの圧縮率と書き込み性能を実現します。古いデータほど解像度を落として保持する（直近は15秒間隔、1年前は1時間間隔など）ダウンサンプリングも典型的な機能です。代表的な実装にPrometheus、InfluxDB、長期保存・水平展開を担うThanosやMimirなどがあります。

何を測るか — RED と USE

「メトリクスは何百種類も取れるが、まず何を見るべきか」に対する定番の答えが2つのメソッドです。REDメソッドはリクエストを受けるサービス向けで、Rate（毎秒のリクエスト数）・Errors（失敗の数）・Duration（処理時間の分布）の3つを見ます。ユーザー体験に直結する指標であり、マイクロサービスの各サービスに一律に適用できるのが強みです。USEメソッドはCPU・メモリ・ディスクといった資源向けで、Utilization（使用率）・Saturation（飽和、処理しきれず待たされている量）・Errors（エラー）を見ます。「サービスの健康はREDで、資源の健康はUSEで」と覚えておくと、ダッシュボード設計の出発点になります。ここで定義したエラー率や応答時間はそのままSLOの計測材料になり、閾値を超えたときにアラートを発報する条件式の入力にもなります。

落とし穴 — カーディナリティ爆発

メトリクス設計の最大の落とし穴がカーディナリティ爆発です。時系列はラベルの値の組み合わせごとに1本作られるため、ユーザーIDやURLのパス全体のような「値が無限に増えるもの」をラベルにすると、時系列の本数が爆発してTSDBのメモリと保存領域を食い潰します。ラベルには「サービス名・環境・ステータスコード」のような値の種類が有限なものだけを使い、個別の事情を追いたければログや分散トレーシングに任せる — この住み分けが、メトリクスを長く安価に運用するための基本原則です。