Monitorowanie uptime i bicia serca

1) Dlaczego go potrzebujesz

Wczesne wykrycie przerw na obwodzie i wewnątrz (rdzeń krawędzi).
Potwierdzenie dostępności użytkownika (nie tylko „są strumieniami żywymi”).
sprawozdawczość umowna SLA/SLO i obowiązki prawne.
Monitorowanie procesów tła (cron, ETL, siniaki płatnicze) poprzez bicie serca.

Metody: Złote sygnały (opóźnienia/ruch/błędy/nasycenie), RED, link do SLO i błędny budżet.

2) Rodzaje kontroli (syntetyki)

ICMP: podstawowa dostępność sieci/IP.
TCP: port żyje/uścisk dłoni (np. 443/5432).
TLS: ważność/termin/łańcuch certyfikatów.
HTTP (S): kod odpowiedzi, opóźnienie, nagłówki, podłoże kluczy w ciele.
DNS: rozdzielczość, TTL, NXDOMAIN/SERVFAIL.
Przeglądarka bezgłowa (ścieżka użytkownika): login → akcja → wylogowanie.
Niestandardowe sondy: autoryzacja płatności w piaskownicy PSP, wewnętrzna syntetyka biznesowa (symulacja depozytów).

Wskazówki: Sprawdź zarówno krawędź, jak i prywatne punkty końcowe (od wewnątrz VPC/K8s) to różne domeny ryzyka.

3) Architektura monitorująca czas uptime

Badacze według regionu (minimum 3 punkty geograficzne).
Eksporter Blackbox dla HTTP/TCP/TLS/DNS.
Syntetyka według ścieżek (etapy sekwencyjne) oddzielnie; przechowywać skrypty.
Prometheus/Mimir/Thanos: zbieranie mierników, zasada SLO/alert.
Alertmanager/Pager: routing P1/P2, eskalacja.
Strona Status: przejrzyste aktualizacje dla firm/klientów.
Kłody/ślady: wiercenie przez 'trace _ id'/korelacja.

4) Punkty końcowe zdrowia: projekt

/ healthz (los) - „to proces żywy”.
/ readyz (gotowość) - „gotowy do odbioru ruchu” (zależności z progami).
/ startupz - „zainicjowany”.
/ check - zaawansowana kondycja biznesowa (łatwa baza danych/kontrola pamięci podręcznej z terminami i wyłącznikiem).
Zdrowie semantyczne: kod 200 tylko wtedy, gdy zależności krytyczne są funkcjonalne; degradacja → 503.

Zasady: czas ≤ 2-3 s, ograniczone kontrole podwykonawcze, brak PII w odpowiedziach, podręcznik części ciężkich.

5) Bicie serca dla pracy i pracowników

Model przełącznika martwego człowieka: jeśli kleszcz nie dotarł na czas, alert.
Użycie: cron/ETL/faktury, kontrole płatności pozagiełdowych, pracownicy tła.

• Bicie serca HTTP: zadanie po zakończeniu robi 'POST/bicie serca/< job>'.
• Metrics-pull: expose 'last _ success _ timestamp' i alert 'starszy niż N minutes'.
• Watchdog: stały sygnał od agenta; brak - alert „break monitoring”.

6) Przykłady konfiguracji

6. 1 Blackbox-eksporter (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 Prometeusz: Cele 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 Bicie serca Job Metrics (Prometheus eksporter)

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

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

6. 4 Watchdog (przełącznik martwego człowieka)

W Alertmanager, włączyć trasę alarmu „Watchdog” (zawsze strzelanie) → jeśli alert nie przyjdzie, monitoring jest złamany.

7) Przykłady PromQL dla 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) Ostrzeganie: progi i przeciwhałasowe

Kworum wielobranżowe: wywołane, jeśli ≥ 2 regiony widzą spadek.
Multi-okno: 1-5 min (szybki kanał) + 30-60 min (stały trend).
Wrażliwość: debounce/na: 2-5 minut przed klapami.
Korelacja: powiązać alarm uptime z metrykami skórzanymi (krawędź, DNS, WAF, pochodzenie).
Okna konserwacji: tłumienie wpisów przez 'maintenance = true' tagi.

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

9) Kontrole wielobranżowe i wielopoziomowe

Minimum 3 geografie (EU/NA/APAC) i różne ASN.
Duplikat: własne próbki + zewnętrzny dostawca uptime.
IPv4/IPv6, HTTP/2/3, różne POP CDN i profile WAF.

10) Kontrole bezpieczeństwa

Zezwalaj na zakres IP próbek na WAF/LB.
Wartości graniczne i obwodnica captcha dla punktów końcowych/sond zdrowotnych.
Podpis tytułowy (HMAC) dla zdrowia prywatnego.
Odrębne dziedziny: próbki publiczne i prywatne (/wewnętrzne/zdrowotne).
Nie zwracaj wewnętrznych wersji/konfiguracji do/healthz; tylko statusy.

11) sprawozdawczość SLO i czas pracy

Dostępność sondy SLI: 2xx/3xx sonda sukcesu.
Przykład SLO: ≥ 99. 95% w ciągu 28 dni w większości regionów.
Błędny budżet: '1 − SLO' → zarządza wydaniami.
Alerty spalania: szybki/powolny kanał dla proporcji awarii próbki.

12) Bicie serca w przypadku płatnych i krytycznych miejsc pracy

Praca „wokół pieniędzy” (transfery, rejestry) - podwójna kontrola: bicie serca + liczniki biznesowe (ile rejestrów jest przetwarzanych).
Wpisy przez „milczenie” (brak nowych zdarzeń> N minut) i przez opóźnienie (opóźnienie w czasie rzeczywistym).

13) Strony o statusie

Oddzielne komponenty (API, płatności, backendy, CDN).
Automatyczne aktualizacje z wpisów, ręczne komentarze za pośrednictwem roli Comms.
Historia incydentów, linki pośmiertne, zaplanowane prace.

14) Integracja z procesem incydentów

Alert SEV według zasad kworum + czas trwania.
Auto-stworzenie karty incydentu, pokój wojenny, zadanie IC.
Szablony komunikacyjne (wewnętrzne/zewnętrzne), w razie potrzeby blokada prawna.
Po weryfikacji: syntetyka zielona ≥ X minut do „Rozdzielczość”.

15) Wydajność i koszt

Częstotliwość pobierania próbek: krytyczny - co 30-60 s; drugorzędne - 1-5 min.
Pamięć masowa: zasady downsampling/recording dla długich okien.
Budżet zewnętrznych dostawców: ograniczenie zaawansowanych skryptów przeglądarki do harmonogramu.

16) Lista kontrolna jakości

• Istnieją/healthz ,/readyz ,/startupz z wyraźną semantyką.
• Próbki z ≥ 3 regionów/ASN, IPv4/IPv6.
• Kontrole i wpisy TLS/DNS T-30/T-7/T-1 dni.
• Bicie serca wszystkich krytycznych miejsc pracy (i „milczenie” biznesu).
• Multi-window + quorum, bez klapowania.
• Wiercenie: przyciski do dzienników/utworów/desek rozdzielczych.
• Strona statusu i szablony komunikacji.
• Dokumentacja SLO/mierników i właścicieli.

17) Plan realizacji (3 iteracje)

1. Tydzień 1: sondy blackbox HTTP/TLS/DNS według domen krytycznych, strona stanu, podstawowe wpisy.
2. Tydzień 2: Wielowymiarowość, zasady kworum, praca z biciem serca, Watchdog.
3. Tydzień 3: skrypty bez głowy (login/deposit), raportowanie SLO, integracja z procesem incydentów.

18) Mini-FAQ

Dlaczego zewnętrzne próbki są lepsze niż wewnętrzne?
Użytkownicy zewnętrzni widzą prawdziwą ścieżkę użytkownika (DNS/CDN/WAF), użytkownicy wewnętrzni widzą stan pochodzenia. Potrzebujemy obu.

Czy muszę sprawdzić płatne PSP?
Tak: syntetyka w piaskownicy i monitorowanie strony stanu; w przypadku degradacji - automatyczne inteligentne trasy.

Jak zmniejszyć hałas?
Kworum, wielokrotne okno, opóźnienie, tłumienie konserwacji, wyraźne progi SLO i własność.

Razem

Monitoring uptime to nie tylko ping. Jest to system: wielowarstwowa syntetyka + wysokiej jakości punkty końcowe zdrowia + praca z biciem serca + strony SLO/alert + status. Standaryzuj kontrole, zmniejszyć hałas, chronić próbki i połączyć wszystko z procesem incydentu - w ten sposób zmniejszyć MTTR i zapisać błędny budżet.