Grafana et Prometheus
| Propriété | Valeur |
|---|---|
| Namespace | monitoring |
| URL | https://grafana.lab.djayzone.com |
| Authentification | GitHub via OAuth2 Proxy, identité Grafana via X-Forwarded-User |
| Stockage | Grafana éphémère, Prometheus 5 GiB en local-path |
| Rétention | 3 jours / 3 Go pour Prometheus |
| Criticité | Haute pour l'observabilité |
Rôle
Prometheus collecte les métriques Kubernetes, des quatre nœuds et des workloads. Grafana affiche les dashboards provisionnés par ConfigMap, dont Homelab / Cluster & Applications.
Alertmanager reçoit les alertes Prometheus. Seules les règles explicitement étiquetées notify=email sont routées vers alert-relay. Deux livraisons indépendantes sont alors déclenchées : un compte rendu HTML via le Mail Gateway et un événement automatisé [SYSTEM] dans le canal Slack #incidents. Les règles natives du chart restent visibles mais ne déclenchent aucune notification afin d’éviter le bruit.
Prometheus fonctionne temporairement avec un seul réplica dans le mode d'optimisation de capacité PLAT-76. Il réserve 1280 MiB et conserve une limite de 1,5 GiB ; le second PVC Prometheus n'est pas supprimé afin de garder un rollback simple vers l'architecture HA documentée dans l'ADR 0005. Thanos/B2 continue d'assurer la durabilité de l'historique, mais la collecte temps réel redevient un SPOF assumé pendant ce mode.
Grafana fonctionne avec un seul réplica stateless dans ce même mode capacité. Le conteneur Grafana réserve 384 MiB et peut utiliser 768 MiB ; les deux sidecars réservent chacun 64 MiB et sont limités à 128 MiB. Les dashboards restent entièrement reprovisionnables depuis Git, ce qui rend ce compromis moins risqué que de conserver deux pods permanents.
Authentification Grafana
L'Ingress public route exclusivement vers l'instance OAuth2 Proxy du namespace monitoring. Après authentification GitHub, OAuth2 Proxy transmet explicitement l'identité dans X-Forwarded-User. Grafana consomme cet en-tête avec auth.proxy, crée automatiquement l'utilisateur si nécessaire et lui assigne le rôle d'organisation Viewer. L'accès anonyme est désactivé et le formulaire de connexion Grafana reste désactivé.
L'en-tête d'identité ne constitue une preuve que parce que l'accès réseau direct à Grafana est fermé. La NetworkPolicy grafana-ingress autorise TCP/3000 uniquement depuis les pods oauth2-proxy du namespace monitoring et depuis les pods Gatus du namespace status, qui conservent leur contrôle interne /api/health. Traefik n'accède jamais directement au Service Grafana.
Le rôle Viewer est volontairement minimal : l'utilisateur peut consulter les dashboards et exécuter leurs requêtes datasource, sans droits Editor ou Admin. Toute montée de privilège doit faire l'objet d'un changement GitOps distinct.
Politique d'alerting e-mail
| Alerte | Temporisation | Sévérité |
|---|---|---|
| Nœud NotReady | 3 minutes | Critique |
| Déploiement critique incomplet | 5 minutes | Critique |
| Mail Gateway non configuré | 2 minutes | Critique |
| CrashLoopBackOff | 10 minutes | Warning |
| Au moins 4 redémarrages sur 15 minutes | 5 minutes | Warning |
| Mémoire disponible sous 15 % | 10 minutes | Warning |
| Disque racine au-dessus de 85 % | 15 minutes | Warning |
Alertmanager regroupe les événements par alerte, namespace et sévérité, attend une minute avant le premier envoi, puis limite les répétitions à une toutes les quatre heures. Un e-mail de résolution est envoyé lorsque l’incident disparaît. Dans Slack, l’ouverture crée un message racine et la résolution répond dans le même fil. Le fingerprint Alertmanager et les métadonnées Slack assurent la corrélation et l’idempotence ; aucun agent ne publie manuellement dans #incidents.
Les fichiers de référence sont alert-rules.yaml, alert-relay.yaml et alert-relay.py. Le destinataire est stocké hors Git dans le Secret monitoring-alerts. Le bot Slack et son token restent isolés dans le namespace slack-mcp ; la NetworkPolicy n’autorise que alert-relay à joindre le bridge sur TCP/8080.
Exploitation
Thanos Compactor et espace temporaire
Le Compactor dispose de 20Gi de workspace temporaire et limite ses compactions
à des plages de 8 heures (--debug.max-compaction-level=2, Thanos v0.42.4).
La rétention B2 reste de 7 jours. Ce réglage réduit la quantité de données à
télécharger et fusionner simultanément ; les gros blocs existants restent
consultables jusqu'à leur expiration. Voir le README du composant monitoring
pour le compromis, la validation d'une passe complète sans éviction pendant au
moins une heure et le rollback GitOps.
kubectl -n monitoring get pods,pvc -o wide
kubectl -n monitoring logs deployment/monitoring-grafana -c grafana --tail=200
kubectl -n monitoring logs deployment/oauth2-proxy --tail=200
kubectl -n monitoring get networkpolicy grafana-ingress
kubectl -n monitoring get prometheus
kubectl -n monitoring get alertmanager,prometheusrule
kubectl -n monitoring logs deployment/alert-relay --tail=200
kubectl top nodes
kubectl top pods -A --sort-by=memory
Validation après déploiement de l'auth proxy
- En navigation privée, ouvrir
https://grafana.lab.djayzone.comet vérifier qu'une session absente est redirigée vers GitHub au lieu d'obtenir un accès anonyme. - S'authentifier avec l'identité GitHub autorisée puis ouvrir un dashboard provisionné, notamment
homelab-notrecouple. - Vérifier dans les logs Grafana que les requêtes ne sont plus associées à
anonymous:0et qu'aucun403n'apparaît sur la lecture Dashboard API v2 ni surteams:read. - Vérifier qu'un panneau utilisant Prometheus retourne toujours ses données.
- Vérifier que Gatus conserve un
200surhttp://monitoring-grafana.monitoring.svc.cluster.local/api/health.
Critère d'arrêt : si la connexion GitHub boucle, si Grafana refuse encore les dashboards autorisés, si les requêtes Prometheus échouent ou si le healthcheck Gatus devient indisponible, revenir immédiatement au commit précédent par revert Git plutôt que d'affaiblir la NetworkPolicy ou le rôle Grafana.
Rollback de l'auth proxy
Le rollback canonique est le revert de la Pull Request qui active auth.proxy. Flux restaure alors la configuration Grafana précédente et supprime la NetworkPolicy ajoutée par le changement. Ne pas contourner temporairement le problème en exposant le Service Grafana ou en élargissant le rôle à Editor/Admin.
Source de vérité
Le dashboard principal est versionné dans apps/ovh-primary/monitoring/dashboard-application-overview.yaml. Une modification manuelle dans Grafana peut être perdue au prochain provisionnement.
Pannes typiques
- PVC local indisponible après déplacement du pod ;
- requête PromQL sans données ;
- sidecar Grafana ne chargeant pas le ConfigMap ;
- OOM Grafana : une limite de 384 MiB provoquait des arrêts simultanés et des réponses 502 lorsque les deux endpoints sortaient du Service ;
- identité Grafana absente : OAuth2 Proxy accepte la session mais Grafana journalise
anonymous:0et refuse certaines routes avec403; - saturation mémoire de Prometheus.
Panneaux « No data »
Avant de modifier un panneau, vérifier si la métrique existe réellement dans Prometheus. Les tuiles instantanées et les courbes temporelles doivent être testées séparément : une jointure PromQL valable à l'instant présent peut échouer sur une plage historique si les labels d'une série ont changé après une maintenance.
Le dashboard principal évite volontairement de joindre les courbes CPU et mémoire à node_uname_info. Les séries temporelles utilisent le label stable instance; les jauges instantanées conservent le nom lisible du nœud. Cette séparation empêche les erreurs de cardinalité après le redémarrage ou le remplacement d'un node-exporter.
# Présence des métriques des quatre nœuds
$query = [uri]::EscapeDataString('node_memory_MemAvailable_bytes')
kubectl get --raw "/api/v1/namespaces/monitoring/services/http:prometheus-operated:9090/proxy/api/v1/query?query=$query"
# Erreurs de requête visibles côté Grafana
kubectl -n monitoring logs deployment/monitoring-grafana -c grafana --since=30m |
Select-String 'status=403|path=/api/ds/query status=400|anonymous:0'