Dashboards de l'infrastructure

1) Pourquoi est-ce nécessaire

Une seule image de l'état : du cluster et des réseaux aux bases de données et files d'attente.
RCA rapide et post mortem : un ensemble de métriques ↔ de logs ↔ de pistes.
SLO par service et plateforme : contrôle de l'accessibilité et de la latence.
FinOps-transparence : volume/coût par service, tenant'am et mercredi.
Conformité/sécurité : état des patchs/vulnérabilités, accès, anomalies.

Méthodologies : Signaux d'or (latitude, trafic, erreurs, saturation), RED (taux, erreurs, durée) pour les demandes, USE (utilité, saturation, erreurs) pour les ressources.

2) Les principes d'un bon dashboard

Validité (Activable) : chaque panneau répond à « quoi faire ensuite ».
Hiérarchie : Vue d'ensemble des domaines → → deep dive → raw.
Modèles/variables : 'cluster', 'namespace', 'service', 'tenant', 'bou'.
Unités uniques : ms pour latence, %, RPS, opérations/s, octets.
Horloge de consistance : par défaut 1-6 heures, presets rapides 5m/15m/24h.
Drilldown : du panneau sur la loge (Loki/ELK) et la piste (Tempo/Jaeger).
Propriété : sur le dashboard indiqué propriétaire, SLO, runbook, contact en ligne.

3) Structure des dossiers et des rôles

00_Overview est un aperçu de haut niveau de la plate-forme.
10_Kubernetes - clusters, noeuds, workloads, NRA/VPA, conteneurs.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30_Storage_DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, stockage d'objets.
40_CICD_Runner - piplines, agents, artefacts, registry.
50_Security_Compliance - vulnérabilités, patchs, RBAC, événements d'audit.
60_FinOps_Cost - coût par service/tenant/cluster, recyclage.
99_Runbooks - liens vers les instructions et les cartes SLO.

Rôles : Plateforme-SRE (accès complet), Service-Owner (ses espaces), Sécurité/Conformité, Finances/FinOps, View-only.

4) Vue d'ensemble de la plate-forme (Landing)

L'objectif est de savoir si tout va bien en ≤30 secondes.

• Plate-forme SLO (disponibilité de l'API edge) : valeur cible, réelle, ère d'erreur, burn-rate.
• Latence p50/p95/p99 par les points d'entrée principaux.
• Erreurs 4xx/5xx et top endpoints avec régression.
• La saturation des ressources (CPU, RAM, réseau, disque) est p95 par cluster.
• Incidents/alertes (actifs) et versions récentes.
• Coût/heure (approximativement) et tendance par semaine.

Les clichés des variables : ' env ', ' region ', ' cluster ', ' tenant '.

5) Kubernetes : clusters et workloades

1. Cluster/Nodes

Recyclage CPU/Mémoire, pression (mémoire/cpu), disque IO, inode.
Sous-systèmes : kube-api, etcd, contrôleurs ; kubelet health.

2. Workloades

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
Targets HPA vs métriques réelles.

3. Chemin réseau dans le cluster

eBPF/Netflow: top talkers, drops, retransmits.

4. Événements K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

Latency p95 histogram_quantile (0. 95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Edge, grille et DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast : répartition du trafic par zone, événements d'échec.
• DNS : latence résolve, taux NXDOMAIN/SERVFAIL, cacha hit-ratio.
• CDN/WAF : verrous selon les règles, trafic anormal (bots/scrapers).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) Bases de données et storage

PostgreSQL/MySQL : qps, latency, lock waits, replication lag, backups/échecs.
Redis : hit ratio, événements, mémoire, commandes lentes.
Kafka/RabbitMQ : lag par groupes consommateurs, rebalances, messages unacked.
Stockage des objets : requêtes, erreurs, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD et artefacts

Pipeline overview : succès/temps d'exécution, file de runner.
Deployment health : versions, statut canary/bleu-vert, temps de réchauffage.
Enregistrez les images : taille, derniers push 'et, recyclage.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) Sécurité et conformité

Patchs et vulnérabilités : proportion de nodules/images avec CVE critique, moyenne « temps avant le patch ».
RBAC et secrets : tentatives infructueuses d'accès, recours aux secrets.
Audit-événements : entrées/changements dans les composants critiques, drift.
WAF/DLP/PII : verrouillage des règles, erreurs de masquage.

10) Logs et pistes : Vue d'ensemble

Résumé des erreurs des logs (Loki/ELK) : top exceptions, nouvelles signatures.
Bouton Aller aux logs avec filtres (LogQL/ES query).
Pistes : haut slow spans, pourcentage de requêtes sans trace-contexte.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps : coût et élimination

Coût par service/tenants/grappes (selon la facturation/les exportateurs).
Noeuds chauds/froids : idle resources, recommandations de rightsizing (CPU/Mem).
Données egress, L7 demandes et leur coût.
Dynamique : semaine/mois, prévisions.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• facteur d'efficacité : 'RPS/$' ou 'SLO-minutes/$'.

12) SLO, erreurs et burn-rate

Carte SLO sur chaque dashboard du domaine : cible, période, erreurs (budget).
Burn-rate alerts (deux vitesses : rapide/lente).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) Normes de visualisation

Tips des panneaux : time-series pour les rangées, stat pour les KPI, table pour top-N, heatmap pour la latence.
Légendes et unites : obligatoires ; labels raccourcis, format SI.
Zones de couleur : vert/jaune/rouge selon SLO/threshold (uniforme).
Description du panneau : ce que nous mesurons, source, runbook-link, propriétaire.

14) Modèles de panneaux (démarrage rapide)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown dans « trace _ id = $ trace ».

(B) Node Health

CPU/Memory/Disk/Network - p95 par nodule, liste « chaud ».
Pressure, throttling, drops de paquets.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Backap status/dernier succès.

(D) Kafka Lag

Lag par groupe, taux de consommation vs production, rebalances.

(E) Cost & Util

Cost/hour par service, idle %, rightsizing hints, prévisions.

15) Variables et étiquettes (ensemble recommandé)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) Intégration avec alerting et gestion des incidents

Règles dans Alertmanager/Grafana-alerts avec des liens vers le dashboard souhaité et des variables déjà encadrées.
P1/P2 selon les critères SLO, auto-assign sur on-call.
Annotations des versions/incidents sur les graphiques.

17) Qualité des dashboards : Check-list

• Propriétaire et contact.
• SLO/thresholds sont documentés.
• Les variables fonctionnent et limitent le volume des demandes.
• Tous les panneaux avec des unités et une légende.
• Drilldown dans les logis/pistes.
• Les panneaux sont placés dans 2-3 « écran » (pas de scroll au kilomètre).
• Temps de réponse des requêtes ≤2 -3 c (cache, downsample).
• Pas de panneaux « morts » et de métriques deprecated.

18) La performance et le coût des dashboards eux-mêmes

Downsampling/recording rules pour les agrégations lourdes.
Cache (query-frontend/repeater) et limites sur range/step.
Hangar de test : charge sur le TSDB/clusters dans les demandes de dashboard typiques.
Sanation des labels (faible cardinalité), abandon des wildcards.

19) Plan de mise en œuvre (itération)

1. Semaine 1 : Landing + avis K8s/Edge, SLO de base, propriétaires.
2. Semaine 2 : DB/Queues, intégration des loges et des sentiers (drilldown), burn-rate alerte.
3. Semaine 3 : FinOps-dashboards, recommandations de rightsizing, rapport sur les coûts.
4. Semaine 4 + : Sécurité/Conformité, autogénération des cartes SLO, tests de régression des dashboards.

20) Mini-FAQ

Combien de dashboards faut-il ?
Au moins 1 aperçu + un par domaine (K8s, Edge, DB, Queues, CI/CD, Security, Cost). Le reste est par maturité.

Plus important, les métriques ou les logs ?
Métriques pour les symptômes et SLO, logs pour les causes. Ligament via 'trace _ id' et labels consistants.

Comment ne pas se noyer dans les panneaux ?
Hiérarchie, propriétaires explicites, hygiène des métriques, rougissement régulier et retrait des panneaux « morts ».

Résultat

Les dashboards d'infrastructure ne sont pas des « beaux graphiques », mais un outil de gestion : SLO control, RCA rapide et FinOps conscient. Uniformiser les variables, les modèles visuels et les propriétaires ; fournir drilldown aux logs/pistes et automatiser les alertes burn-rate. Cela donnera de la prévisibilité, de la rapidité de réaction et de la transparence des coûts au niveau de l'ensemble de la plateforme.