Grafana 可観測性実践：ダッシュボード・PromQL・アラート・コード化設定

Grafana が可観測性の中核である理由

Metrics・Logs・Traces は可観測性の三本柱ですが、それらをつなぐのは通常 Grafana です。その価値は「グラフを描く」ことではなく、散在するシグナルを「今、システムはどうなっているか」に答える一つの界面に集約することにあります。

柱	ソース	答える問い
Metrics	Prometheus	システムは全体として健全か？
Logs	Loki	エラー時に何が起きたか？
Traces	Tempo	遅いリクエストはどのサービスで詰まっているか？

効果的なダッシュボード構築

良いダッシュボードの原則：1 パネルは 1 つの話題、上から下へ粗から細へ。典型的なレイアウト：

上部：全体 SLO（エラー率、P99 遅延、QPS）。
中部：サービス/インスタンスごとの内訳パネル。
下部：生ログと単一トレースリンク。

{
  "panels": [
    {
      "title": "P99 遅延",
      "type": "timeseries",
      "targets": [
        { "expr": "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))" }
      ]
    }
  ]
}

Dashboard JSON は大きくなりがちです。編集前に JSON フォーマッタで展開し、ネスト階層を誤らないようにします。

良い PromQL を書く：可観測性の言語

率（rate）は生カウンタに勝る

# エラー率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)

分位数は histogram_quantile

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

ラベルで比較

# インスタンス別 QPS
sum(rate(http_requests_total[5m])) by (instance)

変数とテンプレート化：1 つの Dashboard で全部を見る

テンプレート変数を使えば、同じパネルが service や env で動的に切り替わり、数十枚のコピペパネルを防げます。

{
  "templating": {
    "list": [
      {
        "name": "service",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(http_requests_total, service)"
      }
    ]
  }
}

パネル内参照：sum(rate(http_requests_total{service="$service"}[5m]))。

マルチソース：Metrics + Logs + Traces

Grafana の強みは相関です。例えば Metrics パネルから「Explore」を開き、同じ trace_id で Tempo へ、さらに service + 時間窓で Loki ログへジャンプできます。

# Loki でラベルフィルタ
{service="checkout", level="error"} |= "timeout"

アラート：見るから通知されるへ

アラートルールは「原因」ではなく「症状」に基づくべきです：

groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
              / sum(rate(http_requests_total[5m])) by (service) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "サービス {{ $labels.service }} のエラー率が 5% 超過"

for: 10m は瞬間的なスパイクを除去し、アラート爆発を防ぎます。

アラートを誘発した応答コードを調べるときは、HTTP ステータスコードツールで 5xx の意味を即座に照合できます。

アノテーションとコード化設定

アノテーション（Annotation）

デプロイやロールバックなどのイベントをタイムラインに印を付け、「直近のリリースが原因では？」を一目で判断できます。

Provisioning：Dashboard をコード化

手作業でポチポチ作るのではなく、ファイルとして Git で管理します：

apiVersion: 1
providers:
  - name: default
    folder: ""
    type: file
    options:
      path: /etc/grafana/provisioning/dashboards

これで Dashboard はレビュー可能・ロールバック可能・再現可能になり、GitOps 実践になります。

よくある質問 FAQ

Q1：P99 が NaN になるのはなぜ？

多くは histogram bucket が上報されていないか、rate 時間窓にデータがないため。histogram_quantile の前に指標の存在を確認してください。

Q2：変数のドロップダウンが空？

変数のデータソースと、label_values のメトリクス名が実在するか確認します。

Q3：アラートが誤報ばかり？

for 継続時間を付け、閾値を上げ、あるいは absent() で指標消失を処理します。

Q4：Grafana と Prometheus のアラートの関係は？

Prometheus は「計算 + 発火」、Grafana は「表示 + 通知ルーティング」。Grafana にホストさせることも可能です。

Q5：定期ジョブの指標はどう見る？

Cron 説明ツールでスケジュールを照合し、指標の時間窓と比べて定時に動いたか判断します。