2026年7月20日

KubernetesのGrafanaでダッシュボードを作る｜kube-prometheus-stackの導入からPromQLのパネル作成・コード管理まで

Docker・コンテナ

KubernetesのGrafanaダッシュボードは、「Prometheusでメトリクスを集める → Grafanaでデータソースとして読む → PromQLでパネルを作る」の3段で作ります。いちばん手早いのは、PrometheusとGrafanaと基本のダッシュボード一式をまとめて入れる Helm チャート kube-prometheus-stack を使う方法です。この記事では、その導入とログイン、名前空間を切り替えられる自作ダッシュボードの作り方、よく使うPromQL、ダッシュボードをConfigMapでコード管理する方法、公開時のセキュリティの注意点を説明します。

チャートのvaluesの項目やGrafanaの画面表記は版によって変わるため、内容は執筆時点（2026年10月現在）のものとして読んでください。

全体の構成

kube-prometheus-stackを入れると、主に次のものが動きます。

Prometheus（Prometheus Operator経由）：メトリクスを集めて保存します。
kube-state-metrics：Deploymentの数、Podの状態、再起動回数など、Kubernetesのオブジェクトの状態をメトリクスにします。
node-exporter：各ノードのCPU・メモリ・ディスクのメトリクスを出します。
kubeletのcAdvisor：コンテナごとのCPU・メモリ使用量を出します（kubeletに組み込まれています）。
Grafana：Prometheusをデータソースとして設定済みの状態で起動し、クラスタ・ノード・Pod向けの基本ダッシュボードが入っています。

自作のダッシュボードで使うメトリクスは、主にkube-state-metrics（kube_ で始まるもの）とcAdvisor（container_ で始まるもの）とnode-exporter（node_ で始まるもの）の3系統です。どの系統のメトリクスかを意識しておくと、値が出ないときの原因を探しやすくなります。

kube-prometheus-stackを導入する

検証用のクラスタで試してから本番に入れることを前提に、最小限の手順を示します。

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

kubectl create namespace monitoring
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring

導入後、Podがすべて Running になったかを確認します。

kubectl get pods -n monitoring

Grafanaにログインする

最初はポートフォワードで、外部に公開せずに接続します。

# Service名を確認（リリース名-grafana になるのが一般的）
kubectl get svc -n monitoring | grep grafana

kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

ブラウザで http://localhost:3000 を開きます。管理者のパスワードはSecretに入っているので、そこから読み出します。

kubectl get secret -n monitoring monitoring-grafana \
  -o jsonpath='{.data.admin-password}' | base64 -d; echo

チャートの既定のパスワードは公開情報なので、そのまま使い続けず、valuesで変更するか、既存のSecretを参照させる設定にします。

自作ダッシュボードを作る

最初は同梱のダッシュボードを眺めて、どんなパネルがあるかをつかむのがおすすめです。そのうえで、自分のアプリの名前空間に絞ったダッシュボードを作ると、日常の確認が楽になります。

名前空間を切り替える変数を作る

ダッシュボードの設定からVariables（変数）を追加し、種類をQuery、データソースをPrometheusにして、次のクエリを入れます。

label_values(kube_pod_info, namespace)

変数名を namespace にすると、ダッシュボード上部のプルダウンで名前空間を切り替えられ、パネルのクエリでは $namespace として使えます。同じ要領で label_values(kube_pod_info{namespace="$namespace"}, pod) を変数 pod にすれば、Pod単位の絞り込みもできます。

よく使うパネルとPromQL

PodごとのCPU使用量（単位はコア）：

sum by (pod) (
  rate(container_cpu_usage_seconds_total{namespace="$namespace", container!=""}[$__rate_interval])
)

container!="" は、Pod全体の合計を表す系列を除くための条件です。これが無いと、同じ使用量を二重に数えてしまいます。$__rate_interval はGrafanaが収集間隔に合わせて範囲を決めてくれる変数で、固定の [1m] より値が欠けにくくなります。

Podごとのメモリ使用量：

sum by (pod) (
  container_memory_working_set_bytes{namespace="$namespace", container!=""}
)

OOMKilledの判定に近いのは、working set の値です。パネルの単位をbytesにすると読みやすく表示されます。

requestsに対するCPU使用率：

sum by (pod) (rate(container_cpu_usage_seconds_total{namespace="$namespace", container!=""}[$__rate_interval]))
/
sum by (pod) (kube_pod_container_resource_requests{namespace="$namespace", resource="cpu"})

1を大きく超えるPodはrequestsが小さすぎ、0.1を下回り続けるPodは大きすぎる可能性があります。requestsはスケジューリングやノードの自動増減の基準になるため、このパネルは費用の見直しにも役立ちます。

再起動の回数（直近1時間）：

sum by (pod) (
  increase(kube_pod_container_status_restarts_total{namespace="$namespace"}[1h])
)

Readyになっていないコンテナ：

count by (pod) (kube_pod_container_status_ready{namespace="$namespace"} == 0)

Readyでないコンテナの数をPodごとに数えます。0件のときはパネルに「No data」と出ますが、異常が無いという意味です。紛らわしい場合は、パネルの設定で値が無いときの表示を0にします。

ノードのCPU使用率：

1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[$__rate_interval]))

パネルを作るときの考え方

パネルを増やしすぎると、障害時にどこを見ればよいか分からなくなります。上段に「今おかしいか」（Ready数、再起動回数、エラー率）、中段に「どこがおかしいか」（PodごとのCPU・メモリ）、下段に「なぜか」（ノードの資源、requestsとの比較）という順に並べると、上から下へ読むだけで調査の順番になります。

ダッシュボードをコードで管理する

画面で作ったダッシュボードは、GrafanaのPod内のデータベースに保存されます。永続ボリュームを設定していないと、Podの作り直しで消えます。チームで運用するなら、JSONとして書き出してGitで管理し、ConfigMapから読み込ませる方法が扱いやすくなります。

ダッシュボードの共有メニューからJSONを書き出したら、次のようなConfigMapにします。

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-dashboard
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  app-dashboard.json: |
    { "title": "App overview", "panels": [] }

kube-prometheus-stackのGrafanaでは、特定のラベルを持つConfigMapをサイドカーが見つけてダッシュボードとして読み込む設定が既定で有効になっています。ラベル名と値（上の例の grafana_dashboard: "1"）は、チャートのvaluesの grafana.sidecar.dashboards 付近の項目で決まるため、使っている版のvaluesで確認してください。data の中身は、書き出したJSONに置き換えます。

この方法で読み込んだダッシュボードは、画面で編集しても次の読み込みで上書きされることがあります。変更はJSONを直してGit経由で反映する、という流れに統一しておくと混乱がありません。

公開とセキュリティの注意点

いきなりインターネットに公開しない：IngressでGrafanaを公開する場合は、TLSを有効にし、匿名アクセスを無効のままにします。可能ならSSOやVPN経由のアクセスに限ります。
管理者アカウントを日常で使わない：閲覧用には権限の弱いユーザーやチームを作ります。
ダッシュボードから機密が漏れないか確かめる：ラベルにメールアドレスや内部のホスト名が入っていると、そのまま画面に表示されます。

アラートは、Grafana側のアラート機能とPrometheusのAlertmanagerのどちらでも作れます。二重に通知が飛ばないよう、どちらで管理するかを先に決めておきます。

まとめ

kube-prometheus-stackを入れると、Prometheus・kube-state-metrics・node-exporter・Grafanaと基本ダッシュボードがまとめて揃います。
管理者パスワードはSecretから読み出し、既定値のまま使い続けないようにします。
自作ダッシュボードは label_values で名前空間の変数を作り、CPU・メモリ・requests比・再起動回数・Ready状態のパネルから始めます。
PromQLでは container!="" で二重計上を避け、$__rate_interval を使います。
ダッシュボードはJSONで書き出してConfigMapで管理し、Grafanaを外部に公開するときはTLSと認証を整えてからにします。