Vault テレメトリ設定: Prometheus / StatsD 連携の実務要点

Vault はサーバ内部のカウンタやレイテンシなどを telemetry として公開できます。代表的な取り込み先は Prometheus（Pull）と StatsD（Push）です。本稿では両者の使い分け、設定の落とし穴、HA 構成での注意をまとめます。

受験対策としては、telemetry スタンザの主要オプション、/v1/sys/metrics のフォーマット指定、Prometheus スクレイプの典型例、StatsD のポート/プロトコル前提が頻出です。

目的と前提：Vault テレメトリの全体像

Vault は server 設定の telemetry スタンザにより観測データのエクスポートを有効化します。Prometheus 互換の出力は HTTP 経由で /v1/sys/metrics?format=prometheus から取得できます。StatsD は UDP ベースでメトリクスを送信します。

本稿は OSS Vault を前提に、安定的に使われるオプションと一般的な運用パターンに絞って解説します。バージョン差異がある環境では、必ず運用中の Vault ドキュメントと設定可能なキーを確認してください。

• Prometheus: Pull 方式。Prometheus サーバが Vault の HTTP エンドポイントを定期スクレイプ。
• StatsD: Push 方式。Vault がローカル/リモートの StatsD デーモンへ UDP で送信。
• HA 構成では、メトリクスのラベルと重複計上（active/standby）に注意。

最小の疎通確認（Prometheus 形式での取得）

curl -s https://vault.example.com:8200/v1/sys/metrics?format=prometheus \
  --cacert /etc/ssl/certs/ca.pem | head -50

アーキテクチャ：Pull と Push、HA での流れ

Prometheus は Pull、StatsD は Push。ネットワークの方向・到達性、ラベル/タグ表現、重複抑止のアプローチが異なります。Vault クラスタを監視する際は、active/standby ノードの扱いと TLS/防火壁設計を先に固めると、後工程の調整が減ります。

• Prometheus はスクレイプの到達性（FW/ACL）を確保し、/v1/sys/metrics に format=prometheus を付与。
• StatsD は UDP 8125（一般的既定）を開通。ロスに強い設計ではないため、ネットワーク品質にも配慮。

データフロー（概念図）

HA での典型ターゲット例（Consul サービスディスカバリを想定）

# Prometheus 側でサービス解決を使う場合のイメージ（抜粋）
scrape_configs:
- job_name: 'vault'
  metrics_path: /v1/sys/metrics
  params:
    format: ['prometheus']
  scheme: https
  tls_config:
    ca_file: /etc/prometheus/ca.pem
  static_configs:
  - targets: ['vault-1.example.com:8200','vault-2.example.com:8200','vault-3.example.com:8200']

Vault の telemetry 設定（最小構成と安全策）

Vault 側では telemetry スタンザで出力形式や送信先を有効化します。Prometheus 連携だけなら HTTP エンドポイントでの出力を維持するため、保持期間（prometheus_retention_time）とホスト名ラベル抑止（disable_hostname）を設定するのが実務上の無難な初手です。

StatsD を併用する場合は statsd_address を追加します。環境の観測基盤が確立済み（Datadog/Graphite など）であれば、移行コストを抑えられます。

• disable_hostname=true はラベルカーディナリティ抑制に効く（ダッシュボードの安定化）。
• prometheus_retention_time はヒストグラム/サマリーの保持窓を調整。過度に大きいとメモリ使用量が増える。
• StatsD は UDP のため、ネットワークロス/バッファあふれ時の再送は期待しない設計に。

vault.hcl（抜粋）: Prometheus と StatsD を同時に有効化

telemetry {
  # Prometheus 形式の保持時間（例: 24h）
  prometheus_retention_time = "24h"

  # ホスト名をラベルに含めないことでカーディナリティを抑制
  disable_hostname = true

  # StatsD 送信（必要な場合のみ有効化）
  # 一般的な既定ポートは 8125/udp
  statsd_address = "127.0.0.1:8125"
}

# 反映: systemd の場合
# sudo systemctl reload vault

Prometheus 連携：スクレイプ設定と検証

Prometheus からは /v1/sys/metrics に対して format=prometheus を付けてスクレイプします。TLS を終端しない構成は避け、最小限でも CA 検証を行います。HA 環境では全ノードをターゲットにするか、サービスディスカバリで動的に解決するのが一般的です。

重複計上や切替時のブレを抑えるため、recording rules で統計を安定化させる運用が現実的です（例: rate の窓幅をやや長めに）。

• metrics_path は /v1/sys/metrics、params に format=prometheus を指定。
• TLS 設定（ca_file/server_name）を忘れない。自己署名の場合は CA を配布。
• 初期検証は curl で整形出力を確認（ステータス 200、メトリクスが # HELP/# TYPE で始まる）。

Prometheus の scrape_configs（最小例）

scrape_configs:
- job_name: 'vault'
  scheme: https
  metrics_path: /v1/sys/metrics
  params:
    format: ['prometheus']
  tls_config:
    ca_file: /etc/prometheus/ca.pem
    # server_name を指定して SNI/証明書のCN/SANを検証
    server_name: vault.example.com
  static_configs:
  - targets: ['vault.example.com:8200']

StatsD 連携：送信設定と取り込み先の注意

Vault は telemetry で statsd_address を指定すると、内部メトリクスを UDP で送信します。取り込み先は Graphite/Datadog/Telegraf など。DogStatsD のようなタグ拡張に依存する場合は、対応するエージェントを選択します。

UDP はロスを前提に設計されているため、ネットワーク混雑や再起動時のスパイクを考慮し、アラート閾値はヒステリシスや複合条件で安定化させると良いです。

• Firewall で 8125/udp を許可（ローカル受信なら不要）。
• 高頻度メトリクスはサンプリングを検討（取り込み先の機能に依存）。
• DogStatsD を使う場合は対応アドレス/タグ設定を取り込み側で有効化。

StatsD 取り込み（Telegraf 経由 Graphite などの例）

# Telegraf の statsd 入力例（telegraf.conf 抜粋）
[[inputs.statsd]]
  service_address = ":8125"
  delete_gauges = false
  delete_counters = false
  # 必要に応じて metric_separator / templates を調整

# Vault 側（前掲 vault.hcl）で statsd_address を 127.0.0.1:8125 に設定

運用チェックと試験対策の要点

運用では、メトリクスの可用性・正確性・遅延の3点を監視観点に入れます。Prometheus は scrape 成功率とメトリクス数のドリフト、StatsD は受信レートとドロップの兆候（取り込み側のログ/内部メトリクス）を監視すると実害を早期に検知できます。

試験では、/v1/sys/metrics のフォーマット指定、telemetry の主要キー、Pull/Push の設計差を確実に押さえると得点源になります。

• curl で /v1/sys/metrics?format=prometheus を確認（TLS/応答コード/ヘッダ）。
• Prometheus の scrape_duration_seconds/scrape_samples_scraped をウォッチ。
• StatsD は取り込み先のメトリクスやログにドロップ/バッファ警告がないか確認。

トラブルシュートの小ネタ

# 1) Prometheus 形式で応答するか
curl -vk https://vault.example.com:8200/v1/sys/metrics?format=prometheus | head -20

# 2) ポート到達性（StatsD/UDP）
sudo tcpdump -ni any udp port 8125 -vv -c 5

# 3) ラベル過多の抑制（設定再確認）
# telemetry.disable_hostname=true を適用後、ダッシュボードの時系列を比較

問題で確認

よくある質問