Prometheus on LIFELOG

Kubernetes監視入門第6回｜GKEとGoogle Cloud Managed Service for Prometheusへ展開する

Sat, 03 Oct 2026 00:00:00 +0900

概要
#

第1回から第5回までは、minikube上にPrometheus・Grafana・Prometheus Operator・kube-prometheus-stackを自分で構築し、仕組みを1つずつ確認してきた。ここまでの構成はすべて、自分でPrometheusを運用する前提（self-managed）だった。

GKE Autopilot 1.25以降、GKE Standard 1.27以降では、Google Cloud Managed Service for Prometheus（以下GMP）のManaged Collectionが既定で有効になっている。Standardはクラスタ作成時に無効化できるが、Autopilot 1.25以降では無効化できない。GMPが管理するのはCollectorのスケール・保存先（Monarch）・PromQLクエリの処理基盤であり、Exporterのインストールや、ServiceMonitor / PodMonitor / PrometheusRuleに代わるPodMonitoring / ClusterPodMonitoring / Rulesの適用は引き続き利用者側の責任である。

この記事では、GKE Standardクラスタを作り、第1回〜第5回の手動構成がGMPのCustom Resourceでどう表現されるかを実測する。可視化については、収集・保存がマネージドであることと、Grafanaを使い続けるかどうかは別の軸であることを示すため、次の2パターンを確認する。パターンAはCloud Monitoring Dashboardのウィジェットが使うクエリと同じPromQLで実際に時系列を取得できることまで、パターンBはPromQL APIでの取得とdata sourceの設定までを確認する。いずれもブラウザ上での画面描画そのものは確認していない。

パターンA（可視化までGoogle Cloudで完結）: Cloud Monitoring（Metrics Explorer・Dashboard）のPromQL APIで同じメトリクスを取得できるかを確認する。これを本線とする
パターンB（Grafana継続利用）: GrafanaをGKE上に再デプロイし、第1回で作ったDashboard資産のPromQL定義をそのまま使ったクエリがAPI経由で同じ値を返すかを確認する

対象読者は、第1回〜第5回でPrometheusのkubernetes_sd_configs・Prometheus Operator・kube-prometheus-stackを手で構築した経験がある人。GKE・GMPに初めて触れる人を想定している。マルチクラスタ・マルチプロジェクトでのメトリクス集約、remote_write・federationなどの高度な構成は扱わない。

今回使う環境
#

第1回〜第5回のminikube環境とは別に、GKE Standardクラスタを新規に作る。第1回から使っているnode-exporterのDaemonSetはhostNetwork: true / hostPID: trueを設定し、hostPath: path: /をreadOnly: trueでマウントしている。GKE AutopilotはhostNetworkとhost namespaceを許可せず、hostPathについても書き込みモードは全面禁止、read-onlyモードでも/var/log/配下のパスのみを許可するため、/をマウントする同じManifestを再利用できない。同じExporter・同じPromQLクエリで第5回までと比較するという本記事の目的上、GKE Standardを選ぶ。

Kubernetes監視入門第5回｜Prometheus OperatorとServiceMonitor・PodMonitorでkube-prometheus-stackを使う

Fri, 02 Oct 2026 00:00:00 +0900

概要
#

第4回では、kubernetes_sd_configsとrelabel_configsを手で書き、Prometheus用のRBACも自分で用意した。対象がNode Exporterとkube-state-metricsの2種類だけでもこれだけの記述が必要だった。監視対象が増えるほどkubernetes_sd_configsやrelabel_configsの管理対象も増え、実運用では保守負荷が高くなる。

Prometheus Operatorは、この繰り返しをCRD（Custom Resource Definition）で定義された型のリソースに置き換える。ServiceMonitor・PodMonitor・PrometheusRuleといったCustom Resourceを作るだけで、Operatorがそれらを読み取り、対応するPrometheus設定を生成する。この記事では、kube-prometheus-stack（Prometheus OperatorとPrometheus本体・Alertmanager・kube-state-metricsなどをまとめたHelm chart）を導入し、第1回〜第4回で手で書いた設定がこれらのCustom Resourceでどう表現されるかを、実際に生成された設定と見比べながら確認する。

対象読者は、第1回〜第4回でPrometheusのkubernetes_sd_configs・alerting rule・RBACを手で書いた経験がある人。Prometheus Operator・kube-prometheus-stackに初めて触れる人を想定している。GKEやGoogle Cloud Managed Service for Prometheusは次回（第6回）で扱う。Alertmanagerの高可用構成、long-term storage、Grafana Operatorなど追加コンポーネントは扱わない。

今回使う環境
#

第1回〜第4回で使っているminikube（--driver=docker、container runtime は containerd）をそのまま使う。minikube・Kubernetes・kubectlのバージョンは変えていない。開始時点は第4回の「元に戻す」を終えた状態、つまりsingle-nodeで、monitoring NamespaceにNode Exporter・Prometheus（static_configs構成）・Grafanaだけが動いている状態を前提とする。第4回で追加したkube-state-metrics・Prometheus用RBAC・kubernetes_sd_configsは、比較のために参照はするが、今回の開始時点では存在しない。

minikube version: v1.39.0
Kubernetes (Server Version): v1.37.0
kubectl (Client Version): v1.34.5-dispatcher

kubectlのクライアント版（1.34）とサーバー版（1.37）は、Kubernetesのversion skew policyが定める前後1マイナーバージョンの範囲を超えている。第1回から変えていない既知の状態であり、この記事内のコマンドはいずれも動作したが、再現する場合はサーバーと同じ1.37系のkubectlを使うことを勧める。

Kubernetes監視入門第4回｜kubernetes_sd_configsとkube-state-metricsでPod・Nodeの状態を追う

Wed, 30 Sep 2026 00:00:00 +0900

概要
#

第1回はstatic_configsでNode Exporterを1台だけ固定して監視した。そこで、Kubernetes上ではPodが増減し、Service Discoveryで検出対象自体が変わるケースには対応できないことを予告していた。第3回でも、up{job=...}==0はPrometheusが既に知っているtargetへのscrape失敗しか検知できず、対象がService Discoveryで消えるケースは別問題だと明記した。

この記事では、その課題に対応するkubernetes_sd_configsを扱う。Node Exporterを2台に増やし、static_configsでServiceを指定した構成ではtargetが1件のままで、背後の2台を個別に区別できないことを実際に確認したうえで、Podを1台ずつ個別のtargetとして検出する設定に切り替える。もう1つ、Kubernetesオブジェクト自体の状態（PodのphaseやNodeのReady状態など）をメトリクス化するkube-state-metricsも導入する。

対象読者は、第1回〜第3回でPrometheus・Node Exporter・Alertmanagerの基本操作を経験した人。Prometheus OperatorやServiceMonitor、kube-prometheus-stackは扱わない（次回で扱う）。

今回使う環境
#

第1回〜第3回で使ったminikube（--driver=docker、container runtime は containerd）をそのまま使う。minikube・Kubernetes・kubectlのバージョンは変えていない。

minikube version: v1.39.0
Kubernetes (Server Version): v1.37.0
kubectl (Client Version): v1.34.5-dispatcher

今回はNode Exporterの複数pod化を確認するため、minikubeのマルチノードクラスタとしてworker nodeを1台追加する。

minikube node add -p prometheus-grafana-intro --worker
kubectl get nodes -o wide

NAME                           STATUS   ROLES           VERSION
prometheus-grafana-intro       Ready    control-plane   v1.37.0
prometheus-grafana-intro-m02   Ready    <none>          v1.37.0

Node ExporterはDaemonSetで動かしているため、新しいNodeを追加すると、そのNodeにもPodが自動で作成される。

Alerting入門第3回｜Prometheus Alerting rulesとAlertmanagerで通知を送る

Sun, 27 Sep 2026 00:00:00 +0900

概要
#

第1回・第2回では、人がPromQLを実行して状態を確認するところまでを扱った。条件を満たしたときに自動で通知する仕組みはまだ扱っていない。実際の運用では、条件を式として登録しておき、一定時間満たされ続けたら通知が届く、という流れが必要になる。

この記事では、Prometheusのalerting ruleとAlertmanagerを使って、scrape失敗を検知してから通知が届くまでの流れを実際に動かして確認する。対象読者は、第1回・第2回でPrometheusへのクエリ実行を経験した人。alerting ruleやAlertmanagerに初めて触れる人を想定している。

この記事では、複数のレシーバーを使い分けるような複雑なルーティングは扱わない。Slack・PagerDutyなど外部サービスとの連携も扱わない。認証情報が必要になり、この記事の主題である「pending・firing・通知」の流れから外れるためである。

Grafana Alertingも扱わない。Grafana自体が持つ別の仕組みであり、Prometheus Alertmanagerとは別物である。

今回使う環境
#

第1回・第2回で構築したminikube v1.39.0（Kubernetes v1.37.0）上のmonitoring Namespace（Node Exporter・Prometheus・Grafana）をそのまま使う。Prometheus prom/prometheus:v3.14.0、Node Exporter prom/node-exporter:v1.12.1は版を変えていない。

今回は、本記事の主題であるAlertmanagerを新規に追加する。検証時点でprom/alertmanager:latestを実行し、docker run --rm prom/alertmanager:latest --versionでv0.34.1であることを確認した。再現性のため、Manifestではprom/alertmanager:v0.34.1に固定して使う。

もう1つ、webhook-receiverという小さなPodを追加する。Alertmanagerが実際に通知を送ったことを、Slackなど外部サービスに依存せず確認するためである。python:3.13-alpine上でPOSTを受け取り、受信時刻（UTC）と本文を1行にまとめて標準出力へ出すだけの、20行に満たないスクリプトをConfigMapでマウントしている。Deployment・Service・ConfigMapの3つに留め、認証や永続化は持たない。

Prometheus側にも変更を加える。alerting ruleを読み込むためのrule_filesと、通知先を指定するalerting.alertmanagersをprometheus-configのConfigMapに追加した。alerting ruleの本体は新しいConfigMap（prometheus-rules）に分け、PrometheusのDeploymentにrulesというVolumeとして追加でマウントしている。

flowchart LR
    subgraph monitoring["monitoring Namespace"]
        NE["node-exporter
(DaemonSet)"]
        PR["Prometheus"]
        AM["Alertmanager"]
        WH["webhook-receiver"]
        NE -- "scrape :9100" --> PR
        PR -- "firing alert" --> AM
        AM -- "webhook POST" --> WH
    end

追加するマニフェストは、記事ディレクトリのsample/にある。記事ディレクトリを作業ディレクトリとして、次の順に適用する。

PromQL入門第2回｜チートシート形式で早引きするrate・increase・topk・histogram_quantile

Sat, 26 Sep 2026 00:00:00 +0900

概要
#

「CPU使用率が高いノードを知りたい」「p95レイテンシを見たい」と思っても、目的からPromQLの書き方にすぐ辿り着けないことがある。第1回では、Prometheus・Grafanaの役割を扱った。PromQLもrate()・sum()・avg()・by()という最小限だけに触れている。実際の調査でよく使うincrease()・topk()・histogram_quantile()や、instant vectorとrange vectorの違いはまだ扱っていない。

この記事では、これらの関数を実際のクエリ結果とともに整理する。対象読者は、第1回でPrometheusにPromQLクエリを送信する操作は経験した人。[5m]のような時間指定の意味や、rate()とincrease()の使い分けがまだ曖昧な人を想定している。Kubernetes・kubectlの基本操作とPromQLでの単純なmetric取得は前提とする。

この記事ではAlerting rules・Alertmanager（第3回）は扱わない。Kubernetes Service Discovery・kube-state-metrics（第4回）も扱わない。新しいコンポーネントの追加も行わず、第1回のminikube環境をそのまま使う。

まず見る：目的から引けるチートシート
#

式の形だけ先に引きたい場合はここを見る。それぞれの根拠・実測は後続の節にある。

やりたいこと	PromQL
いまの値を1点だけ見る	`metric_name{label="value"}`
直近5分間のサンプルをまとめて取得する	`metric_name{label="value"}[5m]`
counterの1秒あたりの増加率を出す（グラフ・記録ルール向け）	`rate(metric_name[5m])`
counterの期間中の増加量を出す（人が読む数値向け）	`increase(metric_name[5m])`
ラベルごとに集計しつつ、そのラベルだけ残す	`sum by(label) (expr)`
特定のラベルだけ落として集計する	`sum without(label) (expr)`
複数本のメトリクスのうち最大値だけ見る（ラベルは残らない）	`max(expr)`
最大値と、それがどのラベルの組み合わせかも見る	`topk(1, expr)`
メモリ使用率を出す	`(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100`
ディスク使用率を出す（マウントポイント指定）	`(1 - node_filesystem_avail_bytes{mountpoint="/path"} / node_filesystem_size_bytes{mountpoint="/path"}) * 100`
ネットワークの受信量（bytes/sec）を出す	`rate(node_network_receive_bytes_total{device!="lo"}[5m])`
コア単位で上位N件だけ抽出する（single-node）	`topk(N, sum by(cpu) (expr))`
ノード単位で上位N件だけ抽出する（複数ノード）	`topk(N, <instanceでまとめた式>)`（集約の仕方はmetricの意味次第。CPU使用率なら`avg by(instance)`）
ヒストグラムからp95などのパーセンタイルを出す	`histogram_quantile(0.95, sum by(le) (rate(metric_bucket[5m])))`

今回使う環境
#

第1回で作成したmonitoring Namespaceの構成（Node Exporter・Prometheus・Grafana）をそのまま使う。バージョンも第1回から変えていない。minikube v1.39.0（--driver=docker）、Kubernetes v1.37.0、Prometheus prom/prometheus:v3.14.0、Node Exporter prom/node-exporter:v1.12.1である。すべてローカルのminikube上で完結し、クラウドの課金は発生しない。

Prometheus・Grafana入門第1回｜minikubeでメトリクス収集からダッシュボード作成まで

Fri, 25 Sep 2026 00:00:00 +0900

概要
#

Prometheus と Grafana は監視でよく使われるが、名前だけ知っていると役割が重なって見える。どちらもグラフを表示できるし、Exporter が何のために要るのかもはっきりしない。

この2つは役割が違う。Prometheus はメトリクスを集めて保存し、問い合わせに応える。Prometheus 自身にも Graph タブがあるため、グラフ表示そのものは Grafana が無くてもできる。

Grafana が違うのは、複数の Panel をまとめた Dashboard として保存し、共有できる点である。Grafana が Prometheus に PromQL を送って結果を描くという順番を、触って確認する。

対象読者は、Prometheus の画面を開いたことがなく、PromQL もこれから学びたい人。minikube と kubectl の基本操作（kubectl apply や kubectl get）は前提とする。

この記事では PromQL の詳細、Alertmanager、Prometheus Operator、GKE への展開は扱わない。kube-prometheus-stack も使わない。

Deployment や DaemonSet の Manifest は自分で書く。Operator が後から何を隠すのかを、次回以降で比較できるようにするためである。

検証すること
#

Prometheus・Grafana・Exporter・PromQL の役割分担
minikube 上に Prometheus・Node Exporter・Grafana を Manifest だけで構築する
Prometheus が Node Exporter を static_configs で scrape する経路
Grafana に Prometheus を Data source として登録し、Dashboard を作る
今回の構成が非永続であること、Node Exporter が何を監視しているかの実際の範囲

今回の構成
#

Node Exporter がホストのメトリクスを /metrics に公開し、Prometheus がそれを scrape して保存する。Grafana は Prometheus に対して PromQL で問い合わせ、結果を Dashboard に描く。

Prometheus on LIFELOG

Kubernetes監視入門 第6回｜GKEとGoogle Cloud Managed Service for Prometheusへ展開する

概要 #

今回使う環境 #

Kubernetes監視入門 第5回｜Prometheus OperatorとServiceMonitor・PodMonitorでkube-prometheus-stackを使う

概要 #

今回使う環境 #

Kubernetes監視入門 第4回｜kubernetes_sd_configsとkube-state-metricsでPod・Nodeの状態を追う

概要 #

今回使う環境 #

Alerting入門 第3回｜Prometheus Alerting rulesとAlertmanagerで通知を送る

概要 #

今回使う環境 #

PromQL入門 第2回｜チートシート形式で早引きするrate・increase・topk・histogram_quantile

概要 #

まず見る：目的から引けるチートシート #

今回使う環境 #

Prometheus・Grafana入門 第1回｜minikubeでメトリクス収集からダッシュボード作成まで

概要 #

検証すること #

今回の構成 #

Kubernetes監視入門第6回｜GKEとGoogle Cloud Managed Service for Prometheusへ展開する

概要
#

今回使う環境
#

Kubernetes監視入門第5回｜Prometheus OperatorとServiceMonitor・PodMonitorでkube-prometheus-stackを使う

概要
#

今回使う環境
#

Kubernetes監視入門第4回｜kubernetes_sd_configsとkube-state-metricsでPod・Nodeの状態を追う

概要
#

今回使う環境
#

Alerting入門第3回｜Prometheus Alerting rulesとAlertmanagerで通知を送る

概要
#

今回使う環境
#

PromQL入門第2回｜チートシート形式で早引きするrate・increase・topk・histogram_quantile

概要
#

まず見る：目的から引けるチートシート
#

今回使う環境
#

Prometheus・Grafana入門第1回｜minikubeでメトリクス収集からダッシュボード作成まで

概要
#

検証すること
#

今回の構成
#