KubernetesクラスタにPrometheusで監視を入れた記録

個人で運用している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の学習コストはそれなりにありますが、運用の手間は想像より軽かったです。

Related Posts