Vault のメトリクス: 主要メトリクスの見方

Vault は高可用で安全にシークレットを配布するためのコア基盤です。運用では、単に起動しているかではなく、リーダー選出、シール状態、リクエスト遅延、ストレージ健全性、リース更新の失敗など、兆候を早めに掴むメトリクスの監視が要点になります。

本稿では公式ドキュメントの挙動を前提に、Prometheus での収集方法と、主要メトリクスの読み方・アラート設計を具体化します。バージョン差異に左右されやすい個別メトリクス名には依存し過ぎず、カテゴリと実務的な見方に寄せて解説します。

全体像と収集方法（Prometheus/StatsD）

Vault は telemetry スタンザを有効化すると、/v1/sys/metrics エンドポイントから Prometheus 形式でメトリクスを公開できます（format=prometheus を指定）。StatsD/DogStatsD への送出も選択可能です。収集方式は運用基盤に合わせて決めますが、ダッシュボードやアラート設計の容易さから、近年は Prometheus 直収集が主流です。

重要な前提は2点です。1) telemetry を設定してサーバを再起動（または安全なメンテナンス手順に従いローリング）すること、2) 本番では /v1/sys/metrics へのアクセス制御（ポリシーで read を付与）を行うこと。まずは開発環境でメトリクス一覧を実際に確認し、利用可能なラベル（パス、メソッド、ステータス、マウント種別など）を把握してからダッシュボード化するのが確実です。

• エンドポイント: /v1/sys/metrics?format=prometheus
• telemetry.prometheus_retention_time を設定すると Vault 内部のメトリクス保持が有効に
• StatsD/DogStatsD は既存 APM/監視と統合しやすいが、ラベルは限定的になりがち

Vault メトリクス収集の典型構成

Vault telemetry と Prometheus スクレイプ設定例（HCL/YAML）

# server.hcl（抜粋）
telemetry {
  prometheus_retention_time = "24h"
  disable_hostname = true
  # 必要に応じて（いずれかを使用）
  # statsd_address   = "127.0.0.1:8125"
  # dogstatsd_address= "127.0.0.1:8125"
}

# sys/metrics 読取用の最小ポリシー例（Vault policy）
path "sys/metrics" {
  capabilities = ["read"]
}

# Prometheus（prometheus.yml 抜粋）
scrape_configs:
  - job_name: "vault"
    scheme: https
    metrics_path: /v1/sys/metrics
    params:
      format: ["prometheus"]
    bearer_token: "s.xxxxxxxx"  # sys/metrics 読取権限のあるトークン
    tls_config:
      insecure_skip_verify: false
    static_configs:
      - targets: ["vault.example.com:8200"]

可用性/HA の見方（リーダー・シール・ヘルス）

HA 運用では、リーダー交代の頻度と直前兆候（レイテンシ上昇、ストレージ遅延）、シール/アンシールのイベント、スタンバイ昇格の成否をウォッチします。メトリクスでは、リーダーシップ関連のカウンタ/ゲージ、シール状態変化のイベント数、スタンバイの RPC 失敗回数などが安定した指標です。加えて /v1/sys/health を併用して状態遷移を定点観測します。

試験・実務ともに、単発のダウン検知よりもリーダー交代の『増加傾向』や『連鎖（交代→遅延→交代）』に注目するのがポイントです。5xx エラーやストレージ警告と相関があれば早期の是正が可能です。

• 見るべき観点: リーダー交代回数、リーダー滞在時間、シール状態の変化、スタンバイ昇格失敗
• ヘルス API は即時性が高い（/v1/sys/health）。メトリクスは傾向把握に強い

HA の状態遷移（概念）

ヘルス/メトリクスの取得例（curl）

# リーダー・シール状態確認（ヘルス API）
curl -sS https://vault.example.com:8200/v1/sys/health \
  -H "X-Vault-Token: s.xxxxx" | jq '{sealed, standby, initialized, version}'

# メトリクス（Prometheus 形式）
curl -sS "https://vault.example.com:8200/v1/sys/metrics?format=prometheus" \
  -H "X-Vault-Token: s.xxxxx" | head -n 50

リクエスト遅延・スループット・エラー率の見方

Vault の API リクエストは、パス（例: auth/、sys/、kv/）、HTTP メソッド、ステータスコードなどのラベルと共にエクスポートされます。これにより、マウント/メソッド/ステータス別のスループット、レイテンシ分布、5xx エラー率を可視化できます。SLO 設計では p95/p99 のレイテンシと 5xx 率（直近 5〜15 分）が実務的です。

個別のメトリクス名やラベルはバージョンで増減することがあるため、まずは /v1/sys/metrics の出力を実際に確認し、ラベル（path, method, status など）で集計できることを前提にダッシュボードを定義してください。

• 遅延は分位点（p95/p99）で監視。突発的スパイクと恒常的上昇を分けて可視化
• 5xx はルート別に集計。auth/* の増加は外部 IdP/ネットワーク要因も疑う

レイテンシ分布の把握（概念）

ダッシュボード/アラート設計の雛形（PromQL の考え方）

# 具体的なメトリクス名は /v1/sys/metrics の出力に合わせて置換してください。
# 例: レイテンシ p95（Histogram/summary を利用可能なら）
# histogram_quantile(0.95, sum by (le, path) (<request_duration_bucket>))

# 例: 5xx 率（直近 5 分）
# sum by (path)(rate(<request_total>{status=~"5.."}[5m])) / sum by (path)(rate(<request_total>[5m]))

# 例: スループット（RPS）
# sum(rate(<request_total>[1m]))

ストレージ/レプリケーション（Raft/Integrated Storage）の見方

Integrated Storage（内蔵 Raft）利用時は、コミット遅延、ピアの健全性、スナップショット/ログ圧縮の進行、ディスク I/O のボトルネックを監視します。メトリクスはストレージ操作の遅延やエラー回数としてエクスポートされます。短期の遅延スパイクよりも、継続的なレイテンシ上昇や再送増加を重視します。

メトリクスと併せて、Autopilot の状態やピアのヘルスを API で確認しておくと、切り分けが早くなります。

• Raft ピア数・リーダーの識別、コミット/適用遅延、スナップショット頻度
• ディスクの fsync 遅延やストレージ層エラーは上位のレイテンシ/リーダー交代に伝播

Raft の概念図（Active/Peers）

Autopilot/ピア状態の取得（参考 API）

# Autopilot の状態（参考：補助的な健全性確認）
curl -sS https://vault.example.com:8200/v1/sys/storage/raft/autopilot/state \
  -H "X-Vault-Token: s.xxxxx" | jq '{healthy: .healthy, failure_tolerance: .failure_tolerance, servers: [.servers[] | {id, node, voter, healthy}]}'

# ピア一覧
curl -sS https://vault.example.com:8200/v1/sys/storage/raft/configuration \
  -H "X-Vault-Token: s.xxxxx" | jq '.configuration.servers[] | {id, address, voter}'

トークン/リース/シークレット寿命の見方

トークン発行とリース更新の失敗は、認可の不具合や外部依存（KMS/PKI/DB）に直結します。メトリクスでは、発行/更新/失効の回数や失敗率、リース保有数の推移を把握します。定常的な増加はリークの兆候、失敗スパイクは外部依存の障害やポリシー変更の影響を疑います。

補助的に /sys/leases API を用いたスポット確認（特定パスのリース総数や残存時間の分布）を運用 Runbook に入れておくと、障害時の切り分けが早くなります。

• 見るべき数値: リース総数、更新成功率、失敗の発生源（path/mount 別）
• 長寿命リースの滞留は tidy/ポリシー見直しの合図

リースのライフサイクル（概念）

リース確認の補助（API）

# 特定パス配下のリース一覧（例）
curl -sS https://vault.example.com:8200/v1/sys/leases/lookup/db/creds/ \
  -H "X-Vault-Token: s.xxxxx" | jq '.'

# トークン情報（例）
curl -sS https://vault.example.com:8200/v1/auth/token/lookup-self \
  -H "X-Vault-Token: s.xxxxx" | jq '{id, policies, ttl, orphan}'

アラート設計と試験対策の要点

アラートは『瞬間最大』より『継続的な逸脱』を拾う条件で設計します。HA の安定性、API レイテンシ、5xx、ストレージ遅延、リース更新失敗の5系統を最低限おさえ、相関を見るダッシュボードをペアで用意します。

試験（Operations）では、telemetry 有効化、/v1/sys/metrics 取得の前提（format=prometheus、権限）、HA とストレージの関係、レート制限や監査ログエラーの兆候などが頻出の文脈です。用語は公式ドキュメント準拠で覚えておくと安全です。

• しきい値は『平常時の基準値 × 2 が 5 分継続』のようにベースラインから設計
• sys/health による即時性と Prometheus による傾向把握を併用

相関を見るダッシュボード（概念配置）

運用 Runbook の雛形（擬似レシピ）

# 1) アラート発火（例: 5xx 増加）
# 2) /v1/sys/metrics を取得し、path/method/status を確認
# 3) 該当 path の下位依存（DB/PKI/ネットワーク）の健全性を確認
# 4) 併せて /v1/sys/health と Raft Autopilot 状態を確認
# 5) 影響範囲（トークン/リース）を確認し、レート制限/回避策を適用

問題で確認

よくある質問