Prometheus Agentモード：エッジ・IoT環境における「攻め」のオブザーバビリティ設計
現場のテックリードとして、一つだけ断言しておく。「エッジ環境でフル機能のPrometheusを動かすのは、ただの自殺行為だ」。
限られたメモリ、不安定なネットワーク、そして何より「エッジにローカルストレージを持たせる」という設計思想が、後の運用でどれほどの負債を生むか。ディスクI/Oのボトルネック、TSDBの肥大化によるOOM Killerの咆哮……そんな悪夢を終わらせるのが Prometheus Agentモード だ。
本稿では、このモードを単なる「送信機」としてではなく、堅牢なオブザーバビリティパイプラインの心臓部として使いこなすための極限の知見を授ける。
—
1. アーキテクチャの断絶：なぜ「Agentモード」なのか
通常モード（Serverモード）とAgentモードの決定的な違いは、「データの永続化」と「クエリエンジン」の有無にある。
- Serverモード: TSDBを保持し、ローカルで評価（Alerting/Recording Rules）を行い、クエリ（PromQL）を処理する。これは「ストレージ」としての責任を負うため、I/Oとメモリのフットプリントが巨大化する。
- Agentモード: TSDBを捨て、スクレイプとRemote Writeに特化する。スクレイプしたメトリクスはWAL（Write Ahead Log）に書き込まれ、即座にRemote Writeで中央の集約基盤（Thanos, Cortex, Mimir等）へ転送される。
「エッジには計算させず、ただ運ぶ」。この哲学こそが、リソース制約の厳しい環境における唯一の正解だ。
—
2. ローカルストレージを持たないエッジ運用の設計
エッジサーバーは「使い捨て」が基本だ。Agentモードを運用する際は、以下の設計を徹底せよ。
- Write-Ahead Log (WAL) の保護: Agentモードは一時的なネットワーク断をWALで吸収する。しかし、再起動時にWALが壊れるとメトリクスがロストする。ストレージはRAMディスクにするか、あるいは最小限の永続ボリューム（数GB程度）を割り当て、`storage.agent.path` を定義する。
- Backpressureの制御: ネットワークが回復した際、溜まったWALを一気にRemote Writeすると、帯域を飽和させる。`queue_config` の `max_shards` と `max_samples_per_send` を絞り、エッジ側の帯域負荷を平準化するのがプロの作法だ。
—
3. メモリを食い尽くさないための極限チューニング
デフォルト設定のまま運用するのは、高速道路を軽自動車で時速200km出すようなものだ。以下のチューニングを施せ。
prometheus.yaml: Agentモードの最適化構成例
global:
scrape_interval: 15s
scrape_timeout: 10s
remote_write:
- url: “https://central-mimir.example.com/api/v1/push”
queue_config:
# メモリ消費を抑えるための調整
capacity: 10000 # キューの深さ
max_shards: 5 # 並列送信数を絞る
max_samples_per_send: 500 # 一回の送信量を抑え、スパイクを抑制
metadata_config:
send: false # メタデータの送信を抑制し帯域を節約
実践テクニック: ターゲットの精査
不要なメトリクスをエッジ側でドロップして転送量を減らす
scrape_configs:
- job_name: ‘node-exporter’
static_configs:
- targets: [‘localhost:9100’]
metric_relabel_configs:
- source_labels: [__name__]
regex: ‘node_cpu_guest.’ # 不要な高カーディナリティメトリクスを排除
action: drop
—
4. チーム開発を加速させる「神」テクニック
隠れたキーボードショートカット（Prometheus UI）
- `Ctrl + Enter`: クエリ実行（ブラウザの更新を待つな、これを叩け）。
- `Tab`: クエリのオートコンプリート補完。
- `Shift + Up/Down`: グラフのスケール調整。
絶対に入れるべき神ツール
- [PromLens](https://promlens.com/): PromQLの構造が複雑化した瞬間、脳内でクエリを追うのは限界が来る。PromLensで実行計画を可視化し、どこでメモリを食っているか特定しろ。
- [Promtool](https://prometheus.io/docs/prometheus/latest/command-line/promtool/): CIパイプラインに `promtool check config` を組み込まないのは怠慢だ。YAMLのシンタックスだけでなく、ルールファイルの整合性までチェックしろ。
設定の共有化ルール：DRY原則の適用
チーム開発では、`scrape_configs` を巨大な一つのファイルにするな。`file_sd_configs`（ファイルベースのサービスディスカバリ） を使え。
サービスごとにファイルを分割し、git管理する
scrape_configs:
- job_name: ‘app-services’
file_sd_configs:
- files:
- ‘/etc/prometheus/sd/app-.json’
refresh_interval: 1m
JSONでターゲット定義を外出しすることで、CI/CDで動的にターゲットを更新できる。これが「疎結合」な監視基盤の第一歩だ。
—
テックリードからの提言
オブザーバビリティとは、「システムの状態を外部から観測可能にすること」ではない。「システムが発するノイズを、意味のある信号に変換するエンジニアリングそのもの」だ。
Agentモードを使ってエッジの負荷を極限まで減らし、中央の基盤で高度な分析を行う。このアーキテクチャは、あなたのチームを「障害対応に追われる運用者」から「システムの真実を俯瞰する設計者」へと変貌させるだろう。
さあ、コードを書き換えろ。そして、メトリクスの海を制覇せよ。