Surveillance de l'aptyme et du heartbeat

1) Pourquoi est-ce nécessaire

Détection précoce des interruptions de service sur le périmètre et à l'intérieur (edge ↔ core).
Confirmation de la disponibilité de l'utilisateur (et pas seulement « si les pods sont vivants »).
Déclaration contractuelle de SLA/SLO et obligations légales.
Contrôle des processus de fond (cron, ETL, sinks de paiement) via heartbeat.

Méthodologies : Signaux d'or (latitude/trafic/erreurs/saturation), RED, liaison à SLO et budget erroné.

2) Types de contrôles (synthétiques)

ICMP : réseau de base/disponibilité IP.
TCP : port vivant/handshake (par exemple 443/5432).
TLS : validation/durée/chaîne de certificats.
HTTP (S) : code de réponse, latitude, en-têtes, sous-chaînes clés dans le body.
DNS : Résolve, TTL, NXDOMAIN/SERVFAIL.
Navigateur headless (chemin d'accès de l'utilisateur) : login → action → logout.
Custom probes : autorisation de paiement en sandbox PSP, synthétiseur d'entreprise interne (deposit simulation).

Conseils : vérifiez à la fois le bord et les endpoints privés (de l'intérieur du VPC/K8s) sont différents domaines de risque.

3) L'architecture de surveillance de l'aptame

Agents d'essai par région (3 points géo minimum).
L'exportateur Blackbox pour HTTP/TCP/TLS/DNS.
Synthétique par voie (steps sequential) séparément ; gardez les scripts.
Prometheus/Mimir/Thanos : collecte de métriques, règle SLO/alerts.
Alertmanager/Pager : routage de P1/P2, escalade.
Status Page : Apdates transparentes pour les entreprises/clients.
Logs/Tracks : drilldown par 'trace _ id'/corrélation.

4) Endpoints de santé : conception

/ healthz (liveness) - « si le processus est vivant ».
/ readyz (read....) - « prêt à recevoir du trafic » (dépendances avec seuils).
/ startupz - « initialisé ».
/ check - amélioration de la santé des entreprises (vérification facile de la base de données/cache avec les timeouts et circuit-breaker).
Santé Semantic : code 200 uniquement lorsque les dépendances critiques fonctionnent ; dégradation → 503.

Règles : Temporisation ≤ 2-3c, sous-vérifications limitées, sans PII dans les réponses, mettre en cache les parties lourdes.

5) Heartbeat pour les job et les workers

Le modèle Dead Man's Switch : si le « tick » n'est pas arrivé à temps - alert.
Utilisation : cron/ETL/jobs de facturation, chain de vérification des paiements, workers de fond.

• Push-heartbeat HTTP : joba à la fin fait 'POST/heartbeat/< job>'.
• Metrics-pull : exposez 'last _ success _ timestamp' et alertez par « plus de N minutes ».
• Watchdog : signal constant de l'agent ; disparu - alert « falaise de surveillance ».

6) Exemples de configurations

6. 1 Blackbox-exporter (HTTP + TLS + DNS)

yaml modules:
http_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"
fail_if_not_ssl: true valid_http_versions: ["HTTP/1. 1","HTTP/2"]
tls_config:
insecure_skip_verify: false headers:
User-Agent: "uptime-probe"
body: ""
ip_protocol_fallback: false

tls_cert:
prober: tcp tcp:
query_response: []
tls: true tls_config:
insecure_skip_verify: false

dns:
prober: dns dns:
query_name: "api. example. com"
valid_rcodes: ["NOERROR"]
preferred_ip_protocol: "ip4"

6. 2 Prometheus : targets et jobs

yaml scrape_configs:
- job_name: 'blackbox-http'
metrics_path: /probe params:
module: [http_2xx]
static_configs:
- targets:
- https://api. example. com/healthz
- https://pay. example. com/readyz relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: blackbox-exporter:9115
- source_labels: [__param_target]
target_label: instance

6. 3 métriques Heartbeat pour jobs (Prometheus exportateur)

job_last_success_timestamp_seconds{job="settlement"} 1. 730000e+09

promql
(time() - job_last_success_timestamp_seconds{job="settlement"}) > 900

6. 4 Watchdog (Dead Man’s Switch)

Dans Alertmanager, activez la route pour alert 'Watchdog' (toujours en cours) → si l'alerte ne vient pas - la surveillance est cassée.

7) Exemples BouQL pour l'pharmacie

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0. 95, sum by (le, instance) (rate(probe_http_duration_seconds_bucket[5m])))

promql
(min_over_time(probe_ssl_earliest_cert_expiry[5m]) - time()) < 7243600

promql rate(probe_dns_rcode{rcode!="NOERROR"}[5m]) > 0

promql sum_over_time((probe_success==1)[28d]) / (28246060)

8) Alerting : seuils et anti-bruit

Quorum multi-région : fonctionne si les régions ≥2 voient tomber.
Multi-window : 1-5 min (canal rapide) + 30-60 min (tendance soutenue).
Sensibilité : debounce/for : 2-5 minutes contre le flapping.
Corrélation : relier l'aptyme alert aux métriques leyer (edge, DNS, WAF, origin).
Maintenance Windows : supprime les alertes par les balises 'maintenance = true'.

promql
≥2 regions simultaneously failed sum by (target) (max_over_time (probe _ success = = 0) [3m]))> = 2

9) Contrôles multirégionaux et multirégionaux

Au moins 3 géographies (EU/NA/APAC) et différents ASN.
Dupliquez : vos propres échantillons + un fournisseur d'aptame externe.
IPv4/IPv6, HTTP/2/3, différents profils ROR CDN et WAF.

10) Sécurité des contrôles

Allowlist IP plages d'échantillonnage sur WAF/LB.
Rate-limits et capcha-bypass pour les endpoints santé/échantillons.
Signature des titres (HMAC) pour la santé privée.
Domaines séparés : échantillons publics et privés (/internal/health).
Ne retournez pas les versions internes/configi à/healthz ; seulement les statuts.

11) SLO et rapports sur l'pharmacie

SLI Availability : proportion d'échantillons HTTP réussis 2xx/3xx.
SLO exemple : ≥ 99. 95 % en 28 jours pour la plupart des régions.
Budget erroné : '1 − SLO' → gère les versions.
Burn-rate alerts : canal rapide/lent pour une proportion d'échecs d'échantillons.

12) Heartbeat pour les paiements et les job critiques

Jobs « autour de l'argent » (transferts, registres) - double contrôle : heartbeat + compteurs d'affaires (combien d'entrées traitées).
Alert par « silence » (pas de nouveaux événements> N minutes) et par lagune (retard sur le temps réel).

13) Statut de la page

Séparez les composants (API, paiements, backends, CDN).
Apdates automatiques d'alerts, commentaires manuels via le rôle Comms.
Historique des incidents, liens post-mortem, travaux prévus.

14) Intégration avec le processus d'incident

Alert SEV selon les règles quorum + durée.
Auto-création d'une carte d'incident, war-room, affectation IC.
Modèles de communication (interne/externe), Legal Hold si nécessaire.
Post-vérification : synthétique vert ≥ X minutes jusqu'à « Résolu ».

15) Productivité et coût

Fréquence des échantillons : critiques - chaque 30-60c ; secondaire - 1-5 min.
Stockage : downsampling/recording rules pour les fenêtres longues.
Budget des fournisseurs externes : limitez les scripts de navigateur avancés selon la planification.

16) Chèque de qualité

• Il y a/healthz ,/readyz ,/startupz avec une sémantique claire.
• Échantillons provenant de ≥3 régions/ASN, IPv4/IPv6.
• Contrôle TLS/DNS et alertes de T-30/T-7/T-1 jours.
• Heartbeat de tous les job critiques (et « silence » des affaires).
• Multi-window + quorum, sans flapping.
• Drilldown : boutons vers les logs/pistes/dashboards.
• Statut de la page et modèles de communication.
• Documentation SLO/métriques et propriétaires.

17) Plan de mise en oeuvre (3 itérations)

1. Semaine 1 : échantillons blackbox HTTP/TLS/DNS sur les domaines critiques, page de statut, alertes de base.
2. Semaine 2 : pluralité-régionalité, quorum-rules, heartbeat top job, Watchdog.
3. Semaine 3 : scripts headless (login/deposit), rapports SLO, intégration au processus incident.

18) Mini-FAQ

En quoi les échantillons externes sont-ils meilleurs que les échantillons internes ?
L'extérieur voit le chemin réel de l'utilisateur (DNS/CDN/WAF), l'état intérieur de l'origin. Il faut les deux.

Dois-je vérifier les PSP payants ?
Oui : synthétique dans la sandbox et suivi des pages de statut ; en cas de dégradation, un routage intelligent automatique.

Comment réduire le bruit ?
Quorum, multi-fenêtre, for-delay, suppression sur maintenance, SLO-seuils clairs et propriété.

Résultat

L'aptyme-surveillance n'est pas seulement un ping. C'est un système : synthétiques multirégionaux + health-endpoints de qualité + heartbeat job + SLO/alerting + status pages. Normalisez les contrôles, réduisez le bruit, protégez les échantillons et associez tout au processus d'incident - de sorte que vous réduisez MTTR et conservez un budget erroné.