Monitoraggio farmacia e heartbeat

1) Perché è necessario

Rilevamento precoce dei tempi di inattività nel perimetro e all'interno (edge n'core).
Conferma la disponibilità dell'utente (e non solo se i sottoprodotti sono vivi).
Rapporti contrattuali SLA/SLO e obblighi legali.
Controllo dei processi di fondo (cron, ETL, sink di pagamento) tramite heartbeat.

Metodologie: Golden Signals (latency/traffic/errors/saturation), RED, collegamento a SLO e budget errati.

2) Tipi di controllo (synthetics)

ICMP: rete/disponibilità IP di base.
TCP: porta viva/handshake (ad esempio 443/5432).
TLS: validità/scadenza/catena di certificati.
HTTP (S) - Codice di risposta, latency, intestazioni, sottocartelle chiave in body.
DNS: taglio, TTL, NXDOMAIN/SERVFAIL.
Browser Headless (percorso utente): login → azione → logout.
Custom probes: autorizzazione al pagamento in sandbox PSP, sintetica aziendale interna (deposit simulation).

Suggerimenti: controllare sia edge che endpoint privati (dall'interno di VPC/K8s) sono domini di rischio diversi.

3) Architettura di monitoraggio delle farmacie

Agenti di prova per regione (minimo 3 punti geo).
L'esportatore Blackbox per HTTP/TCP/TLS/DNS.
Sintetico per percorsi (sequential steps) separatamente; Conservate gli script.
Prometheus/Mimir/Thanos - Raccolta di metriche, regola SLO/alert.
Alertmanager/Pager: instradamento P1/P2.
Status Page: update trasparenti per business/client.
Linee/piste: drilldown per «trace _ id »/correlazione.

4) Health-endpoint: design

/ healthz - Se il processo è vivo.
/ readyz - «Pronto a prendere traffico» (dipendenze con soglie).
/ startupz è stato inizializzato.
/ check - health aziendale estesa (controlli di database/cache leggeri con timeout e circuito-breaker).
Codice Semantic health: 200 solo per le dipendenze critiche Il degrado è → 503.

Regole: timeout 2-3s, controlli sotto controllo limitati, senza PI nelle risposte, cache parti pesanti.

5) Heartbeat per i workers e i worker

Il modello Dead Man's Switch, se la teca non è arrivata in tempo, è un alert.
Utilizzo: cron/ETL/fatture jobs, controlli di pagamento off-chain, worker di sfondo.

• Push-heartbeat HTTP: jobs al termine di «POST/heartbeat/< job>».
• Metrics-pull: espone «last _ success _ timestamp» e alerti per «più di N minuti».
• Watchdog: segnale costante da un agente; Sparito. Alert «Dirottamento».

6) Esempi di configurazione

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: target e 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 Heartbeat-metrica per il jobs (Prometheus exporter)

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)

In Alertmanager, accendere la route per alert «Watchdog» (sempre firing) se l'avviso non arriva - il monitoraggio è rotto.

7) Esempi di PromQL per farmacia

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: soglie e anti-rumore

Multi-region quorum: funziona se le regioni ≥2 vedono un calo.
Multi-window: 1-5 min (canale veloce) + 30-60 min (trend costante).
Sensibilità: debounce/for: 2-5 minuti contro il flapping.
Correlazione: collegare farmacie alert a layer metriche (edge, DNS, WAF, origin).
Maintenance windows - Sopprimere gli alert in base ai tag maintenance = true.

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

9) Controlli molti-regionali e molti-venditori

Almeno 3 geografie (EU/NA/APAC) e ASN diverse.
Rinnovate i vostri campioni e il provider di farmacie esterne.
IPv4/IPv6, HTTP/2/3, diversi CDN ROR e profili WAF.

10) Sicurezza dei controlli

Allowlist IP intervalli di campioni per WAF/LB.
Rate-limits e capcha-bypas per endpoint health/campioni.
Firma intestazione (HMAC) per health private.
Domini separati: provini pubblici e privati (/internal/health).
Non restituire le versioni interne/confighi a/healthz; Solo gli stati.

11) SLO e rapporti di farmacia

SLI Availability: percentuale di provini HTTP 2xx/3xx di successo.
SLO esempio: ≥ 99. 95% in 28 giorni per la maggior parte delle regioni.
Budget errato: '1 - SLO', gestisce i comunicati.
Burn-rate alert è un canale veloce/lento per la percentuale di fallimenti del campione.

12) Heartbeat per i pagamenti e le critiche

Job «intorno al denaro» (trasferimenti, registri) - doppio controllo: heartbeat + contatori aziendali (quanti record elaborati).
Alert per «silenzio» (nessun nuovo evento> N minuti) e per raggio (ritardo dal real-time).

13) Stato pagina

Separare i componenti (API, pagamenti, backend, CDN).
Update automatici da alert, commenti manuali attraverso il ruolo Comms.
Storia di incidenti, collegamenti post-mortem, lavori pianificati.

14) Integrazione con il processo di incidente

Alert SEC secondo le regole quorum + durata.
Auto-creazione tessera incidente, war-room, assegnazione IC.
Modelli di comunicazione (interni/esterni), Legali Hold se necessario.
Dopo la verifica, il sintetico è verde X minuti prima di «Resolved».

15) Prestazioni e costi

Frequenza dei campioni: critici - ogni 30-60s; secondario - 1-5 minuti

Storage: downsampling/recording rule per finestre lunghe.
Budget dei provider esterni: limitare gli script di browser avanzati in base alla pianificazione.

16) Assegno-foglio di qualità

• C'è/healthz ,/readyz ,/startupz con una semantica chiara.
• Campioni da regioni ≥3/ASN, IPv4/IPv6.
• Controlli TLS/DNS e alert T-30/T-7/T-1 giorni.
• Heartbeat di tutti i critici (e business «silenzio»).
• Multi-window + quorum, senza flapping.
• Drilldown: pulsanti a logi/piste/dashboard.
• Stato pagina e modelli di comunicazione.
• Documentazione SLO/metriche e proprietari.

17) Piano di implementazione (3 iterazioni)

1. Settimana 1: blackbox-test HTTP/TLS/DNS per domini critici, stato-pagina, alert di base.
2. Settimana 2: un sacco di regionalità, le regole quorum, heartbeat top, Watchdog.
3. Settimana 3: script headless (login/deposit), report SLO, integrazione con il processo di incidente.

18) Mini FAQ

Perché i provini esterni sono migliori di quelli interni?
Gli esterni vedono il percorso reale dell'utente (DNS/CDN/WAF), gli interni lo stato origin. Abbiamo bisogno di entrambi.

È necessario controllare i PSP a pagamento?
Sì, sintetico in sandbox e monitoraggio delle pagine di stato; in caso di degrado - smart-routing automatico.

Come ridurre il rumore?
Quorum, multi-window, for-ritardo, supplence su maintenance, soglie SLO chiare e possesso.

Totale

Il monitoraggio della farmacia non è solo un ping. Questo è un sistema: sintetici molto-regionali + health-endpoint di qualità + heartbeat jobs + sLO/alerting + status-page. Standardizzare i controlli, ridurre il rumore, proteggere i provini e collegare tutto al processo di incidente, in modo da ridurre il MTTR e mantenere il budget errato.