Prometheus Agent Mode: エッジ・IoT環境における「ゼロ・ストレージ」メトリクス収集の極意
多くのエンジニアが「Prometheus＝TSDB（時系列データベース）」という呪縛に囚われている。だが、真のオブザーバビリティ・アーキテクトは知っている。監視対象が数千台のエッジデバイスや、リソースが制限されたIoTゲートウェイである場合、Prometheusのローカルストレージは「最大の敵」となることを。
Prometheus v2.26で導入されたAgentモードは、まさにその呪縛を解き放つための銀の弾丸だ。今日は、この機能を極限まで使い倒し、エッジ環境を「ただのメトリクス収集点」へと昇華させるためのアーキテクチャ論を語る。
—
1. 脳と心臓を切り離せ：Agentモードの核心
通常モードとAgentモードの決定的な違いは、「ローカルでの永続化」と「クエリエンジン」の有無だ。
- 通常モード (Server): スクレイプしたデータをローカルのブロックストレージ（TSDB）に書き込み、PromQLクエリを受け付ける。これは「現場に病院を建てる」行為だ。
- Agentモード: スクレイプとRemote Write（転送）に特化する。ローカルのTSDB（WAlの圧縮やインデックス作成）は一切行わない。これは「現場で血液を採取し、中央の大病院へ即座に転送する」行為だ。
アーキテクチャ上の利点:
- ディスクI/Oの撲滅: データの書き込みはメモリ内のWALバッファと、Remote Write送信のための小さなキューのみ。SDカードや安価なSSDの寿命を削ることはない。
- クエリ負荷の排除: CPUリソースは「スクレイプ」と「ネットワーク送信」に100%集中できる。
—
2. Remote Writeによる「エッジ・セントリック」運用設計
ローカルストレージを持たないエッジサーバーにおいて、唯一の命綱が `remote_write` だ。ここで陥りがちな罠が「ネットワーク分断時のデータ消失」である。
Agentモードは、これをWAL（Write Ahead Log）によるリプレイメカニズムで解決している。設定の勘所は、キューの制御だ。
prometheus.yml (Agent Mode)
global:
scrape_interval: 15s
remote_write:
- url: “https://central-prometheus-gateway/api/v1/write”
# ネットワーク不安定なエッジ環境では、キューのサイズと並列数を最適化する
queue_config:
capacity: 2500 # キューに溜め込むサンプル数
max_shards: 5 # 並列送信数（CPUコア数に合わせて調整）
min_backoff: 1s # 再送間隔の最適化
max_backoff: 30s
# 認証トークンは機密管理のため環境変数から読み込むこと
bearer_token_file: /etc/prometheus/secrets/remote_write_token
設計の極意:
エッジ側で通信が途絶えた際、WALは溢れる。メモリ消費を抑えつつ生存時間を延ばすには、`capacity` を物理メモリの空き容量と相談して限界まで積む。これこそが、エッジ特有の「バッファ戦略」である。
—
3. メモリ消費を削ぎ落とす：低レイヤ最適化ハック
Agentモードであっても、数万メトリクスを扱うとメモリを食う。特にGCの頻発はエッジデバイスでは致命的だ。以下のハックを適用せよ。
手順A: ゴミを削る（Relabeling）
すべてのメトリクスを送信するのは愚策だ。`metric_relabel_configs` で、不要なラベルや高カーディナリティなメトリクスを「収集段階」で破棄せよ。
scrape_configs:
- job_name: ‘node_exporter’
metric_relabel_configs:
# メモリ使用率等の高精度すぎるメトリクスを削除
- source_labels: [__name__]
regex: ‘node_memory_.’
action: drop
手順B: プロセス起動オプションの限界突破
Prometheusバイナリを実行する際の引数を極限まで調整する。
/usr/local/bin/prometheus \
–config.file=/etc/prometheus/prometheus.yml \
–enable-feature=agent \
–storage.agent.path=/tmp/prometheus-agent \
–web.listen-address=127.0.0.1:9090 \
–log.level=warn \
# ここが重要：Goのメモリ管理に介入する
# GOGCを下げるとGC頻度が増えCPUを食う。エッジなら100〜200でバランスを取れ
–env=”GOGC=100″
—
4. 自動構成とデプロイの自動化（エキスパート・プラクティス）
エッジ環境では、手動設定など言語道断だ。Ansibleで叩くか、K3s等の軽量K8sでPodとして展開し、ConfigMapの更新を `inotify` で検知してリロードする仕組みを作る。
自動リロードの鉄則:
Prometheusは `/-/reload` エンドポイントを叩くだけで設定を再読み込みする。これをシステム化せよ。
設定変更時に即座に反映させるためのinotifyスクリプト抜粋
inotifywait -m /etc/prometheus/ -e close_write | while read path action file; do
if [ “$file” = “prometheus.yml” ]; then
curl -X POST http://localhost:9090/-/reload
fi
done
—
最後に：オブザーバビリティの本質とは
Agentモードを導入するということは、「監視の境界線」を明確にするということだ。エッジは「収集」に徹し、中央は「可視化と解析」に徹する。この分離こそが、大規模監視システムにおいて唯一スケールするアーキテクチャである。
ツールをただ動かすな。ツールの「意図」を理解し、そのリソース消費の波形までを設計せよ。それができる者だけが、真に信頼性の高いシステムを構築できる。
さあ、そのエッジデバイスに、真のオブザーバビリティを実装する準備はできたか。