Monitoring Kubernetes en 2025 : Guide Complet Prometheus et Grafana

Le monitoring Kubernetes est devenu exponentiellement plus complexe en 2025. Les environnements modernes jonglent avec des microservices, des fonctions serverless, des réseaux complexes et souvent plusieurs clusters distribués. Ce guide complet vous présente les outils, stratégies et meilleures pratiques pour observer vos environnements Kubernetes de manière efficace.

L’État du Monitoring Kubernetes en 2025

Les environnements Kubernetes en 2025 sont hautement complexes, gérant des microservices, des fonctions serverless et des couches réseau complexes, souvent à travers plusieurs clusters. Ces environnements sont dynamiques et distribués, avec de nombreuses nouvelles technologies ajoutées en couches.

Défis principaux :

• Échelle massive : Des milliers de pods éphémères
• Dynamisme : Pods qui apparaissent et disparaissent constamment
• Distribution : Multi-cluster, multi-région, multi-cloud
• Complexité : Mesh services, sidecars, opérateurs personnalisés

La solution ? Une approche d’observabilité unifiée où traces, métriques et logs fournissent des insights profonds. S’appuyer sur un seul type de signal n’est souvent pas suffisant pour diagnostiquer les problèmes complexes.

La Stack Standard : Prometheus + Grafana

Pour les meilleurs outils de monitoring Kubernetes 2025, la plupart des équipes standardisent encore sur Prometheus + Grafana pour les métriques de base. Les outils open source comme Prometheus et Grafana sont fondamentaux, et une stratégie efficace consiste souvent à les combiner ou à utiliser une plateforme qui gère l’échelle et réduit la charge de gestion.

Pourquoi Prometheus ?

Architecture et Fonctionnement :

Prometheus utilise un modèle pull (scraping), découvrant et collectant automatiquement les métriques depuis les services Kubernetes. Il s’intègre nativement avec l’API Kubernetes pour la découverte de services.

# Exemple de ServiceMonitor pour découverte automatique
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
  namespace: production
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

Avantages de Prometheus :

Grafana : Visualisation Flexible

Grafana fournit une manière flexible d’explorer et de visualiser les données Prometheus. L’intégration est transparente et permet de créer des dashboards riches et interactifs.

Tableau de bord essentiel pour Kubernetes :

# Dashboard populaire : Kubernetes Cluster Monitoring
# https://grafana.com/grafana/dashboards/315

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-k8s-cluster
  namespace: monitoring
data:
  k8s-cluster.json: |
    {
      "dashboard": {
        "title": "Kubernetes Cluster Monitoring",
        "panels": [
          {
            "title": "Cluster CPU Usage",
            "targets": [{
              "expr": "sum(rate(containercpuusagesecondstotal[5m]))"
            }]
          },
          {
            "title": "Cluster Memory Usage",
            "targets": [{
              "expr": "sum(containermemoryworkingsetbytes)"
            }]
          }
        ]
      }
    }

Dashboards recommandés (Grafana Labs) :

Kube Prometheus Stack : Solution Tout-en-Un

Le Kube Prometheus Stack simplifie l’observabilité en combinant Prometheus, Grafana et Alertmanager dans une solution de monitoring évolutive.

Installation avec Helm :

# Ajouter le repo Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Installer la stack complète
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack 
  --namespace monitoring 
  --create-namespace 
  --set prometheus.prometheusSpec.retention=30d 
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi 
  --set grafana.adminPassword=changeme

Composants inclus :

Métriques Clés à Surveiller

Surveillez les métriques au niveau cluster, nœud, pod et application, en portant une attention particulière à :

Niveau Cluster

# Latence de l'API Server
histogramquantile(0.99,
  sum(rate(apiserverrequestdurationsecondsbucket[5m])) by (le, verb)
)

# Taux d'erreur API Server
sum(rate(apiserverrequesttotal{code=~"5.."}[5m]))
/
sum(rate(apiserverrequesttotal[5m]))

# Pods en état non-running
count(kubepodstatusphase{phase!="Running"})

Niveau Nœud

# CPU utilisé vs disponible
100  (1 - avg(rate(nodecpusecondstotal{mode="idle"}[5m])))

# Mémoire disponible
nodememoryMemAvailablebytes / nodememoryMemTotalbytes  100

# Disk I/O saturation
rate(nodediskiotimesecondstotal[5m])

Niveau Pod

# Taux de restart des conteneurs
rate(kubepodcontainerstatusrestartstotal[15m])

# Pods en CrashLoopBackOff
count(kubepodcontainerstatuswaitingreason{reason="CrashLoopBackOff"})

# Utilisation CPU vs limits
sum(rate(containercpuusagesecondstotal[5m])) by (pod)
/
sum(kubepodcontainerresourcelimits{resource="cpu"}) by (pod)

# Utilisation mémoire vs requests
sum(containermemoryworkingsetbytes) by (pod)
/
sum(kubepodcontainerresourcerequests{resource="memory"}) by (pod)

Niveau Application

# Latence des requêtes HTTP (p95)
histogramquantile(0.95,
  sum(rate(httprequestdurationsecondsbucket[5m])) by (le, service)
)

# Taux d'erreur HTTP
sum(rate(httprequeststotal{status=~"5.."}[5m])) by (service)
/
sum(rate(httprequeststotal[5m])) by (service)

# Throughput
sum(rate(httprequeststotal[5m])) by (service)

OpenTelemetry : La Nouvelle Standard

Le consensus en 2025 est clair : même si vous aimez PromQL et Grafana, exécutez un collecteur OpenTelemetry (OTel) en amont. Les équipes apprécient OTel car les collecteurs peuvent pousser simultanément vers des stores open-source (Thanos, Loki, Tempo) et des APMs commerciaux (Datadog, New Relic).

Architecture avec OpenTelemetry

┌─────────────┐
│Application  │
│  (OTel SDK) │
└──────┬──────┘
       │ OTLP
       ▼
┌─────────────────┐
│OTel Collector   │
│  (Daemonset)    │
└────┬────┬───┬───┘
     │    │   │
     ▼    ▼   ▼
  Tempo Loki Prometheus
  (Traces)(Logs)(Metrics)

Installation du Collecteur OTel :

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
  namespace: monitoring
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
      prometheus:
        config:
          scrapeconfigs:
            - jobname: 'kubernetes-pods'
              kubernetessdconfigs:
                - role: pod

    processors:
      batch:
        timeout: 10s
        sendbatchsize: 1024
      memorylimiter:
        limitmib: 512
        spikelimitmib: 128

    exporters:
      prometheus:
        endpoint: "0.0.0.0:8889"
      otlp/tempo:
        endpoint: "tempo:4317"
        tls:
          insecure: true
      loki:
        endpoint: "http://loki:3100/loki/api/v1/push"

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch, memorylimiter]
          exporters: [otlp/tempo]
        metrics:
          receivers: [otlp, prometheus]
          processors: [batch]
          exporters: [prometheus]
        logs:
          receivers: [otlp]
          processors: [batch]
          exporters: [loki]
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: otel-collector
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: otel-collector
  template:
    metadata:
      labels:
        app: otel-collector
    spec:
      containers:
      - name: otel-collector
        image: otel/opentelemetry-collector-contrib:0.91.0
        ports:
        - containerPort: 4317  # OTLP gRPC
        - containerPort: 4318  # OTLP HTTP
        - containerPort: 8889  # Prometheus metrics
        volumeMounts:
        - name: config
          mountPath: /etc/otel
        env:
        - name: OTELCONFIG
          value: /etc/otel/config.yaml
      volumes:
      - name: config
        configMap:
          name: otel-collector-config

Avantages d’OpenTelemetry :

eBPF : La Révolution de l’Observabilité

eBPF est passé discrètement de filtre de paquets de niche à superpuissance de l’observabilité, avec des outils comme Pixie, Cilium Hubble et Groundcover attachant des sondes aux appels système et points de trace du noyau.

Cilium Hubble pour l’Observabilité Réseau

Installation de Cilium avec Hubble :

# Installer Cilium avec Hubble activé
cilium install --version 1.14.5
cilium hubble enable --ui

# Vérifier le statut
cilium status
cilium hubble port-forward &

Observer les flux réseau :

# Flux en temps réel
hubble observe

# Flux filtrés par namespace
hubble observe --namespace production

# Flux avec latence
hubble observe --verdict DROPPED

# Top des connexions
hubble observe --last 1000 -o jsonpb | 
  jq '.flow | "(.source.namespace)/(.source.podname) -> (.destination.namespace)/(.destination.podname)"' | 
  sort | uniq -c | sort -nr | head -10

Avantages d’eBPF :

Pixie pour l’Auto-Instrumentation

Pixie fournit une observabilité instantanée sans modification du code.

# Installation de Pixie
kubectl apply -f https://work.withpixie.ai/manifest.yaml

# Accès à l'UI
px deploy
px live

Capacités de Pixie :

Stockage à Long Terme : Thanos et Cortex

Prometheus seul a des limitations pour le stockage à long terme et la haute disponibilité. Thanos et Cortex résolvent ces problèmes.

Thanos : HA et Stockage Illimité

# Sidecar Thanos pour Prometheus
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: prometheus
spec:
  template:
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.48.0
        # ... config prometheus ...

      - name: thanos-sidecar
        image: thanosio/thanos:v0.32.5
        args:
        - sidecar
        - --prometheus.url=http://localhost:9090
        - --tsdb.path=/prometheus
        - --objstore.config-file=/etc/thanos/objstore.yml
        volumeMounts:
        - name: prometheus-storage
          mountPath: /prometheus
        - name: thanos-objstore-config
          mountPath: /etc/thanos
---
# Configuration du stockage objet (S3)
apiVersion: v1
kind: Secret
metadata:
  name: thanos-objstore-config
stringData:
  objstore.yml: |
    type: S3
    config:
      bucket: "prometheus-metrics"
      endpoint: "s3.amazonaws.com"
      accesskey: "${AWSACCESSKEYID}"
      secretkey: "${AWSSECRETACCESSKEY}"

Composants Thanos :

Avantages :

Solutions Commerciales vs Open Source

Les solutions commerciales incluent Datadog, Dynatrace, New Relic, AppDynamics, Splunk et Instana. Bien qu’elles fournissent des intégrations automatisées et de l’évolutivité, leurs coûts élevés et leur lock-in propriétaire les rendent moins idéales pour les équipes flexibles ou soucieuses du budget.

Comparaison : Open Source vs Commercial

Stack Open Source Recommandée

Pour PME/Startups :

Prometheus + Grafana + Alertmanager
↓
Évolution vers : + Loki (logs) + Tempo (traces)

Pour Entreprises :

Prometheus + Thanos (HA + stockage long terme)
+ Grafana (visualisation)
+ Loki (logs)
+ Tempo (traces)
+ OpenTelemetry Collector (unification)
+ Cilium Hubble (réseau eBPF)

Alerting Intelligent

Alertmanager : Configuration Avancée

apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-config
data:
  alertmanager.yml: |
    global:
      slackapiurl: 'https://hooks.slack.com/services/XXX'

    route:
      receiver: 'default'
      groupby: ['alertname', 'cluster', 'service']
      groupwait: 10s
      groupinterval: 10s
      repeatinterval: 12h
      routes:
      - match:
          severity: critical
        receiver: 'pagerduty'
        continue: true
      - match:
          severity: warning
        receiver: 'slack-warnings'

    receivers:
    - name: 'default'
      slackconfigs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

    - name: 'pagerduty'
      pagerdutyconfigs:
      - servicekey: 'YOURPAGERDUTYKEY'

    - name: 'slack-warnings'
      slackconfigs:
      - channel: '#alerts-warnings'
        sendresolved: true

Règles d’Alerte Essentielles

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-alerts
spec:
  groups:
  - name: kubernetes.rules
    interval: 30s
    rules:

    # Pod CrashLooping
    - alert: PodCrashLooping
      expr: rate(kubepodcontainerstatusrestartstotal[15m]) > 0
      for: 5m
      labels:
        severity: critical
      annotations:
        description: 'Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping'

    # Node NotReady
    - alert: NodeNotReady
      expr: kubenodestatuscondition{condition="Ready",status="true"} == 0
      for: 5m
      labels:
        severity: critical
      annotations:
        description: 'Node {{ $labels.node }} is not ready'

    # High Memory Usage
    - alert: HighMemoryUsage
      expr: |
        (sum(containermemoryworkingsetbytes{container!=""}) by (namespace, pod)
        /
        sum(kubepodcontainerresourcelimits{resource="memory"}) by (namespace, pod))
        > 0.9
      for: 5m
      labels:
        severity: warning
      annotations:
        description: 'Pod {{ $labels.namespace }}/{{ $labels.pod }} using > 90% memory'

    # API Server Latency
    - alert: APIServerHighLatency
      expr: |
        histogramquantile(0.99,
          sum(rate(apiserverrequestdurationsecondsbucket[5m])) by (le, verb)
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        description: 'API Server p99 latency is {{ $value }}s for {{ $labels.verb }}'

    # Disk Space Running Out
    - alert: DiskSpaceRunningOut
      expr: |
        predictlinear(nodefilesystemfreebytes{fstype!~"tmpfs"}[6h], 243600) < 0
      for: 1h
      labels:
        severity: warning
      annotations:
        description: 'Disk {{ $labels.device }} on {{ $labels.node }} will run out in 24h'

Grafana Cloud pour Kubernetes

Grafana Cloud simplifie le monitoring en offrant Prometheus, Loki et Tempo managés avec intégration Kubernetes native.

Installation de l'agent Grafana :

# Helm chart
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install grafana-agent grafana/grafana-agent 
  --namespace monitoring 
  --set-string grafana.apiKey=$GRAFANAAPIKEY 
  --set-string grafana.url=$GRAFANAURL

Avantages :

Best Practices 2025

1. Monitoring Multi-Couches

Implémentez une stratégie d'observabilité à quatre niveaux :

┌─────────────────────────────────┐
│  Application (Traces, Metrics)  │ ← OpenTelemetry SDK
├─────────────────────────────────┤
│  Platform (Kubernetes Metrics)  │ ← Kube State Metrics
├─────────────────────────────────┤
│  Infrastructure (Nodes, Network)│ ← Node Exporter, Cilium
├─────────────────────────────────┤
│  Business (KPIs, SLOs)          │ ← Custom Metrics
└─────────────────────────────────┘

2. Adopter les SLOs (Service Level Objectives)

Définissez et surveillez des SLOs basés sur l'expérience utilisateur.

# Exemple de SLO : 99.9% de requêtes < 500ms
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: slo-latency
spec:
  groups:
  - name: slo.rules
    rules:
    - record: slo:latency:ratio
      expr: |
        sum(rate(httprequestdurationsecondsbucket{le="0.5"}[5m]))
        /
        sum(rate(httprequestdurationsecondscount[5m]))

    - alert: SLOLatencyBreach
      expr: slo:latency:ratio < 0.999
      for: 5m
      labels:
        severity: critical
      annotations:
        description: 'Latency SLO breach: {{ $value | humanizePercentage }}'

3. Corrélation Traces-Metrics-Logs

Utilisez des identifiants de corrélation (trace ID) pour lier les trois signaux.

// Exemple avec OpenTelemetry
const { trace } = require('@opentelemetry/api');
const logger = require('./logger');

function handleRequest(req, res) {
  const span = trace.getActiveSpan();
  const traceId = span.spanContext().traceId;

  // Log avec trace ID
  logger.info('Processing request', {
    traceId: traceId,
    userId: req.user.id
  });

  // Métrique avec label
  requestCounter.add(1, {
    endpoint: req.path,
    traceId: traceId
  });
}

4. Automatiser avec GitOps

Gérez vos configurations de monitoring comme du code.

# ArgoCD Application pour monitoring stack
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: monitoring-stack
spec:
  project: default
  source:
    repoURL: https://github.com/monentreprise/k8s-monitoring
    targetRevision: HEAD
    path: monitoring
    helm:
      values: |
        prometheus:
          retention: 30d
        grafana:
          dashboards:
            enabled: true
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

5. Optimiser les Coûts

Stratégies pour réduire les coûts de monitoring :

# Configuration Thanos pour downsampling
apiVersion: apps/v1
kind: Deployment
metadata:
  name: thanos-compactor
spec:
  template:
    spec:
      containers:
      - name: thanos-compactor
        args:
        - compact
        - --retention.resolution-raw=30d
        - --retention.resolution-5m=90d
        - --retention.resolution-1h=365d

Tendances 2025 et Au-Delà

AI-Powered Observability

L'IA révolutionne le monitoring avec :

eBPF Généralisé

eBPF devient la norme pour :

Unified Observability Platforms

Convergence vers des plateformes unifiées offrant traces, métriques, logs et profiling dans une seule interface cohérente.

Leaders du marché :

Checklist de Déploiement

Avant de déployer votre stack de monitoring :

Métriques :

Visualisation :

Alerting :

Observabilité Avancée :

Sécurité :

Conclusion

Le paysage du monitoring Kubernetes a considérablement maturé en 2025. Avec des couches de stockage haute disponibilité (Thanos), des traceurs alimentés par eBPF (Pixie, Hubble) et OpenTelemetry se façonnant en lingua franca pour tous les signaux, nous disposons aujourd'hui d'outils puissants pour une observabilité totale.

Points clés à retenir :

La clé du succès en 2025 est d'adopter une approche pragmatique : commencez simple (Prometheus + Grafana), puis évoluez vers une stack unifiée (+ OpenTelemetry + Loki + Tempo) au fur et à mesure que vos besoins croissent.

Sources et Références

Article mis à jour en décembre 2025 avec les dernières tendances et outils de l'écosystème Kubernetes.*