Surveillance des infrastructures

Surveillance de l'infrastructure

1) Objectifs et cadre

• Avertissez-vous des pannes avant l'utilisateur (détection précoce).
• Diagnostiquer la cause première (de symbtom à cause).
• Prendre en charge SLO-Gate Releases et Auto-back.
• Nourrir l'analyse post-incident (evidence as data).

Principes de référence : Observable par design, moins de bruit - plus de signaux, automatisation des réactions, un seul panneau de vérité.

2) Triade d'observabilité

Métriques (timeseries) : vitesse/demande/erreurs/saturation (USE/RED).
Logs : détails de l'événement avec le contexte ; ne contiennent aucun secret/PII.
Tracks : traitement distribué des liens de causalité.

• Profilage (CPU/heap/lock/io), eBPF pour le niveau système.
• Evénements/audits (K8s Events, modifications configues/secrets).

3) SLI/SLO/SLA - langage de qualité

SLI (indicateur) : 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (objectif) : "demandes réussies ≥ 99. 9 % en 30 jours".
Error Budget : déviation autorisée ; utilisé pour les sorties auto-stop.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Carte des couches de surveillance

1. Hôtes/VM/nœuds : CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Réseau/LB/DNS : RTT, paquets/drops, backlog, SYN/Timeout, santé-probes.
3. Kubernetes/Orchestrator : serveur API, etcd, contrôleurs, scheduler ; pods/nœuds, pending/evicted, throttling, kube-events.
4. Services/conteneurs : RED (Rate/Errors/Durée), lecture/liveness.
5. Bases de données/caches : QPS, lock wait, replication lag, buffer hit, slow queries.
6. Files d'attente/pneus : consumer lag, requeue/dead-letter, throughput.
7. Stockage/cloud : S3/Blob des erreurs et latency, 429/503 des fournisseurs.
8. Limites du périmètre : WAF/Rate Limits, 4xx/5xx le long des itinéraires, CDN.
9. Synthétique : Vérification HTTP des scripts (dépôt/retrait), TLS/certificats.
10. Économie/capacité : cost per service, utilisation, headroom.

5) Whitebox и Blackbox

Whitebox : exportateurs/SDK au sein des services (Prometheus, OpenTelemetry).
Blackbox : échantillons externes provenant de différentes régions (disponibilité, latitude, expiration TLS).
Combiner : « signe extérieur » + « diagnostic intérieur ».

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes : signaux clés

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pods : Pending/CrashLoopBackOff, OOMKilled, restarts.
Plans/limites : Requests vs Limits, PodDissolutionBudget, HPA/VPA.
Réseau : Drops de politique de réseau, contrack exposition.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) OBD et files d'attente

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) Métriques RED/USE et corrélations commerciales

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (pour les ressources) : Utilisation, Saturation, Errors.
Associez au produit : dépôts/paiements succès, drapeaux frod, conversion sont des « gardiens » à la sortie canariale.

9) Structure d'alerte

Tier-1 (page) : incidents affectant le SLO (disponibilité, 5xx, latence, défaillance des composants critiques en grappe).
Tier-2 (tiket) : dégradation de la capacité, augmentation des erreurs sans impact sur le SLO.
Tier-3 (infos) : tendances, capacité prédictive, certificats expirant.

Règles d'escalade : temps de silence/compression des doublons, rotation sur appel, « follow-the-sun ».

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Exemples de règles Prometheus

10. 1 Erreurs 5xx avec seuil SLO

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Brûlage error-budget (burn multi-window)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Saturation du système (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Logs : Collecte, normalisation, rétention

Standardisation : JSON-logs : 't',' level ',' service ',' trace _ id', 'user/tenant'.
Pipline : Agent (Fluent Bit/Vector) → tampon → index/stockage.
Edito : masquer les PII/secrets sur le bord.
Retenshn : classe de stockage rapide (7-14 jours), archive « froide » (30-180 jours).
Sémantique : error budgets/deprecates sont des canaux distincts.

12) Tracs et OpenTelemetry

Utilisez l'outil Points d'entrée (gateway), appels kliyent→servis, bases de données/caches/files d'attente.
Liez les métriques aux attributs de trace (Exemplars) pour une navigation rapide.
OTel Collector en tant que passerelle centrale : filtrage, échantillonnage, exportation vers les beckends sélectionnés.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Contrôles synthétiques et externes

Les pistes HTTP des scénarios d'affaires (login, dépôt, retrait, achat).
TLS/Domain : durée des certificats/CAA/DNS health.
Régionalité : échantillons provenant des principaux pays/fournisseurs (routage/organigrammes).
La synthétique doit être alerte si elle n'est pas disponible pour l'utilisateur, même avec la télémétrie interne verte.

14) Profilage et eBPF

Profilage continu : identification des fonctions chaudes, des verrous.
eBPF : événements système (syscalls, TCP retransmits), sur la vente avec un minimum d'overhead.
Les alertes de profilage sans straticien (tiquets), et pour les régressions après la libération - comme un signal de retour.

15) Dashboards et « panneau de vérité »

1. Présentation de la plateforme : SLI/SLO sur les services clés, error-budget, alertes.

2. API RED : RPS/ERRORS/DURÉE par itinéraire.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues : backlog/lag, refusé/répété.

6. Per-release : comparaison des métriques avant/après (fenêtres canaries).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Incidents, alertes sonores et escalade

Déduplication : regroupement par service/cause, suppression des cascades.
Silence/maintenance : Les sorties/migrations ne doivent pas « peindre » tout en rouge.
Runbooks : chaque alerte critique avec des étapes de diagnostic et un « bouton » de retour.
Postmortem : la ligne temporelle, ce qu'on a appris, quels signaux ont été ajoutés/nettoyés.

17) Sécurité dans la surveillance

RBAC pour la lecture/modification des règles/datasors.
Secrets : les tokens des exportateurs/agents - via Secret Manager.
Isolation : métriques clients/tenants - dans des espaces/labels séparés.
Intégrité : signature des agents/bilds, configi via GitOps (merge-revue).

18) Finances et capacité (FinOps)

Quotas et budgets ; alertes à croissance anormale.
Right-sizing : analyse des demandes/limites, élimination des CPU/RAM, spot-instances pour les tâches non critiques.
« Cost per request/tenant » en tant que KPI d'efficacité.

19) Anti-modèles

Seulement des métriques d'infrastructure sans SLI personnalisé.
100 + alerts « sur tout » → cécité sur appel.
Logs comme seule source (pas de métriques et de tracing).
Dashbords mutables sans versioning/rhubarbe.
Manque de synthétiseurs : « tout est vert », mais le front n'est pas disponible.
Il n'y a pas de lien avec les communiqués : vous ne pouvez pas répondre « ce qui a changé au moment X ».

20) Chèque de mise en œuvre (0-60 jours)

0-15 jours

Définir SLI/SLO pour 3-5 services clés.
Inclure les exportateurs/agents de base, normaliser les logs JSON.
Configurer le Tier-1 alerte (availability, 5xx, p95).

16-30 jours

Ajouter des synthétiques selon des scénarios critiques.
Activer les trajets (OTel) sur les services d'entrée/critiques.
Dashboards « Per-release » et error-budget burn-rules.

31-60 jours

Couvrir les bases de données/files d'attente/cache avec des signaux avancés.
Implémenter eBPF/profilage pour les services high-CPU.
GitOps pour règles/dashboards/alerts, nettoyage régulier du bruit.

21) Métriques de maturité

Couverture SLO des services clés ≥ 95 %.
MTTA/MTR (cible : min/dizaines de minutes).
Proportion d'alertes Tier-1 fermées par auto-action ou par un retour rapide.
Rapport alertes « utiles « / » bruyantes »> 3:1.
Couverture synthétique de toutes les voies « monétaires » = 100 %.

22) Applications : Mini-modèles

Prometheus - accessibilité par classe de statut

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - Conseil pour les Canaries

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - Garde et silence

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Conclusion

La surveillance n'est pas un ensemble de graphiques, mais un système d'exploitation SRE : SLI/SLO en tant que contrat de qualité, métriques/tracés/logs en tant que sources de vérité, alertes en tant que signal contrôlé, synthétique en tant que « voix de l'utilisateur », GitOps en tant que discipline de changement. Construisez un circuit unique de l'hôte à l'API, attachez-le aux versions et aux retours - et la plate-forme sera prévisible, rapide et économique.