Überwachung von Aptime und Heartbeat

1) Warum es notwendig ist

Frühzeitige Erkennung von Ausfallzeiten am Perimeter und im Inneren (Edge ↔ Core).
Bestätigung der Benutzerverfügbarkeit (nicht nur „ob die Pods live sind“).
Vertragliche Berichterstattung über SLA/SLO und rechtliche Verpflichtungen.
Steuerung der Hintergrundprozesse (Cron, ETL, Payment Syncs) über Heartbeat.

Methoden: Goldene Signale (Latenz/Verkehr/Fehler/Sättigung), ROT, Bindung an SLO und fehlerhaftes Budget.

2) Arten von Inspektionen (Synthetik)

ICMP: grundlegendes Netzwerk/IP-Verfügbarkeit.
TCP: Port live/handshake (z.B. 443/5432).
TLS: Gültigkeit/Laufzeit/Zertifikatskette.
HTTP (S): Antwortcode, Latenz, Header, Schlüsselteilstrings im Körper.
DNS: Resolve, TTL, NXDOMAIN/SERVFAIL.
Headless-Browser (Benutzerpfad): Login → Aktion → Logout.
Custom probes: Zahlungsautorisierung in der PSP-Sandbox, interne Geschäftssynthese (Deposit-Simulation).

Tipps: Überprüfen Sie sowohl Edge als auch private Endpoints (von innen VPC/K8s) sind verschiedene Risikodomänen.

3) Aptime-Überwachungsarchitektur

Testagenten nach Region (mindestens 3 Geopunkte).
Blackbox-Exporteur für HTTP/TCP/TLS/DNS.
Synthetik entlang der Pfade (sequentielle Schritte) getrennt; Speichern Sie die Skripte.
Prometheus/Mimir/Thanos: Sammlung von Metriken, SLO/Alert-Regel.
Alertmanager/Pager: P1/P2 Routing, Eskalation.
Status Page: Transparente Updates für Unternehmen/Kunden.
Logs/Traces: Drilldown durch 'trace _ id '/Korrelation.

4) Gesundheit-Endpunkte: Entwurf

/ healthz (liveness) - „ob der Prozess lebt“.
/ readyz (Bereitschaft) - „bereit, Verkehr zu empfangen“ (Abhängigkeiten mit Schwellen).
/ startupz - „wurde initialisiert“.
/ check - erweiterte Business Health (einfache DB/Cache-Checks mit Timeouts und Circuit-Breaker).
Semantic health: Code 200 nur, wenn kritische Abhängigkeiten funktionieren; Verschlechterung → 503.

Regeln: Timeout ≤ 2-3s, limitierte Sub-Checks, keine PII in den Antworten, schwere Teile zwischenspeichern.

5) Herzschlag für Jobs und Worker

Dead Man's Switch-Modell: Wenn der „Tick“ nicht rechtzeitig kam - alert.
Verwendung: cron/ETL/Rechnungsjobs, Off-Chain-Zahlungsprüfungen, Hintergrundworker.

• Push-Heartbeat HTTP: Der Job macht „POST/Heartbeat/< job>“, wenn er fertig ist.
• Metrics-pull: Belichten Sie' last _ success _ timestamp 'und alertite mit „älter als N Minuten“.
• Watchdog: konstantes Signal vom Agenten; verschwunden - alert „Unterbrechung der Überwachung“.

6) Beispiele für Konfigurationen

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: Ziele und 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-Metrik für Joba (Prometheus-Exporteur)

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)

Aktivieren Sie im Alertmanager die Route für die Alert 'Watchdog' (immer firing) → wenn die Warnung nicht kommt - die Überwachung ist kaputt.

7) PromQL Beispiele für Aptyme

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: Schwellen und Anti-Lärm

Multi-region quorum: Wird ausgelöst, wenn ≥2 Regionen einen Rückgang sehen.
Multi-Fenster: 1-5 min (schneller Kanal) + 30-60 min (stetiger Trend).
Empfindlichkeit: debounce/for: 2-5 Minuten gegen Flapping.
Korrelation: Verknüpfen Sie die Aptime Alert mit Leyer-Metriken (Edge, DNS, WAF, Origin).
Windows-Wartung: Alert-Unterdrückung durch 'Wartung = wahr' -Tags.

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

9) Viele-regionale und viele-Verkäufer-Kontrollen

Mindestens 3 Geographien (EU/NA/APAC) und verschiedene ASNs.
Duplizieren: eigene Proben + externer Aptime-Anbieter.
IPv4/IPv6, HTTP/2/3, verschiedene CDNs und WAF-Profile.

10) Sicherheit der Inspektionen

Allowlist IP der Probenbereiche auf WAF/LB.
Rate-Limits und Capcha-Bypass für Gesundheits-Endpunkte/Proben.
Header Signature (HMAC) für private Gesundheit.
Getrennte Domains: öffentliche Proben und private (/internal/health).
Geben Sie keine internen Versionen/Configs an/healthz zurück; Nur Status.

11) SLO und Aptime Reporting

SLI-Verfügbarkeit: Anteil erfolgreicher 2xx/3xx HTTP-Samples.
SLO Beispiel: ≥ 99. 95% in 28 Tagen in den meisten Regionen.
Fehlerhaftes Budget: „1 − SLO“ verwaltet → Releases.
Burn-Rate-Alerts: schneller/langsamer Kanal für einen Bruchteil der Probenausfälle.

12) Heartbeat für Payment und Critical Job

Jobs „um Geld“ (Transfers, Register) - doppelte Kontrolle: Heartbeat + Geschäftszähler (wie viele Datensätze verarbeitet werden).
Alertas durch „Stille“ (keine neuen Ereignisse> N Minuten) und durch Verzögerung (Verzögerung von Echtzeit).

13) Status der Seiten

Trennen Sie Komponenten (APIs, Zahlungen, Backends, CDNs).
Automatische Updates von Alert, manuelle Kommentare über die Comms-Rolle.
Geschichte der Vorfälle, Postmortem-Links, geplante Arbeiten.

14) Integration in den Incident-Prozess

Alert SEV nach den Regeln von quorum + Dauer.
Auto-Erstellung der Störfallkarte, Kriegsraum, IC-Zuordnung.
Kommunikationsvorlagen (intern/extern), ggf. Legal Hold.
Post-Verifizierung: Synthetik grün ≥ X Minuten vor „Resolved“.

15) Leistung und Kosten

Probenfrequenz: kritisch - alle 30-60s; sekundär - 1-5 min.
Lagerung: Downsampling/Recording-Regeln für lange Fenster.
Budget für externe Anbieter: Begrenzen Sie erweiterte Browser-Skripte nach Zeitplan.

16) Qualitätscheckliste

• Es gibt/healthz ,/readyz ,/startupz mit klarer Semantik.
• Proben aus ≥3 Regionen/ASN, IPv4/IPv6.
• TLS/DNS-scans und alerts T-30/T-7/T-1 Tage.
• Heartbeat aller kritischen Jobs (und Business „Stille“).
• Multi-window + quorum, ohne Flapping.
• Drilldown: Buttons zu Logs/Tracks/Dashboards.
• Status-Seite und Kommunikationsvorlagen.
• Dokumentation von SLOs/Metriken und Eigentümern.

17) Implementierungsplan (3 Iterationen)

1. Woche 1: HTTP/TLS/DNS Blackbox-Tests für kritische Domains, Status-Seite, Basis-Alerts.
2. Woche 2: Viel-Regionalität, Quorum-Regeln, Herzschlag-Top-Job, Watchdog.
3. Woche 3: Headless-Szenarien (Login/Deposit), SLO-Reporting, Integration in den Incident-Prozess.

18) Mini-FAQ

Warum sind externe Proben besser als interne?
Externe sehen den realen Pfad des Benutzers (DNS/CDN/WAF), interne sehen den Ursprungszustand. Wir brauchen beides.

Muss ich bezahlte PSPs überprüfen?
Ja: Synthetik in der Sandbox und Überwachung der Status-Seiten; beim Abbau - automatisches Smart-Routing.

Wie kann man Lärm reduzieren?
Quorum, Multi-Window, For-Delay, Suppression auf Wartung, klare SLO-Schwellenwerte und Besitz.

Summe

Bei der Aptime-Überwachung geht es nicht nur um Ping. Es ist ein System: multiregionale Synthetics + hochwertige Health-Endpoints + Heartbeat Job + SLO/Alerting + Status-Seiten. Standardisieren Sie Inspektionen, reduzieren Sie Lärm, schützen Sie Proben und verknüpfen Sie alles mit dem Incident-Prozess - so reduzieren Sie die MTTR und sparen Sie ein fehlerhaftes Budget.