Prometheus + Grafanaで構築する最強のKubernetes監視環境【2025年完全ガイド】

インフラ・ネットワーク

深夜2時、Slackに障害アラートが響く。CPUスパイク、メモリリーク、ポッドの異常終了…。こんな経験、ありませんか？

Kubernetesクラスターの運用において、適切な監視システムは命綱です。2025年現在、Prometheus + Grafanaの組み合わせは、Kubernetes監視のゴールドスタンダードとして確固たる地位を築いています。

本記事では、Prometheus 3.5.0 LTSと最新のGrafanaを使った監視環境の構築方法を、実践的なコード例とともに詳しく解説します。従来のメトリクス監視から、OpenTelemetryを活用した3 Pillars of Observability（メトリクス、ログ、トレース）の統合まで、現代のクラウドネイティブ環境に必要な監視戦略をお伝えします。

じゅんち８

私は過去にPrometheusのアラート設定が不完全で、本番環境のディスク容量不足を見逃し、深夜3時に緊急対応をした経験があります。その経験から学んだ「本当に使える」監視設定をお伝えします。

なぜKubernetes監視が重要なのか

現代のマイクロサービス環境の複雑さ

Kubernetesクラスターは、数百から数千のコンテナが動的に作成・削除される複雑な環境です。従来の仮想マシン監視とは異なり、以下の特徴があります：

  • 短期間で消失するリソース: ポッドは数分で作成・削除される
  • 動的なサービス発見: IPアドレスやホスト名が常に変化
  • 複雑な依存関係: マイクロサービス間の通信パス
  • リソース制約: CPUやメモリの制限と要求

監視なしで起こりうる問題

適切な監視がない環境では、以下のような問題が発生します：

  1. レスポンス時間の劣化: ユーザーが気づく前に検知できない
  2. リソース枯渇: CPU、メモリ、ディスクの不足を見逃す
  3. カスケード障害: 一つのサービスの問題が全体に波及
  4. パフォーマンス最適化の機会損失: ボトルネックの特定ができない

Prometheus + Grafanaの基本概念

Prometheusのアーキテクチャ

Prometheusはプル型のメトリクス収集システムです。定期的にターゲットからメトリクスを取得し、時系列データベースに保存します。

┌─────────────┐    HTTP GET    ┌─────────────┐
│ Application │ ◄────────────── │ Prometheus  │
│   :8080/    │                 │   Server    │
│  /metrics   │                 └─────────────┘
└─────────────┘                        │
                                        │
┌─────────────┐                        │
│   Grafana   │ ◄──────────────────────┘
│  Dashboard  │      PromQL Query
└─────────────┘

重要な構成要素

  • Prometheus Server: メトリクス収集・保存・クエリ処理
  • Grafana: 可視化とダッシュボード作成
  • Alertmanager: アラート通知の管理
  • Node Exporter: ホストレベルメトリクス収集
  • kube-state-metrics: Kubernetesオブジェクトの状態メトリクス

2025年最新：3 Pillars of Observabilityの統合

OpenTelemetryによる統合監視

2025年現在、Observabilityは以下の3つの柱で構成されます：

  1. メトリクス（Metrics）: Prometheus
  2. ログ（Logs）: Grafana Loki
  3. トレース（Traces）: Grafana Tempo
┌─────────────────┐
│ OpenTelemetry   │
│    Collector    │
├─────────────────┤
│ Metrics → Prom  │
│ Logs → Loki     │
│ Traces → Tempo  │
└─────────────────┘

なぜ統合が重要か

従来はメトリクスのみを監視していましたが、現代の複雑なシステムでは：

  • メトリクス: 何が起こっているか（CPU使用率、エラー率）
  • ログ: なぜ起こったか（エラーメッセージ、スタックトレース）
  • トレース: どこで起こったか（リクエストの流れ、レイテンシ）

この3つを組み合わせることで、問題の根本原因を素早く特定できます。

実践：kube-prometheus-stackによる構築

Helmを使った導入

kube-prometheus-stackは、Prometheus、Grafana、Alertmanagerを統合したHelm chartです。

# Helm repositoryの追加
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 専用namespaceの作成
kubectl create namespace monitoring

# values.yamlの準備（基本設定）
cat > values.yaml << EOF
prometheus:
  prometheusSpec:
    retention: 15d
    retentionSize: 50GiB
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi

grafana:
  persistence:
    enabled: true
    storageClassName: gp3
    size: 10Gi
  adminPassword: your-secure-password
  
  # Grafana Loki統合
  additionalDataSources:
    - name: Loki
      type: loki
      url: http://loki:3100
      
    - name: Tempo
      type: tempo
      url: http://tempo:3100

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi

# Node Exporterの有効化
nodeExporter:
  enabled: true

# kube-state-metricsの有効化
kubeStateMetrics:
  enabled: true
EOF

# インストール実行
helm install prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --values values.yaml

インストール後の確認

# ポッドの確認
kubectl get pods -n monitoring

# サービスの確認
kubectl get svc -n monitoring

# Grafanaへのアクセス設定
kubectl port-forward -n monitoring svc/prometheus-stack-grafana 3000:80

ServiceMonitor/PodMonitorの設定方法

ServiceMonitorとは

ServiceMonitorは、Kubernetesのサービスを監視対象として自動発見する仕組みです。アプリケーションに対して、以下のような設定を行います。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: default
  labels:
    app: my-app
    release: prometheus-stack  # kube-prometheus-stackのlabelSelectorに一致
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: metrics  # サービスのポート名
    interval: 30s
    path: /metrics
    scheme: http

アプリケーションサービスの例

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  labels:
    app: my-app
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  - name: metrics  # Prometheusメトリクス用ポート
    port: 9090
    targetPort: 9090
  selector:
    app: my-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:latest
        ports:
        - containerPort: 8080
          name: http
        - containerPort: 9090
          name: metrics

PodMonitorの活用

特定のポッドを直接監視したい場合は、PodMonitorを使用します：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: my-pod-monitor
  namespace: default
  labels:
    release: prometheus-stack
spec:
  selector:
    matchLabels:
      app: critical-service
  podMetricsEndpoints:
  - port: metrics
    interval: 15s
    path: /metrics
じゅんち８

ServiceMonitorとPodMonitorの違いで混乱したことがあります。ServiceMonitorはService経由、PodMonitorは直接Podを監視します。通常はServiceMonitorを使い、特別なケースでPodMonitorを選択するのが良いでしょう。

実用的なダッシュボードとアラート設定

必須ダッシュボード

Grafanaには事前に優秀なダッシュボードが用意されています：

  1. Kubernetes / Compute Resources / Cluster: クラスター全体のリソース使用状況
  2. Kubernetes / Compute Resources / Namespace: ネームスペース別リソース
  3. Kubernetes / Compute Resources / Pod: 個別ポッドの詳細
  4. Node Exporter Full: ノードレベルの詳細メトリクス

カスタムダッシュボードの作成

実用的なPromQLクエリの例：

# CPUスロットリング率の監視
rate(container_cpu_cfs_throttled_seconds_total[5m]) / rate(container_cpu_cfs_periods_total[5m]) * 100

# メモリ使用率（上限に対する比率）
container_memory_working_set_bytes / container_spec_memory_limit_bytes * 100

# ポッドの再起動回数（1時間あたり）
increase(kube_pod_container_status_restarts_total[1h])

# HTTPエラー率（アプリケーション固有）
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100

# ディスク使用率
(node_filesystem_size_bytes{fstype!="tmpfs"} - node_filesystem_avail_bytes{fstype!="tmpfs"}) / node_filesystem_size_bytes{fstype!="tmpfs"} * 100

重要なアラート設定

PrometheusRuleを使ったアラート例：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-alerts
  namespace: monitoring
  labels:
    release: prometheus-stack
spec:
  groups:
  - name: kubernetes.rules
    rules:
    - alert: PodCrashLooping
      expr: rate(kube_pod_container_status_restarts_total[5m]) * 60 * 5 > 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"
        description: "Pod {{ $labels.namespace }}/{{ $labels.pod }} has been restarting {{ $value }} times in the last 5 minutes"
    
    - alert: HighCPUUsage
      expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "High CPU usage on {{ $labels.instance }}"
        description: "CPU usage is above 80% for more than 5 minutes on {{ $labels.instance }}"
    
    - alert: HighMemoryUsage
      expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "High memory usage on {{ $labels.instance }}"
        description: "Memory usage is above 85% for more than 5 minutes on {{ $labels.instance }}"
    
    - alert: DiskSpaceLow
      expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 10
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Disk space is low on {{ $labels.instance }}"
        description: "Disk space is below 10% on {{ $labels.instance }} {{ $labels.mountpoint }}"

Alertmanagerの設定

Slackへの通知設定例：

global:
  slack_api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'slack-notifications'
  routes:
  - match:
      severity: critical
    receiver: 'slack-critical'

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#monitoring'
    title: 'Kubernetes Alert'
    text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}{{ end }}'

- name: 'slack-critical'
  slack_configs:
  - channel: '#alerts-critical'
    title: 'CRITICAL: Kubernetes Alert'
    text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}{{ end }}'
    send_resolved: true

スケーリングとパフォーマンス最適化

Prometheusの高可用性構成

大規模環境では、Prometheus自体の可用性が重要になります：

prometheus:
  prometheusSpec:
    replicas: 2
    
    # シャーディング設定
    shards: 3
    
    # 外部ストレージの設定（Thanos使用）
    thanos:
      image: quay.io/thanos/thanos:v0.34.1
      version: v0.34.1
      objectStorageConfig:
        key: thanos.yaml
        name: thanos-objstore-secret
    
    # リソース制限
    resources:
      limits:
        cpu: 2000m
        memory: 8Gi
      requests:
        cpu: 1000m
        memory: 4Gi
    
    # 長期保存の設定
    retention: 2d  # ローカル保存は短期間
    retentionSize: 10GiB

Thanosによる長期保存

# Thanos オブジェクトストレージ設定
apiVersion: v1
kind: Secret
metadata:
  name: thanos-objstore-secret
  namespace: monitoring
stringData:
  thanos.yaml: |
    type: s3
    config:
      bucket: thanos-metrics-bucket
      endpoint: s3.amazonaws.com
      region: us-west-2
      access_key: YOUR_ACCESS_KEY
      secret_key: YOUR_SECRET_KEY

メトリクス収集の最適化

収集間隔とリソース使用量のバランス：

# 高頻度監視が必要なワークロード
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: critical-service-monitor
spec:
  endpoints:
  - interval: 15s  # 高頻度
    scrapeTimeout: 10s
  
# 通常のワークロード  
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: normal-service-monitor
spec:
  endpoints:
  - interval: 60s  # 標準
    scrapeTimeout: 30s

# バッチジョブなど
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: batch-job-monitor
spec:
  endpoints:
  - interval: 300s  # 低頻度
    scrapeTimeout: 60s

Grafana パフォーマンス最適化

grafana:
  grafana.ini:
    database:
      type: postgres
      host: postgres.monitoring.svc.cluster.local:5432
      name: grafana
      user: grafana
      password: your-password
    
    # キャッシュ設定
    cache:
      enable: true
    
    # 同時接続数制限
    server:
      router_logging: true
    
    # アラート設定最適化
    alerting:
      execute_alerts: true
      concurrent_render_count: 5

トラブルシューティングとベストプラクティス

よくある問題と解決方法

1. メトリクスが収集されない

# ターゲットの確認
kubectl port-forward -n monitoring svc/prometheus-stack-kube-prom-prometheus 9090:9090
# http://localhost:9090/targets でターゲット状況を確認

# ServiceMonitorの設定確認
kubectl get servicemonitor -n monitoring
kubectl describe servicemonitor your-monitor-name -n monitoring

2. Grafanaダッシュボードにデータが表示されない

# データソース接続の確認
# Grafana → Configuration → Data Sources → Prometheus
# Test接続でエラーをチェック

# PromQLクエリのテスト
# Prometheus UI（http://localhost:9090）でクエリを直接実行

3. アラートが発火しない

# PrometheusRuleの確認
kubectl get prometheusrule -n monitoring
kubectl describe prometheusrule your-rule-name -n monitoring

# Alertmanager設定の確認
kubectl get secret alertmanager-prometheus-stack-kube-prom-alertmanager -n monitoring -o yaml
じゅんち８

監視システム自体の監視も忘れずに！Prometheusのディスク使用量やGrafanaのレスポンス時間もアラート設定に含めています。監視システムがダウンすると、何も分からなくなりますからね。

運用のベストプラクティス

1. 段階的ロールアウト

  • 開発環境で十分テストしてから本番適用
  • カナリアデプロイでアラート設定を検証

2. ラベリング戦略

  • 一貫したラベル命名規則の制定
  • 環境（dev/staging/prod）、チーム、サービス別の分類

3. 容量プランニング

  • メトリクス保存期間と必要ストレージの計算
  • ネットワーク帯域とスクレイプ間隔の最適化

4. セキュリティ対策

  • RBAC（Role-Based Access Control）の適切な設定
  • 機密性の高いメトリクスのアクセス制御
  • TLS通信の有効化

2025年のトレンドと今後の展望

eBPFベースの監視ツール

従来のメトリクス収集に加え、eBPF（extended Berkeley Packet Filter）を使った低オーバーヘッド監視が注目されています：

  • Pixie: リアルタイムオブザーバビリティプラットフォーム
  • Cilium Hubble: ネットワーク層の可視化
  • Parca: 継続的プロファイリング

AIによる異常検知

機械学習を活用した異常検知機能の進化：

  • Grafana ML: パターン認識による異常検知
  • Prometheus AutoML: 自動しきい値設定
  • AIOps統合: インシデント予測と自動対応

サステナビリティ監視

環境負荷の可視化も重要な要素に：

  • Carbon footprint tracking: エネルギー消費量の監視
  • Green metrics: 効率性指標の導入
  • Resource optimization: 無駄なリソース使用の特定

まとめ

Prometheus + Grafanaを使ったKubernetes監視環境の構築は、現代のクラウドネイティブアプリケーション運用に欠かせない要素です。本記事で解説した内容を実践することで：

  • 可視性の向上: システム全体の状況を一目で把握
  • 迅速な障害対応: アラートによる早期発見と通知
  • パフォーマンス最適化: ボトルネックの特定と改善
  • 予防的運用: 問題発生前の対策実施

特に2025年現在では、メトリクスだけでなく、ログとトレースを統合したThree Pillars of Observabilityの実践が重要です。OpenTelemetryを活用した統合監視により、複雑なマイクロサービス環境でも確実に問題を特定できます。

kube-prometheus-stackを使用することで、複雑な設定を簡略化しつつ、エンタープライズレベルの監視環境を短期間で構築できます。ServiceMonitorとPodMonitorを適切に設定し、実用的なアラートを配置することで、安心してサービスを運用できる基盤が完成します。

継続的な改善とスケーリングを意識しながら、あなたの環境に最適化された監視システムを構築してください。適切な監視は、安定したサービス提供の基盤となる重要な投資です。

関連記事

タイトルとURLをコピーしました