Observabilité et Alertes

Vue d'ensemble

Chaque cluster Kubernetes SdV est livré avec une stack de monitoring et d'alerting complète, opérationnelle dès la mise en service. Cette infrastructure repose sur des outils standards de l'écosystème Cloud Native et permet une supervision continue de la santé du cluster et de vos applications.

Architecture de la stack de monitoring

La solution de monitoring déployée sur les clusters SdV intègre les composants suivants :

Points d'accès

Métriques disponibles

La stack de monitoring vous offre une visibilité complète sur :

• Consommation CPU, mémoire, disque, réseau par nœud
• Charge système et disponibilité des nœuds (masters et workers)
• Métriques matérielles détaillées (températures, erreurs hardware si supporté)

• État et santé des Pods, Deployments, StatefulSets, DaemonSets
• Utilisation des ressources (requests/limits vs consommation réelle)
• Événements Kubernetes (crashs, evictions, scheduling failures)
• Quotas et limites par Namespace

• Exposition de métriques custom au format Prometheus via /metrics
• Scraping automatique avec ServiceMonitor (voir section Monitoring applicatif)
• Métriques HTTP (latence, codes de réponse, throughput) si instrumentées

Grafana

Grafana est la plateforme de visualisation utilisée pour explorer les métriques collectées par Prometheus. Elle propose une interface web intuitive permettant de créer, consulter et partager des tableaux de bord personnalisés.

Accès à Grafana

Dashboards préconfigurés

Les clusters SdV sont livrés avec un ensemble de dashboards couvrant les principaux aspects de supervision :

Configuration des dashboards

Les configurations des dashboards Grafana sont stockées sous forme de ConfigMaps dans le Namespace kube-system. Cela permet un déploiement déclaratif et versionné.

Lister les ConfigMaps de dashboards

kubectl -n kube-system get configmaps | grep grafana-dashboard

Consulter un dashboard spécifique

kubectl -n kube-system get cm sdv-monitoring-kube-promet-k8s-resources-cluster -o yaml

Exemple de contenu :

apiVersion: v1
kind: ConfigMap
metadata:
  name: sdv-monitoring-kube-promet-k8s-resources-cluster
  namespace: kube-system
  labels:
    grafana_dashboard: "1"
data:
  k8s-resources-cluster.json: |
    {
      "dashboard": {
        "title": "Kubernetes / Compute Resources / Cluster",
        "panels": [
          ...
        ]
      }
    }

Bonnes pratiques Grafana

✅ Recommandations :

• Utilisez les dashboards fournis comme point de départ avant de demander des personnalisations
• Créez des vues personnalisées via les filtres de variables (namespace, pod, etc.)
• Exploitez les timeranges dynamiques pour analyser des périodes spécifiques
• Partagez des liens directs vers des graphiques spécifiques pour faciliter la communication avec les équipes

❌ À éviter :

• Créer des dashboards manuellement (non persistants)
• Multiplier les requêtes lourdes sur de longues périodes (impact performance Prometheus)
• Ignorer les dashboards existants et recréer des vues redondantes

Prometheus

Prometheus est le cœur du système de monitoring. C'est une base de données de séries temporelles (time series database) qui collecte et stocke les métriques du cluster et de vos applications.

Accès à Prometheus

Fonctionnalités principales

1. Exploration de métriques (PromQL)

L'interface Prometheus permet d'exécuter des requêtes PromQL (Prometheus Query Language) pour explorer les métriques en temps réel.

Exemples de requêtes utiles :

# Utilisation CPU par pod
sum(rate(container_cpu_usage_seconds_total[5m])) by (pod, namespace)

# Mémoire utilisée par namespace
sum(container_memory_usage_bytes{image!=""}) by (namespace)

# Nombre de pods en état non-running
count(kube_pod_status_phase{phase!="Running"}) by (namespace)

# Requêtes HTTP par seconde sur un Ingress
sum(rate(haproxy_frontend_http_requests_total[5m])) by (frontend)

# Latence p95 d'une application
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

2. Visualisation des targets

La page Status > Targets (/targets) affiche tous les endpoints scrapés par Prometheus, leur état de santé et la dernière collecte réussie.

Cela permet de vérifier :

• Que vos ServiceMonitors sont correctement détectés
• Que les endpoints de métriques répondent correctement
• Les éventuelles erreurs de scraping

3. Règles d'alerte

Prometheus permet de définir des règles d'alerte qui évaluent en continu des conditions PromQL. Lorsqu'une condition est remplie, une alerte est déclenchée et transmise à Alertmanager.

Consulter les règles actives

Rendez-vous à l'adresse suivante pour voir toutes les règles configurées :

http://prometheus.internal.<nom_du_cluster>.sdv.fr/rules

Cette page affiche :

• Recording rules : règles qui pré-calculent des métriques coûteuses
• Alerting rules : règles qui déclenchent des alertes

Stockage des règles

Les règles Prometheus sont stockées dans des ConfigMaps dans le Namespace kube-system :

kubectl -n kube-system get configmaps | grep prometheus-rulefiles

Exemple de consultation :

kubectl -n kube-system get cm prometheus-sdv-monitoring-kube-promet-prometheus-rulefiles-0 -o yaml

Extrait d'une règle typique :

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-sdv-monitoring-kube-promet-prometheus-rulefiles-0
  namespace: kube-system
data:
  rules.yaml: |
    groups:
    - name: kubernetes-resources
      interval: 30s
      rules:
      - alert: KubePodCrashLooping
        annotations:
          description: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"
          summary: "Pod is crash looping"
        expr: |
          rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 15m
        labels:
          severity: warning
      
      - alert: KubeNodeNotReady
        annotations:
          description: "Node {{ $labels.node }} is not ready"
          summary: "Node is not ready"
        expr: |
          kube_node_status_condition{condition="Ready",status="true"} == 0
        for: 5m
        labels:
          severity: critical

Consulter les alertes actives

La page Alerts affiche toutes les alertes en cours, leur état (pending, firing), et les labels associés :

http://prometheus.internal.<nom_du_cluster>.sdv.fr/alerts

Alertmanager

Alertmanager gère la distribution des alertes générées par Prometheus. Il assure le routage intelligent, le groupement, la déduplication, le silencing et l'envoi vers les différents canaux de notification (email, Slack, webhooks, PagerDuty, etc.).

Accès à Alertmanager

Fonctionnalités principales

1. Vue des alertes actives

L'interface Alertmanager affiche toutes les alertes en cours de traitement, avec leurs labels, annotations, et état de groupement.

Vous pouvez :

• Filtrer les alertes par labels (namespace, severity, etc.)
• Voir l'historique de déclenchement
• Appliquer des silences temporaires pour suspendre les notifications

2. Silencing (mise en silence)

Le silencing permet de suspendre temporairement les notifications pour une alerte spécifique ou un groupe d'alertes.

Cas d'usage :

• Maintenance planifiée d'un service
• Investigation en cours d'un incident connu
• Désactivation temporaire d'une alerte bruyante

3. Routage intelligent

Alertmanager route les alertes vers différents destinataires selon des règles configurables (severity, namespace, labels custom, etc.).

Par exemple :

• Alertes severity=critical → email équipe SRE + PagerDuty
• Alertes severity=warning + namespace=dev → blackhole (ignorées)
• Alertes severity=warning + namespace=production → email équipe produit

Architecture de la configuration

La configuration d'Alertmanager est stockée dans un Secret Kubernetes :

Namespace: kube-system
Secret: alertmanager-sdv-monitoring-kube-promet-alertmanager
Clé: alertmanager.yaml

Visualiser la configuration actuelle

kubectl get secret -n kube-system alertmanager-sdv-monitoring-kube-promet-alertmanager \
  -o go-template='{{index .data "alertmanager.yaml"}}' | base64 -d

Exemple de configuration type :

global:
  resolve_timeout: 5m
  smtp_from: alerting@sdv.fr
  smtp_require_tls: false
  smtp_smarthost: relix.sdv.fr:25
 
# Règles d'inhibition : évite les alertes redondantes
inhibit_rules:
- equal:
  - alertname
  - namespace
  source_matchers:
  - severity="critical"
  target_matchers:
  - severity="warning"
 
# Définition des destinataires
receivers:
- name: "null"  # Blackhole : ignore les alertes
 
- name: email-admins-sdv
  email_configs:
  - to: admins@sdv.fr
    headers:
      Subject: "[{{ .GroupLabels.severity | toUpper }}] {{ .GroupLabels.alertname }}"
 
- name: watchdog
  webhook_configs:
  - url: "https://alertmanagerwatchdog.sdv.fr/watchdog.php"
    send_resolved: true
 
# Configuration du routage
route:
  group_by:
  - alertname
  - namespace
  group_wait: 30s       # Attente avant le premier envoi (groupement)
  group_interval: 5m    # Intervalle entre envois d'alertes groupées
  repeat_interval: 3h   # Délai avant renvoi d'une même alerte
  receiver: email-admins-sdv  # Destinataire par défaut
  
  routes:
  # Ignore les alertes InfoInhibitor
  - matchers:
    - alertname = InfoInhibitor
    receiver: "null"
    continue: false
  
  # Watchdog vers webhook dédié
  - matchers:
    - alertname = Watchdog
    receiver: watchdog
    continue: false
  
  # Toutes les alertes warning/critical vont aux admins
  - matchers:
    - severity =~ critical|warning
    receiver: email-admins-sdv
    continue: true
 
templates:
- /etc/alertmanager/config/*.tmpl

Structure de la configuration

La configuration Alertmanager se compose de quatre sections principales :

1. Section global

Paramètres globaux appliqués à tous les receivers.

global:
  resolve_timeout: 5m              # Délai avant de considérer une alerte comme résolue
  smtp_from: alerting@sdv.fr       # Adresse email expéditeur
  smtp_smarthost: relix.sdv.fr:25  # Serveur SMTP
  smtp_require_tls: false          # TLS non requis (SMTP interne)

2. Section receivers

Définit les destinataires des alertes. Chaque receiver a un nom unique et une configuration spécifique (email, Slack, webhook, etc.).

Exemple : Receiver email

receivers:
- name: team-backend
  email_configs:
  - to: backend@example.com
    from: alerting@sdv.fr
    smarthost: relix.sdv.fr:25
    require_tls: false
    send_resolved: true  # Envoie aussi les résolutions d'alertes
    headers:
      Subject: "[K8S] {{ .GroupLabels.alertname }} - {{ .GroupLabels.namespace }}"

Exemple : Receiver Slack

receivers:
- name: team-frontend-slack
  slack_configs:
  - api_url: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
    channel: "#alerts-prod"
    title: "{{ .GroupLabels.alertname }}"
    text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
    send_resolved: true

Exemple : Receiver webhook

receivers:
- name: custom-webhook
  webhook_configs:
  - url: "https://monitoring.example.com/webhook"
    send_resolved: true
    http_config:
      basic_auth:
        username: user
        password: pass

Exemple : Receiver blackhole (ignorer des alertes)

receivers:
- name: "null"  # Toutes les alertes routées ici sont ignorées

3. Section route

Définit le routage des alertes vers les receivers. Fonctionne comme un arbre de décision :

route:
  receiver: default            # Receiver par défaut si aucune route ne matche
  group_by: [alertname, namespace]  # Critères de groupement
  group_wait: 30s             # Attente initiale avant envoi (permet groupement)
  group_interval: 5m          # Intervalle entre envois groupés
  repeat_interval: 12h        # Délai avant renvoi d'une alerte identique
  
  routes:
  # Route 1 : Développement → Blackhole
  - matchers:
    - namespace =~ .*-dev
    receiver: "null"
    continue: false  # Stop le routage ici
  
  # Route 2 : Alertes critiques → Email + PagerDuty
  - matchers:
    - severity = critical
    receiver: oncall-pagerduty
    continue: true   # Continue vers les routes suivantes
    
    routes:
    # Sous-route : Critiques production → Email équipe prod
    - matchers:
      - namespace =~ .*-prod
      receiver: team-prod-email
  
  # Route 3 : Warnings production → Email
  - matchers:
    - severity = warning
    - namespace =~ .*-prod
    receiver: team-prod-email

Matchers

Les matchers permettent de filtrer les alertes selon leurs labels :

Paramètres de temporisation

4. Section inhibit_rules

Les règles d'inhibition permettent de supprimer des alertes redondantes lorsqu'une alerte plus sévère est active.

Exemple : Si une alerte critical est active sur un service, toutes les alertes warning concernant ce même service sont inhibées.

inhibit_rules:
- source_matchers:
  - severity = critical
  target_matchers:
  - severity = warning
  equal:
  - alertname
  - namespace

Explication :

• Source : Alerte critique active
• Target : Alertes warning qui seront inhibées
• Equal : Labels devant être identiques entre source et target

Exemples de configurations avancées

Routage par environnement et sévérité

route:
  receiver: default
  group_by: [alertname, namespace, severity]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  
  routes:
  # Ignorer les alertes de dev (tous niveaux)
  - matchers:
    - namespace =~ .*-dev
    receiver: "null"
    continue: false
  
  # Alertes critiques production
  - matchers:
    - severity = critical
    - namespace =~ .*-prod
    receiver: oncall-critical
    repeat_interval: 1h  # Renvoi toutes les heures si non résolu
    continue: true
    
    routes:
    # Spécialisations par namespace
    - matchers:
      - namespace = payment-prod
      receiver: team-payment-critical
    
    - matchers:
      - namespace = api-prod
      receiver: team-api-critical
  
  # Alertes warning production
  - matchers:
    - severity = warning
    - namespace =~ .*-prod
    receiver: team-prod-warnings
    repeat_interval: 24h
  
  # Alertes staging (severity important uniquement)
  - matchers:
    - namespace =~ .*-stage
    - severity =~ critical|warning
    receiver: team-staging
    repeat_interval: 6h

Routage par type d'alerte

route:
  receiver: default
  routes:
  # Alertes infrastructure → Équipe SRE
  - matchers:
    - alertname =~ Kube.*|Node.*
    receiver: sre-team
  
  # Alertes applicatives → Équipe Dev
  - matchers:
    - alertname =~ App.*|HTTP.*
    receiver: dev-team
  
  # Alertes stockage → Équipe Storage
  - matchers:
    - alertname =~ PVC.*|PV.*|Disk.*
    receiver: storage-team

Modifier la configuration Alertmanager

Procédure de modification

kubectl get secret -n kube-system alertmanager-sdv-monitoring-kube-promet-alertmanager \
  -o go-template='{{index .data "alertmanager.yaml"}}' | base64 -d > alertmanager.yaml

# Validation syntaxe YAML
yamllint alertmanager.yaml
 
# Validation configuration Alertmanager (si amtool est installé)
amtool check-config alertmanager.yaml

kubectl create secret generic alertmanager-sdv-monitoring-kube-promet-alertmanager \
  --from-file=alertmanager.yaml \
  --namespace kube-system \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl -n kube-system logs -l app.kubernetes.io/name=alertmanager -f

level=info ts=2026-02-19T10:15:32.123Z caller=coordinator.go:119 component=configuration msg="Loading configuration file" file=/etc/alertmanager/config/alertmanager.yaml
level=info ts=2026-02-19T10:15:32.124Z caller=coordinator.go:131 component=configuration msg="Completed loading of configuration file" file=/etc/alertmanager/config/alertmanager.yaml

level=error ts=2026-02-19T10:15:32.123Z caller=coordinator.go:125 component=configuration msg="Loading configuration file failed" file=/etc/alertmanager/config/alertmanager.yaml err="yaml: line 12: could not find expected ':'"

http://alertmanager.internal.<nom_du_cluster>.sdv.fr/#/status

Ajouter plusieurs fichiers de configuration

Il est possible d'enrichir la configuration avec des fichiers supplémentaires (templates, configurations externes, etc.) :

kubectl create secret generic alertmanager-sdv-monitoring-kube-promet-alertmanager \
  --from-file=alertmanager.yaml \
  --from-file=templates/email.tmpl \
  --from-file=templates/slack.tmpl \
  --namespace kube-system \
  --dry-run=client -o yaml | kubectl apply -f -

Les templates doivent être référencés dans la section templates de la configuration principale :

templates:
- /etc/alertmanager/config/email.tmpl
- /etc/alertmanager/config/slack.tmpl

Monitoring applicatif

Exposer des métriques custom

Vos applications peuvent exposer leurs propres métriques au format Prometheus pour un monitoring spécifique à votre domaine métier.

Prérequis

1. Instrumenter l'application avec une bibliothèque Prometheus client (disponible pour la plupart des langages : Go, Python, Java, Node.js, etc.)
2. Exposer un endpoint /metrics retournant les métriques au format Prometheus
3. Créer un ServiceMonitor pour configurer le scraping automatique

Exemple d'instrumentation (Go)

package main
 
import (
    "net/http"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)
 
var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )
    
    httpRequestDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "HTTP request duration in seconds",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "endpoint"},
    )
)
 
func init() {
    prometheus.MustRegister(httpRequestsTotal)
    prometheus.MustRegister(httpRequestDuration)
}
 
func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":8080", nil)
}

ServiceMonitor pour scraping automatique

Un ServiceMonitor est une CRD (Custom Resource Definition) du Prometheus Operator qui configure automatiquement le scraping d'un Service.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: mon-application
  namespace: production
  labels:
    app: mon-application
    release: sdv-monitoring  # Label requis pour être détecté par Prometheus
spec:
  selector:
    matchLabels:
      app: mon-application  # Selector du Service à scraper
  endpoints:
  - port: metrics  # Nom du port défini dans le Service
    path: /metrics
    interval: 30s  # Fréquence de scraping
    scrapeTimeout: 10s

Alertes custom

Vous pouvez définir des alertes personnalisées pour vos applications en utilisant la CRD PrometheusRule.

Exemple de PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: mon-application-alerts
  namespace: production
  labels:
    release: sdv-monitoring  # Label requis pour être détecté par Prometheus
spec:
  groups:
  - name: mon-application
    interval: 30s
    rules:
    # Alerte : Trop de requêtes en erreur
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m])) by (namespace, pod)
        /
        sum(rate(http_requests_total[5m])) by (namespace, pod)
        > 0.05
      for: 5m
      labels:
        severity: warning
        component: backend
      annotations:
        summary: "Taux d'erreur élevé sur {{ $labels.namespace }}/{{ $labels.pod }}"
        description: "Le pod {{ $labels.pod }} a un taux d'erreur de {{ $value | humanizePercentage }} sur les 5 dernières minutes."
    
    # Alerte : Latence élevée
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          sum(rate(http_request_duration_seconds_bucket[5m])) by (le, namespace, pod)
        ) > 2
      for: 10m
      labels:
        severity: critical
        component: backend
      annotations:
        summary: "Latence p95 élevée sur {{ $labels.namespace }}/{{ $labels.pod }}"
        description: "La latence p95 est de {{ $value }}s, au-dessus du seuil de 2s."
    
    # Alerte : Pods en crash loop
    - alert: PodCrashLooping
      expr: |
        rate(kube_pod_container_status_restarts_total{namespace="production"}[15m]) > 0
      for: 15m
      labels:
        severity: critical
        component: infrastructure
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} en crash loop"
        description: "Le pod redémarre fréquemment, {{ $value }} restarts sur 15min."

Bonnes pratiques

Général

✅ Recommandations :

• Consultez régulièrement les dashboards Grafana pour anticiper les problèmes
• Configurez des alertes proactives (saturation disque, mémoire, etc.) avant d'atteindre les limites
• Documentez vos seuils d'alerte et ajustez-les au fil du temps (réduction du bruit)
• Utilisez les silences Alertmanager pendant les maintenances planifiées
• Instrumentez vos applications avec des métriques métier (commandes traitées, transactions, etc.)
• Créez des runbooks (procédures de résolution) pour chaque alerte critique

❌ À éviter :

• Ignorer les alertes répétées (alerte fatigue) : ajustez les seuils ou corrigez le problème
• Supprimer des alertes sans analyse : comprendre la cause racine avant de désactiver
• Utiliser uniquement Grafana sans configurer d'alertes (approche réactive vs proactive)
• Exposer les interfaces de monitoring publiquement (risque de sécurité)

Alerting

✅ Recommandations :

• Limitez les alertes aux événements nécessitant une action humaine
• Classifiez la sévérité de manière cohérente :
  • critical : incident impactant les utilisateurs, intervention immédiate requise
  • warning : dégradation partielle, investigation nécessaire mais pas urgente
  • info : informationnel, aucune action requise
• Utilisez le groupement (group_by) pour éviter les tempêtes d'alertes
• Configurez des repeat_interval adaptés (3h-12h pour les warnings, 1h pour les critiques)
• Ajoutez toujours des annotations description et summary explicites dans vos alertes
• Testez le routage avec des alertes fictives avant de déployer en production

❌ À éviter :

• Alertes trop sensibles déclenchant des faux positifs fréquents
• Absence de for dans les alertes (déclenchement instantané sur des pics transitoires)
• Envoyer toutes les alertes au même destinataire sans routage intelligent
• Oublier de configurer send_resolved: true (vous ne saurez pas quand l'incident est résolu)

Métriques applicatives

✅ Recommandations :

• Exposez des métriques alignées sur vos objectifs métier (SLI/SLO)
• Utilisez les types de métriques appropriés :
  • Counter : événements cumulatifs (requêtes HTTP, erreurs, etc.)
  • Gauge : valeurs instantanées (CPU, mémoire, connexions actives, etc.)
  • Histogram : distribution de valeurs (latences, tailles de payload etc.)
  • Summary : similaire à histogram mais avec quantiles précalculés
• Limitez la cardinalité des labels (évitez les labels avec trop de valeurs uniques : user_id, request_id, etc.)
• Préfixez les noms de métriques par le nom de votre application (myapp_http_requests_total)
• Documentez vos métriques custom dans un README applicatif

❌ À éviter :

• Créer des labels à haute cardinalité (explosion de séries temporelles, impact performance Prometheus)
• Exposer des informations sensibles dans les labels ou noms de métriques
• Changer les noms de métriques sans versioning (casse l'historique)
• Ne pas tester l'endpoint /metrics avant le déploiement (risque de scraping en erreur)

Performance et dimensionnement

✅ Recommandations :

• Utilisez des recording rules pour pré-calculer des requêtes PromQL coûteuses
• Limitez la rétention de métriques aux besoins réels (par défaut : 15 jours)
• Archivez les métriques long terme dans un système externe si nécessaire (Thanos, Cortex, etc.)
• Réduisez l'intervalle de scraping pour les métriques peu critiques (interval: 60s au lieu de 30s)

❌ À éviter :

• Requêtes PromQL sur de très longues périodes dans Grafana (impact performance)
• Scraping trop fréquent de métriques peu volatiles (gaspillage de ressources)
• Stocker indéfiniment toutes les métriques (saturation du stockage Prometheus)

Troubleshooting

Prometheus ne scrape pas mes métriques

• Votre application n'apparaît pas dans la page Targets de Prometheus
• Les métriques custom ne sont pas disponibles dans PromQL

1. ServiceMonitor mal configuré
   • Vérifier le label release: sdv-monitoring est présent
   • Vérifier le selector matchLabels correspond au Service
   • Vérifier le nom du port dans endpoints[].port correspond au nom dans le Service
2. Service inexistant ou mal configuré
   • Vérifier que le Service existe : kubectl get svc -n <namespace>
   • Vérifier que le selector du Service matche les labels des Pods
3. Port non accessible
   • Tester manuellement l'endpoint metrics :
     Terminal

     kubectl port-forward -n <namespace> pod/<pod-name> 8080:8080
     curl http://localhost:8080/metrics

4. Namespace non monitoré
   • Vérifier que le Namespace n'est pas exclu de la configuration Prometheus

# Vérifier que le ServiceMonitor est créé
kubectl get servicemonitor -n <namespace>
 
# Vérifier la configuration du ServiceMonitor
kubectl describe servicemonitor <nom> -n <namespace>
 
# Consulter les logs Prometheus
kubectl  -n kube-system logs -l app.kubernetes.io/name=prometheus -f

Alertes non reçues

• Les alertes sont visibles dans Prometheus mais aucune notification n'est reçue

1. Alerte en état pending
   • Le délai for n'est pas encore écoulé
2. Alerte inhibée
   • Une alerte plus sévère est active sur le même service
   • Vérifier les règles d'inhibition dans Alertmanager
3. Routage incorrect
   • L'alerte est routée vers le receiver "null" (blackhole)
   • Vérifier la configuration route dans Alertmanager
4. Problème de configuration du receiver
   • Serveur SMTP inaccessible
   • Webhook endpoint en erreur
   • Token Slack invalide

# Vérifier l'état des alertes dans Prometheus
# http://prometheus.internal.<cluster>.sdv.fr/alerts
 
# Vérifier les alertes actives dans Alertmanager
# http://alertmanager.internal.<cluster>.sdv.fr/
 
# Consulter les logs Alertmanager
kubectl -n kube-system logs -l app.kubernetes.io/name=alertmanager -f
 
# Tester le routage avec amtool (si installé)
amtool alert query  # Liste les alertes actives
amtool config routes test --config.file=alertmanager.yaml \
  <label1>=<value1> <label2>=<value2>  # Teste le routage

Grafana affiche "No data"

• Les dashboards Grafana affichent "No data" alors que des métriques existent

1. Filtre de dashboard trop restrictif
   • Vérifier les variables de filtrage (namespace, pod, etc.)
2. Période de temps incorrecte
   • Ajuster le time range dans Grafana
3. Requête PromQL invalide
   • Tester la requête directement dans Prometheus
4. Prometheus inaccessible depuis Grafana
   • Vérifier la datasource dans Grafana : Configuration > Data Sources > Prometheus

# Tester la requête PromQL directement
# http://prometheus.internal.<cluster>.sdv.fr/graph
 
# Vérifier la connectivité Grafana → Prometheus
kubectl -n kube-system logs -l app.kubernetes.io/name=grafana -f

Saturation du stockage Prometheus

• Prometheus crashloop ou redémarre fréquemment
• Logs indiquant "out of disk space"

1. Trop de séries temporelles collectées
   • Métriques avec labels à haute cardinalité
2. Rétention trop longue
   • Paramètre retention trop élevé

# Vérifier la consommation de stockage
kubectl -n kube-system exec -it prometheus-<pod-name> -- df -h /prometheus
 
# Lister le nombre de séries temporelles
# http://prometheus.internal.<cluster>.sdv.fr/api/v1/status/tsdb
 
# Identifier les métriques volumineuses
# http://prometheus.internal.<cluster>.sdv.fr/api/v1/label/__name__/values
 
# Réduire la rétention (contact SdV requis)
# Ou supprimer des ServiceMonitors inutiles

Ressources complémentaires

Documentation officielle

• Prometheus Documentation
• Prometheus Operator
• Grafana Documentation
• Alertmanager Documentation
• PromQL Basics

Configuration Alertmanager

• Alertmanager Configuration
• Notification Templates

Instrumentation applicative

• Prometheus Client Libraries
• Instrumenting a Go application
• Node.js client (prom-client)
• Java client (Micrometer)

Exemples de métriques et alertes

• Awesome Prometheus alerts
• Kubernetes Monitoring with Prometheus