個人で運用しているKubernetesクラスタに、Prometheus Operatorで監視を入れてみました。セットアップと運用で分かったことの記録です。
構成の概要
使っているのは Prometheus Operator + Helmfile の組み合わせです。kube-prometheus-stackというHelmチャートをベースにして、必要なExporter(Redis、MySQL)を追加しています。
Cloud MonitoringやDatadogも候補でしたが、個人の小さなクラスタに追加コストをかける気にはならず、Prometheusを選びました。
Helmfileで管理する
kube-prometheus-stackのvalues.yamlはデフォルトだけで数千行あるので、 helm install 直叩きはすぐ辛くなります。Helmfileを使っています。
repositories:
- name: prometheus-community
url: https://prometheus-community.github.io/helm-charts
releases:
- name: prometheus
namespace: monitoring
chart: prometheus-community/kube-prometheus-stack
version: 41.9.1
values:
- values/prometheus.yaml
バージョンをピン留めして、values.yamlを別ファイルに分離しておけばGitで差分を追えます。複数チャートを扱うようになると helmfile sync で一発再現できるのがありがたいです。
ServiceMonitorのラベル — 地味にハマる
運用していて一番ハマったのがServiceMonitorのラベルマッチングでした。
Prometheus OperatorがServiceMonitorを認識するには、Prometheus CRの serviceMonitorSelector に一致するラベルが付いている必要があります。kube-prometheus-stackではHelmのrelease名がそのままラベル値になるため、この構成(release名 = prometheus)では release: prometheus が必要です。
# Prometheus側の設定
spec:
serviceMonitorSelector:
matchLabels:
release: prometheus
# Redis ExporterのServiceMonitor
serviceMonitor:
enabled: true
namespace: monitoring
labels:
release: prometheus # ← これがないとメトリクスが来ない
厄介なのは、ラベルが合っていなくてもエラーにならないこと。ServiceMonitorは普通にデプロイされ、kubectl get でも見えます。ただPrometheusが無視するだけ。Exporterのログを見て、Serviceの疎通を確認して、最後に「ラベルが足りなかった」と気づく——という遠回りを一度やりました。
以降、Exporterを追加したら必ず確認しています。
# Prometheusが期待するラベルを確認
kubectl -n monitoring get prometheus -o yaml | grep -A 3 serviceMonitorSelector
# ServiceMonitorのラベルを確認
kubectl -n monitoring get servicemonitor -o yaml | grep -A 2 labels
まとめ
以前は helm install 直叩きで管理していましたが、差分管理が面倒でやめました。Helmfileに切り替えてからは構成管理がだいぶ楽です。
Prometheus Operatorの学習コストはそれなりにありますが、運用の手間は想像より軽かったです。
![[Kubernetes] Prometheus MySQL Exporter インストール方法](/tcard/cecde373-ca85-46a7-b944-faae23d9e279/2022-11-23-cecde373-ca85-46a7-b944-faae23d9e279.webp)

