Uptime și monitorizarea bătăilor inimii

1) De ce aveți nevoie de ea

Detectarea precoce a întreruperilor la perimetru și în interior (marginea ↔ miezul).
Confirmarea disponibilității utilizatorului (nu doar „sunt păstăile în viață”).
SLA/SLO raportare contractuală și obligații legale.
Monitorizarea proceselor de fond (cron, ETL, vânătăi de plată) prin bătăi ale inimii.

Metodologii: Semnale de aur (latență/trafic/erori/saturație), RED, legătură cu SLO și buget eronat.

2) Tipuri de controale (sintetice)

ICMP: disponibilitate de bază în rețea/IP.
TCP: portul este viu/strângere de mână (de ex. 443/5432).
TLS: valabilitate/termen/lanț de certificate.
HTTP (S): cod de răspuns, latență, antete, substraturi cheie în corp.
DNS: rezoluție, TTL, NXDOMAIN/SERVFAIL.
Browser fără cap (calea utilizatorului): conectare → acțiune → deconectare.
Sonde personalizate: autorizație de plată în sandbox PSP, sintetică internă de afaceri (simulare de depozit).

Sfaturi: Verificați atât margine și puncte finale private (din interiorul VPC/K8s) sunt domenii de risc diferite.

3) Arhitectura de monitorizare uptime

Agenți de încercare pe regiuni (minim 3 geo-puncte).
Blackbox exportator pentru HTTP/TCP/TLS/DNS.
Sintetica prin trasee (pași secvențiali) separat; stoca script-uri.
Prometheus/Mimir/Thanos: colectarea de valori, SLO/regula de alertă.
Alertmanager/Pager: P1/P2 de rutare, escaladare.
Status Page: actualizări transparente pentru afaceri/clienți.
Busteni/urme: foraj prin 'trace _ id'/corelare.

4) Health-endpoints: design

/ healthz (liveness) - „este procesul viu”.
/ readyz (pregătire) - „gata să primească trafic” (dependențe cu praguri).
/ startupz - „initializat”.
/ check - sănătate avansată de afaceri (baze de date ușor/cache verificări cu timeout și circuit-breaker).
Sănătate semantică: cod 200 numai atunci când dependențele critice sunt funcționale; degradarea → 503.

Reguli: timeout ≤ 2-3s, sub-verificări limitate, fără PII în răspunsuri, piese grele cache.

5) Bătăi de inimă pentru locul de muncă și lucrători

Modelul comutatorului omului mort: dacă căpușa nu a ajuns la timp, alertă.
Utilizare: locuri de muncă cron/ETL/factură, controale de plată în afara lanțului, lucrători de fond.

• Push-heartbeat HTTP: de locuri de muncă atunci când a terminat face "POST/bătăi ale inimii/< job> '.
• Metrics-pull: expune 'last _ success _ timestamp' și alertă prin „mai vechi de N minute”.
• Watchdog: semnal constant de la agent; lipsă - alertă „pauză de monitorizare”.

6) Exemple de configurare

6. 1 Blackbox-exportator (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 Prometeu: ținte și Jabs

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 Heartbeat Job Metrics (Prometheus exportator)

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

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

6. 4 Câine de pază (Comutatorul omului mort)

În Alertmanager, activați ruta de alertă „Watchdog” (întotdeauna de tragere) → în cazul în care alerta nu vine, monitorizarea este ruptă.

7) Exemple PromQL pentru uptime

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) Alertare: praguri și anti-zgomot

Cvorumul multiregional: declanșat dacă regiunile ≥2 văd o scădere.
Multi-fereastră: 1-5 min (canal rapid) + 30-60 min (tendință constantă).
Sensibilitate: debunch/pentru: 2-5 minute contra clapare.
Corelație: asociați alerta de uptime cu măsurarea pielii (margine, DNS, WAF, origine).
Ferestre de întreținere: suprimarea alertelor prin etichete „întreținere = adevărat”.

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

9) Controale multi-regiune și multi-furnizor

Minim 3 geografii (EU/NA/APAC) și diferite ASN-uri.
Duplicat: mostre proprii + furnizor extern de uptime.
IPv4/IPv6, HTTP/2/3, diferite POP-uri CDN și profiluri WAF.

10) Controale de securitate

Se permit intervale IP de probe pe WAF/LB.
Rate-limite și captcha-bypass pentru puncte finale/sonde de sănătate.
Semnătura de titlu (HMAC) pentru sănătatea privată.
Domenii separate: mostre publice și private (/interne/de sănătate).
Nu returnați versiunile interne/configurații la/healthz; numai statusuri.

11) SLO și raportarea uptime

SLI Disponibilitate: 2xx/3xx Rata de succes a sondei HTTP.
Exemplu SLO: ≥ 99. 95% în 28 de zile în majoritatea regiunilor.
Buget eronat: „1 − SLO” → gestionează versiunile.
Alerte Burn-rate: canal rapid/lent pentru proporția de eșecuri eșantion.

12) Bătăi de inimă pentru plăți și locuri de muncă critice

Locuri de muncă „în jurul valorii de bani” (transferuri, registre) - dublu control: bătăi ale inimii + contoare de afaceri (câte înregistrări sunt procesate).
Alerte prin „tăcere” (fără evenimente noi> N minute) și prin lag (lag în spatele în timp real).

13) Pagini de stare

Componente separate (API-uri, plăți, backend-uri, CDN-uri).
Actualizări automate din alerte, comentarii manuale prin intermediul rolului Comms.
Istoricul incidentelor, legături post-mortem, lucrări planificate.

14) Integrarea cu procesul incident

Avertizați SEV după regulile cvorumului + durata.
Auto-crearea unui card incident, război-cameră, IC atribuire.
Șabloane de comunicare (interne/externe), Legal Hold, dacă este necesar.
Post-verificare: sintetice verde ≥ X minute la „Rezolvate”.

15) Performanță și cost

Frecvența de eșantionare: critică - la fiecare 30-60 s; secundar - 1-5 min.
Stocare: downsampling/înregistrare reguli pentru ferestre lungi.
Bugetul furnizorilor externi: limitați scripturile avansate ale browserului la program.

16) Lista de verificare a calității

• Există/healthz ,/readyz ,/startupz cu semantică clară.
• Probe din ≥3 regiuni/ASN, IPv4/IPv6.
• TLS/DNS verifică și alerte T-30/T-7/T-1 zile.
• Bătăi de inimă toate locurile de muncă critice (și de afaceri „tăcere”).
• Multi-fereastră + cvorum, fără flapping.
• Drilldown: butoane pentru jurnale/piese/tablouri de bord.
• Pagina de stare și șabloane de comunicare.
• Documentația SLO/metrici și proprietari.

17) Planul de implementare (3 iterații)

1. Săptămâna 1: HTTP/TLS/DNS sonde blackbox de domenii critice, pagina de stare, alerte de bază.
2. Săptămâna 2: Multi-regionalitate, reguli de cvorum, bătăi de inimă de locuri de muncă de top, Watchdog.
3. Săptămâna 3: scripturi fără cap (autentificare/depunere), raportare SLO, integrare cu procesul incident.

18) Mini-Întrebări frecvente

De ce sunt probele externe mai bune decât cele interne?
Utilizatorii externi văd calea utilizatorului real (DNS/CDN/WAF), utilizatorii interni văd starea de origine. Avem nevoie de amândouă.

Trebuie să verific PSP-urile plătite?
Da: sintetice în sandbox și monitorizarea paginii de stare; în caz de degradare - rutare automată inteligentă.

Cum de a reduce zgomotul?
Cvorum, multi-fereastră, pentru întârziere, suprimarea întreținerii, praguri SLO clare și proprietatea.

Total

Monitorizarea uptime nu este doar ping. Acesta este un sistem: sintetice multiregionale + puncte finale de sănătate de înaltă calitate + bătăi de inimă de locuri de muncă + SLO/alertă + pagini de stare. Standardizați verificările, reduceți zgomotul, protejați probele și conectați totul la procesul incident - în acest fel reduceți MTTR și salvați bugetul eronat.