メトリクス収集の設計 — Push型とPull型をどこで選ぶか

メトリクス収集の方式選定は、構築後に修正コストが跳ね上がる意思決定のひとつです。Push型かPull型かを「後から決める」と、短命なコンテナやオートスケール環境で計測が欠落し、障害時に根拠のないデータしか残らない状況に陥ります。本記事では、環境の特性・ネットワーク境界・カーディナリティの三軸から、収集方式をどの段階でどう選ぶかを解説します。

収集方式を決めずに始めて穴が空く構造

設計判断を先送りにしたときのツケ

メトリクス収集の設計を後回しにしたまま構築を進めると、後になって穴が見えてきます。「とりあえずNode Exporterを入れる」という判断は、静的なサーバーが10台以下の環境では問題が表面化しにくく、それで十分に見えます。しかし環境が30台・50台と広がるにつれ、Pull型前提の設計がオートスケールやコンテナ環境と噛み合わなくなる事例は現場で多く聞かれます。収集方式の変更はダッシュボード・アラート・データ保持設計のすべてに波及するため、最初の判断の重みは想像以上に大きいです。

Pull型前提で始めてコンテナが消えるパターン

PrometheusのようなPull型ツールは、スクレイプ対象のエンドポイントが安定して存在することを前提とします。AWS LambdaやKubernetesのJob系ワークロードのように、実行時間が数秒〜数分で完了する短命なワークロードは、PrometheusがPollしに行く前に消えてしまいます。構築を任されたある担当者がバッチ処理のメトリクスをPrometheusで収集しようとしたところ、スクレイプ間隔15秒の間に処理が終了し、成功率や処理件数がほぼ取得できなかったという話はよく聞きます。アラートが静かなことで「正常稼働しているから出ない」と誤認されるパターンも多く、設計レビューで明示的に指摘しないと見落とされがちです。

「後から追加」が難しい理由

途中でPush型に切り替える場合、StatsD等のUDPエンドポイントの追加だけでなく、既存のアラートルールをMetricsQL／PromQLから別のクエリ言語に移植する作業が発生します。環境数が20を超えた段階での方式変更は、実装工数が3倍以上になることもあります。ダッシュボードのクエリ・アラート定義・データ保持期間のすべてを手直しすることになるため、「動いているからこのまま行く」という判断が先送りを招きます。最初の設計判断がどれだけ後工程に影響するかを、構築フェーズの入り口で共有しておくことが重要です。

Push型が向く環境・Pull型が向く環境の違い

Push型が優位になる条件

Push型は「メトリクスを送る側がアクティブに発信する」方式です。短命なジョブ・バッチ処理・Lambdaなど常時起動していないワークロードでは、Push型が根本的に適しています。また、ファイアウォールの制約でインバウンドを開けられないDMZ内のサーバーや、エージェントのインストールが禁止されている共有ホスティング環境でも、アウトバウンドのHTTP／UDPは許可されていることが多く、Push型が現実的な選択肢となります。「収集側からポートを開けてもらう」交渉コストが高い組織では、この観点が技術選定の主因になることもあります。

Pull型が優位になる条件

Pull型は「収集基盤が対象をスクレイプする」方式です。常時稼働するサービス、特にHTTPエンドポイントを持つマイクロサービスや、Kubernetes上のPodのように動的に増減はするが起動時間は長いワークロードでは、Service Discoveryと組み合わせたPull型が管理コストを下げます。収集側が対象の死活状態を把握できるため、「エンドポイントが消えた＝サービスが落ちた」という検知を自動化しやすい点も強みです。また、どのターゲットをどの間隔でスクレイプするかの制御が収集側に集約されるため、監査・変更管理がしやすいという設計上の利点もあります。

ハイブリッドが現実解になるケース

多くの本番環境では、常時稼働のサービスとバッチジョブが混在します。この場合、Pull型（Prometheus）をベースにしながら、短命なジョブのみPushgateway経由でメトリクスを集約するハイブリッド構成が選ばれます。ただし、Pushgatewayはメトリクスの「墓場」になりやすく、ジョブが失敗しても最後にPushしたデータが残り続けるという落とし穴があります。設計段階でTTLや削除戦略（ジョブ完了時のDELETE APIコール）を決めておかないと、失敗したジョブの古いデータが「成功」に見えたまま残り続け、アラートが意図どおりに動きません。

Push / Pull / エージェント常駐の特性比較

3方式の主要な特性を以下にまとめます。各方式が「何を犠牲にして何を得るか」を選定の参考にしてください。

観点	Push型（StatsD・Remote Write等）	Pull型（Prometheus等）	エージェント常駐型（Telegraf・Datadogエージェント等）
短命ジョブへの対応	◎ 実行中にPush可能	△ スクレイプ前に消えるリスク	○ ローカル収集のため即時記録可
ファイアウォール制約	◎ アウトバウンドのみ	△ インバウンドポート開放が必要	◎ アウトバウンドのみ（エージェント→SaaS）
ターゲット死活検知	△ 送信が止まるまで検知できない	◎ up=0で即座に検知	○ ハートビート設計が別途必要
動的スケールへの追従	○ 新インスタンスが起動後すぐ送信開始	◎ Service Discoveryで自動追従	○ 起動スクリプトにエージェント同時インストールを組み込む
高カーディナリティ制御	△ 送信側に制御を置く必要がある	◎ sample_limit・relabelで収集側が制御	○ エージェント設定でフィルタリング可
収集基盤の障害影響	△ 送信失敗がクライアントに伝わりにくい（特にUDP）	◎ スクレイプ失敗はメタメトリクスで可視化	○ エージェントのバッファリング機能に依存

StatsD系Push型の特性と落とし穴

StatsD（UDPベース）やInfluxDB Line Protocolを使ったPush型は、クライアントライブラリが薄くアプリケーションコードへの組み込みが容易です。UDP送信のためアプリのレイテンシへの影響がほぼゼロである反面、送信先が落ちてもクライアントにはエラーが返りません。「送ったつもりが届いていなかった」という状態が検知しにくく、収集基盤の障害が静かにデータ欠損を引き起こします。本番でこの欠損に気づくのは、障害後のポストモーテムで「その時間帯のメトリクスがない」と発覚するタイミングであることが多いです。

Prometheus系Pull型の特性と注意点

Prometheusはスクレイプ失敗を自身のメタメトリクス（up=0）として記録するため、収集異常を比較的容易に検知できます。Service Discoveryを利用すれば、新しいPodの追加をconfig変更なしに自動検出できます。一方、スクレイプ対象が数千を超えると、Prometheusの単一インスタンスではスクレイプ負荷と時系列データの保持がボトルネックになります。Thanos・Cortex・Victoria Metricsなどの分散構成は、この問題への回答として大規模構築事例で広く採用されています。

エージェント常駐型の設計上の考慮点

DatadogエージェントやTelegrafのようなエージェント常駐型は、OSメトリクス・ログ・トレースを一元収集する設計をとります。バックエンドとの接続管理はエージェントが担うため、収集側の設計が単純化されます。ただし、エージェント自体がCPU・メモリを消費します。CPUスパイク時にエージェントの動作が遅延すると、その瞬間のメトリクスが欠落するという逆説が生じるため、エージェントのリソース上限（cpu_max_percent等の設定値）を設計段階で明示しておくことが重要です。この値を決めないまま本番投入すると、ノイズ源になって初めて気づくパターンに陥ります。

短命なインスタンス・オートスケールでの収集判断

短命ジョブの計測で起きる設計ミス

バッチ処理の平均実行時間が30秒以下のジョブに対して、スクレイプ間隔30秒のPrometheusをそのまま適用する設計は、構造的にメトリクスを取りこぼします。スクレイプのタイミングとジョブの生存期間が重なる確率が低く、実際には2〜3割程度しか収集できないケースもあります。アラートが静かになることで「正常稼働しているから出ない」と誤認されることが多く、設計レビューで明示的に指摘しないと見落とされがちです。ジョブの実行時間とスクレイプ間隔の関係を設計フェーズに確認項目として組み込む必要があります。

Pushgatewayの正しい使い方と限界

PushgatewayはPrometheusエコシステムの「短命ジョブ用の中継地点」として設計されており、ジョブが完了時にメトリクスをPushし、PrometheusがPushgatewayからスクレイプするという二段構えでPull型の弱点を補います。ただし、Pushgatewayはジョブの終了を知らないため古いデータが残り続けます。ジョブ単位でのラベル設計と、完了後のメトリクス削除（DELETE API）を組み合わせた運用設計が必要です。この削除処理を省略すると、失敗したジョブの最終値が「成功」に見えたまま残り続け、アラートが意図どおりに機能しません。

オートスケールグループの動的ターゲット管理

EC2オートスケーリンググループやKubernetesのHPAによってインスタンスが動的に増減する環境では、静的なスクレイプターゲット設定は機能しません。PrometheusのEC2 Service Discovery（ec2_sd_configs）やkubernetes_sd_configsを使い、インスタンスの生存期間に合わせて自動的にターゲットリストを更新する設計が必要です。Push型を採用する場合、新規インスタンスが起動直後からメトリクスを送り始めるためService Discoveryの設定は不要になります。その代わりに、送信先エンドポイントのURL・認証情報をインスタンスのブートストラップ設計（ユーザーデータ・SSMパラメータ等）に組み込む判断が求められます。

ネットワーク境界越しの収集をどう設計するか

ファイアウォール・セキュリティグループの影響

Pull型はコレクターがターゲットのメトリクスエンドポイント（9090番・9100番など）へインバウンド接続する必要があります。VPCのセキュリティグループ・オンプレのFWルールでこのインバウンドが許可されていない環境では、Pull型の導入がファイアウォール変更申請を伴います。申請から承認まで1〜2週間かかる組織では、Push型を選ぶことで構築スピードを維持できます。ただし、Push型でアウトバウンドを使う場合も、送信先のエンドポイントIPとポートの明示的な許可が必要である点は変わりません。「FW制約があるからPush型で」という判断は正しいですが、アウトバウンドの許可申請も見落とさないよう設計書に明記しておくことが重要です。

オンプレとクラウドが混在する境界設計

オンプレのベアメタルサーバーとAWS／GCPが混在する構成では、Direct ConnectやVPN越しにPrometheusがスクレイプしに行く設計か、各環境にローカルのPrometheusを置いてRemote Writeで中央の集約基盤（Victoria Metrics等）に送るフェデレーション構成かを選ぶ必要があります。スクレイプトラフィックが数十台規模であれば直接取りに行く設計でも帯域上の問題は生じにくいですが、200台を超えると帯域・レイテンシ・接続数が無視できない設計上の変数になります。データの所在と集約ポイントを最初に決めておくことが、後の設計ブレを防ぐ起点になります。

Push型でのエンドポイント認証設計

Push型でSaaS系の収集エンドポイントにメトリクスを送る場合、認証情報（APIキー・トークン）の管理が設計上の課題になります。インスタンスのユーザーデータやenvironment変数に直接書くと、スナップショット・AMIに認証情報が焼き込まれるリスクがあります。AWS Secrets ManagerやHashiCorp Vaultから動的に取得する設計、またはIAMロールベースの認証をブートストラップ設計に組み込む判断が求められます。認証情報の取り回しを設計段階で決めておかないと、インスタンス増加とともにシークレットの管理コストが急増し、後から収拾がつかなくなります。

集めすぎ（高カーディナリティ）で破綻する境界

カーディナリティ爆発のメカニズム

時系列データベース（TSDB）は、ラベルの組み合わせごとに独立した時系列を持ちます。user_idやrequest_idのような無限に増える値をラベルにすると、1つのメトリクス名でも数百万の時系列が生まれます。Prometheusは時系列数の増加に対してメモリ消費が線形に増加するため、カーディナリティ爆発はOOMキルによるPrometheusの停止に直結します。本番稼働中に初めてこの問題に気づくケースが多く、設計段階でのラベル設計レビューが軽視されがちな落とし穴のひとつです。「詳細なラベルを付けるほど良い」という直感が、構築後の障害を招きます。

ラベル設計で避けるべき判断

高カーディナリティの典型的なアンチパターンとして、エンドポイントのURLをそのままラベルにする（/api/users/12345のように動的IDを含む）ケースがあります。また、環境ごとに異なるラベル名・値を整合なく追加し続けるケースも問題です。一見「詳細な情報が取れる」と感じられますが、時系列数が数万を超えた段階でクエリレイテンシが急増し、ダッシュボードのレスポンスが10秒以上かかる状態になります。設計段階でラベルの候補を列挙し、「その値の種類は何通りか」を明示的に確認するプロセスが有効です。値の種類が100通りを超える場合は、ラベル採用を再考する目安になります。

収集量の上限をどこで設計するか

PrometheusやVictoria Metricsでは、スクレイプ1回あたりのサンプル数上限（sample_limit）を設定でき、これを超えるターゲットはスクレイプを失敗扱いにすることで基盤を保護できます。設計時に「1サービスあたり最大何時系列まで許容するか」という上限値を明示し、エクスポーター側でも不要なメトリクスを削る（metric_relabel_configsによるドロップルール等）設計を組み込むことが、後の破綻を防ぐ判断です。収集量の上限は初期設計時には過大に見えますが、サービスが成長するとあっという間に現実の問題になります。上限を決めずに運用を始めると、基盤の増強コストが収集設計の問題として表面化します。

メトリクス収集設計チェックフレーム

以下は、方式選定から収集上限設計までを網羅した確認リストです。設計レビューの場で活用してください。

1. ワークロードの寿命を分類する：常時起動か短命ジョブかを明示する。短命ジョブが含まれる場合はPush型またはPushgatewayの採用を検討する。
2. ネットワーク境界とFW制約を確認する：インバウンドポートが開けられるか確認し、開けられない場合はPush型で設計するか変更申請の工数を見込むかを判断する。
3. 動的スケールの有無を確認する：オートスケールがある場合、Pull型ではService Discoveryの設計を、Push型ではブートストラップへの認証情報組み込みを設計に含める。
4. 認証情報の管理方法を決める：APIキー・トークンをどこで管理するか（Secrets Manager・Vault・IAMロール等）を構築前に決定し、インスタンスに直書きしない設計を確認する。
5. 短命ジョブとPushgatewayの削除戦略を決める：Pushgatewayを使う場合、ジョブ完了後のDELETE APIコールをジョブ定義に含め、古いデータの残留を防ぐ設計とする。
6. ラベルの候補とカーディナリティを事前に審査する：各ラベルの値の種類が100通りを超える場合は採用しない。動的IDはラベルに含めない。
7. 収集量の上限値を明示する：1ターゲットあたりのメトリクス数・時系列数の上限を設定し、sample_limitやrelabelルールで強制する設計とする。
8. 大規模環境での分散構成を検討する：スクレイプ対象が数千を超える見込みなら、Thanos・Cortex・Victoria Metricsなどの分散構成を最初から設計に含める。
9. ハイブリッド構成の場合は方式の境界を明示する：どのワークロードをPushで、どれをPullで収集するかをドキュメント化し、設計の齟齬を防ぐ。