Prometheus 監視とアラート実践 2026：PromQL、Alertmanager、SLO 駆動の可観測性

なぜ Prometheus はクラウドネイティブ監視の標準であり続けるか

OpenTelemetry が拡大する 2026 年でも、Prometheus は Metrics の柱を握っています。プルモデル・多次元データモデル・強力な PromQL を特徴とし、Alertmanager と組んでアラートの閉ループを形成します。その設計トレードオフを理解することが、信頼できる可観測性の第一歩です。

次元	Prometheus	プッシュ型案
収集	/metrics をプル	クライアントがプッシュ
クエリ	PromQL、多次元で柔軟	外部ストアのクエリに依存
サービス発見	K8s/Consul を標準支援	自前実装が必要
向き	マシン/サービス指標	短命ジョブ（Pushgateway 併用）

---

アーキテクチャとコアコンポーネント

• Prometheus Server：スクレイプ・保存（ローカル TSDB）・PromQL 実行。
• Exporter：第三者システム指標を /metrics へ露出（node_exporter 等）。
• Alertmanager：重複排除・グループ化・ルーティング・サイレンス。
• Pushgateway：バッチ/短命ジョブのプッシュ指標を受け取る。

# prometheus.yml 最小構成
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["node-1:9100", "node-2:9100"]
  - job_name: "api"
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_name]
        regex: "order-api"
        action: keep

スクレイプ失敗の調査では、Exporter の応答コード（200/503 等）を HTTP ステータスコード ツールで照合し、収集側か露出側かを素早く切り分けます。

---

PromQL コア関数

rate / irate：レート計算

# 毎秒リクエスト数（5m 窓、スパイクを平滑化）
rate(http_requests_total[5m])

# 瞬時レート（直近2サンプル）、鋭敏だが抖れやすい
irate(http_requests_total[5m])

histogram_quantile：分位遅延

http_request_duration_seconds_bucket はヒストグラム指標。分位関数で P99 遅延を：

# P99 リクエスト遅延
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

ラベル集約

# サービスとコードで QPS を集約
sum by (service, code) (rate(http_requests_total[5m]))

---

記録ルール（Recording Rules）：事前計算でコスト削減

高頻度で高価なクエリを新しい時系列に事前計算し、ダッシュボードは結果を直接読みます。

# rules/recording.yml
groups:
  - name: http_slo
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))
      - record: job:request_latency:p99
        expr: |
          histogram_quantile(0.99,
            sum by (job, le) (rate(http_request_duration_seconds_bucket[5m])))

---

アラートルールと Alertmanager

アラートルール

# rules/alerts.yml
groups:
  - name: availability
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{code=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m                 # 10分継続で発報、抖れを回避
        labels:
          severity: critical
        annotations:
          summary: "エラー率が 5% 超"
          description: "サービス {{ $labels.job }} の5xx率 {{ $value | humanizePercentage }}"

Alertmanager のルーティングとグループ化

# alertmanager.yml
route:
  receiver: "slack-default"
  group_by: ["alertname", "job"]
  group_wait: 30s          # 同グループ初回待機で複数を集約
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ["severity=critical"]
      receiver: "pagerduty"
      continue: true
    - matchers: ["job=~"batch.*"]
      receiver: "slack-batch"

receivers:
  - name: "slack-default"
    slack_configs:
      - api_url: ${SLACK_URL}
        channel: "#alerts"

抑制（Inhibition）とサイレンス（Silence）

• 抑制：「ホストダウン」アラートがある時、そのホスト上の「サービス不通」を抑制しノイズを削減。
• サイレンス：保守窓（リリース等）で特定アラートを一時ミュート。Cron ツールで保守窓を計画。

---

SLO とエラーバジェット燃焼率

「経験的閾値」を SLO（Service Level Objective）に置き換えるのが現代アラートの核心。99.9% 可用性の例：

# 30日窓の合規比（good / total）
(
  sum(rate(http_requests_total{code!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) > 0.999

燃焼率（Burn Rate）アラートはエラーバジェットの急消費を早期検知：

- alert: ErrorBudgetBurnFast
  expr: |
    (
      sum(rate(http_requests_total{code=~"5.."}[1h]))
      / sum(rate(http_requests_total[1h]))
    ) > (14.4 * (1 - 0.999))   # 1h で 30d 予算を 14.4 倍の割合で消費
  for: 5m
  labels: { severity: critical }

---

アプリ計装：Exporter 任せにしない

業務指標は能動的に計装。Python 例：

from prometheus_client import Counter, Histogram, start_http_server

REQUESTS = Counter("http_requests_total", "総リクエスト数", ["method", "code"])
LATENCY = Histogram("http_request_duration_seconds", "リクエスト所要")

start_http_server(8000)   # /metrics を露出

@LATENCY.time()
def handle(req):
    REQUESTS.labels(req.method, "200").inc()
    return "ok"

フロントエンドやゲートウェイ側は、構造化指標を JSON フォーマッター で検証してから監視パイプラインへ書き込み、汚染を防ぎます。

---

本番ベストプラクティス・チェックリスト

1. for を適切に：瞬時抖れによるアラートストームを回避。
2. カーディナリティ制御：高基数列（user_id 等）をラベルにしない（TSDB を破壊）。
3. 階層アラート：Warning はチャットへ、Critical はオンコールページャへ。
4. 記録ルールを前置：ダッシュボードは事前計算系列を読む。
5. 長期保存：ローカル TSDB に Thanos / Mimir を組み、遠隔書き込みで単機保持上限を突破。

---

よくある質問 FAQ

Q1：rate と irate はどちら？

傾向には rate（平滑）、瞬間スパイクには irate（鋭敏）。ダッシュボードは通常 rate。

Q2：ヒストグラムかサマリか？

跨インスタンス集約分位（全体 P99 等）が必要ならヒストグラム。単インスタンスで分位不明なら Summary。ヒストグラムが柔軟で推奨。

Q3：アラートが抖れます？

ルールに for: 10m を付けるか、指標の rate 窓を長くし短周期変動を吸収。

Q4：ラベルが多すぎると？

各ユニークラベル組は別時系列。高基数列の乱用はメモリ・書き込み爆発を招く、Prometheus 最大の性能坑。

Q5：Prometheus はログやトレースを代用できますか？

できません。Metrics は「総量と傾向」、Logs は「一件の詳細」、Traces は「呼び出し経路」。補完関係で完全な可観測性を構成。

---

推奨ツール

Prometheus 運用には、以下の ToolsKu ツールが役立ちます：

• HTTP ステータスコード — Exporter/Alertmanager 端点応答の照合
• Cron — 保守サイレンス窓と収集周期の計画
• JSON フォーマッター — アラート Webhook と指標ペイロードの検証

---

Prometheus の強みは「グラフを描く」ことではなく、「PromQL で業務の健康を定量可能な SLO に訳し、Alertmanager でノイズを実行可能なアラートに絞る」こと。指標・アラート・SLO の三層を繋げば、監視は初めて価値を持ちます。