ようこそ、オブザーバビリティの世界へ。
Kubernetes（K8s）という広大な宇宙を航行する際、羅針盤（モニタリング）なしで進むのは、霧の中を全速力で走るようなものです。かつて私たちは、サーバー一台一台にログインしては `top` コマンドを叩いていましたが、現代のマイクロサービス環境ではそれは不可能です。
今日は、K8s監視のデファクトスタンダードであり、もはや「これ一択」と言っても過言ではない Prometheus Operator、およびその集合体である kube-prometheus-stack についてお話しします。
この記事を読み終える頃には、あなたは「動的なインフラをどうやって静的な設定なしで監視し続けるか」という難問に対する、エレガントな解法を手にしているはずです。
—
1. K8s監視におけるPrometheusの「正解」：Operatorパターン
まず、なぜ普通の Prometheus をそのまま K8s に入れるだけでは不十分なのか、その本質を理解しましょう。
K8s の最大の特徴は「動的（Dynamic）」であることです。Pod は生まれ、消え、IPアドレスは常に変わります。従来の `prometheus.yml` にターゲットのIPを書き込む手法では、10分も経てば設定はゴミと化します。
そこで登場したのが Prometheus Operator です。
これは、「Prometheus の設定を K8s のカスタムリソース（CRD）として定義し、その変更をプログラムが監視して、Prometheus の設定を自動で書き換える」という仕組みです。
- 手動管理： 職人が `prometheus.yml` を書き、リロードする（ミスが起きやすい）。
- Operator管理： 「このラベルがついたサービスを監視せよ」という宣言を K8s に投げるだけ。あとは Operator がすべてやってくれる。
この「宣言的（Declarative）」なアプローチこそが、K8s 運用を劇的に楽にする鍵なのです。
—
2. Helmを使った kube-prometheus-stack のデプロイ
それでは、実際に動かしてみましょう。
現在、最も推奨されるインストール方法は、Prometheus、Grafana、Alertmanager、そして各種エクスポーターがセットになった `kube-prometheus-stack` を Helm で導入することです。
インストール手順
まず、Helm リポジトリを追加します。
リポジトリの追加
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
監視専用のNamespaceを作成
kubectl create namespace monitoring
次に、インストールを実行します。初期学習用であれば、デフォルト設定で十分ですが、本番では `values.yaml` をカスタマイズするのが定石です。
kube-prometheus-stack のインストール
helm install prometheus-stack prometheus-community/kube-prometheus-stack \
–namespace monitoring
これだけで、K8s クラスターの CPU、メモリ、ネットワーク、さらには各ノードの健康状態を監視する最強の布陣が整います。
—
3. ServiceMonitor：監視対象を「自動発見」させる魔術
ここがこの記事で最も重要なポイントです。
インストールが終わった後、自分の作ったアプリケーションをどうやって Prometheus に認識させるのでしょうか？
その答えが ServiceMonitor です。
仕組み
Prometheus Operator は、クラスター内の `ServiceMonitor` というリソースを常に監視しています。新しい `ServiceMonitor` が作成されると、Operator は即座に Prometheus の設定を更新し、ターゲットへのスクレイピング（メトリクス収集）を開始します。
具体的な設定例
例えば、`/metrics` エンドポイントを持つ Go アプリケーションがあるとしましょう。
1. アプリケーションの Service 定義
apiVersion: v1
kind: Service
metadata:
name: my-app-service
labels:
app: my-app # このラベルが重要！
spec:
ports:
- name: web
port: 8080
selector:
app: my-app
—
2. ServiceMonitor の定義（これが Prometheus への指示書）
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app-monitor
namespace: monitoring
labels:
release: prometheus-stack # Helmチャートが認識するためのラベル（重要）
spec:
selector:
matchLabels:
app: my-app # 監視対象の Service のラベルと一致させる
endpoints:
- port: web # Service で定義したポート名
path: /metrics # メトリクスが露出されているパス
interval: 30s # 収集間隔
ここがポイント：
`ServiceMonitor` を作成するだけで、Prometheus 本体の再起動も設定ファイルの書き換えも不要です。開発者は自分のアプリと一緒にこの YAML をデプロイするだけで、監視が自動的にスタートします。これが「K8s ネイティブ」な運用の美しさです。
—
4. リソース枯渇を防ぐための「現場の知見」
Prometheus は非常に強力ですが、何も考えずに運用すると、ある日突然メモリ不足（OOM Killer）で死にます。これは、収集するメトリクスの量（カーディナリティ）が爆発するためです。
現場で震えるような障害を起こさないための、3つの鉄則をお伝えします。
① リソース制限（Limits）の明示
Prometheus のメモリ使用量は、収集する「時系列データ数」に比例します。必ず `values.yaml` で制限をかけましょう。
prometheus:
prometheusSpec:
resources:
requests:
memory: 2Gi
limits:
memory: 4Gi
② 保存期間とサイズの制御
デフォルトでは「15日間」データを保持しますが、ディスク容量も有限です。時間（retention）だけでなく、サイズ（retentionSize）でも制限をかけるのがプロの技です。
retention: 10d
retentionSize: “20GB”
③ 「高カーディナリティ」なラベルを避ける
例えば、ラベルに「ユーザーID」や「セッションID」を入れてはいけません。ユーザーが100万人いれば、100万通りの時系列データが生成され、Prometheus のメモリを一瞬で食い尽くします。ラベルは「種類を特定できる程度の粒度」に留めるのが鉄則です。
—
最後に：あなたに贈るアドバイス
Prometheus 運用において、一番大切なのは「完璧なダッシュボードを作ること」ではありません。「異常が起きたときに、自信を持ってその原因を探れる状態を作っておくこと」です。
今回紹介した `kube-prometheus-stack` と `ServiceMonitor` をマスターすれば、インフラの変更に怯える日々は終わります。システムが生き物のように変化しても、監視がそれに自動で追随してくれるからです。
まずは自分のアプリをデプロイし、`ServiceMonitor` でメトリクスが Grafana に流れてくる瞬間を目撃してください。その時、あなたは一歩先のエンジニアへと進化しているはずです。
もし設定で迷ったら、いつでも聞いてください。オブザーバビリティの道は深く、そして楽しいものです。
健闘を祈ります！