Моніторинг аптайма та heartbeat

1) Навіщо це потрібно

Раннє виявлення простоїв на периметрі і всередині (edge ↔ core).
Підтвердження користувацької доступності (а не тільки «чи живі поди»).
Контрактна звітність по SLA/SLO і юридичні зобов'язання.
Контроль фонових процесів (cron, ETL, платіжні синки) через heartbeat.

Методології: Golden Signals (latency/traffic/errors/saturation), RED, прив'язка до SLO і помилкового бюджету.

2) Види перевірок (synthetics)

ICMP: базова мережевуха/доступність IP.
TCP: порт живий/handshake (наприклад, 443/5432).
TLS: валідність/термін/ланцюжок сертифікатів.
HTTP(S): код відповіді, latency, заголовки, ключові підрядки в body.
DNS: резолв, TTL, NXDOMAIN/SERVFAIL.
Headless-браузер (шлях користувача): login → дію → logout.
Custom probes: платіжна авторизація в sandbox PSP, внутрішня бізнес-синтетика (deposit simulation).

Поради: перевіряйте і edge, і приватні ендпоінти (зсередини VPC/K8s) - це різні домени ризику.

3) Архітектура аптайм-моніторингу

Пробні агенти по регіонах (мінімум 3 гео-точки).
Blackbox-експортер для HTTP/TCP/TLS/DNS.
Синтетика по шляхах (sequential steps) окремо; зберігайте скрипти.
Prometheus/Mimir/Thanos: збір метрик, правило SLO/алертів.
Alertmanager/Pager: маршрутизація P1/P2, ескалації.
Status Page: прозорі апдейти для бізнесу/клієнтів.
Логи/траси: drilldown по'trace _ id '/кореляції.

4) Health-ендпоінти: дизайн

/ healthz (liveness) - «чи живий процес».
readyz (readiness) - «готовий приймати трафік» (залежності з порогами).
/ startupz - «пройшов ініціалізацію».
/ check - розширений бізнес-health (легкі перевірки БД/кешу з таймаутами і circuit-breaker).
Semantic health: код 200 тільки при працездатності критичних залежностей; деградація → 503.

Правила: таймаут ≤ 2-3с, лімітовані під-перевірки, без PII у відповідях, кешуйте важкі частини.

5) Heartbeat для джоб і воркерів

Модель Dead Man's Switch: якщо «тік» не прийшов вчасно - алерт.
Використання: cron/ETL/інвойс-джоби, off-chain перевірки платежів, фонові воркери.

• Push-heartbeat HTTP: джоба по завершенні робить'POST/heartbeat/< job>'.
• Metrics-pull: експонуйте'last _ success _ timestamp'і алертіть по «старше N хвилин».
• Watchdog: постійний сигнал від агента; пропав - алерт «обрив моніторингу».

6) Приклади конфігурацій

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: Таргети та джоби

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-метрика для джоби (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)

У Alertmanager включіть route для алерта'Watchdog'( завжди firing) → якщо оповіщення не приходить - моніторинг зламаний.

7) Приклади PromQL для аптайма

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) Алертінг: пороги і анти-шум

Multi-region quorum: спрацьовує, якщо ≥2 регіонів бачать падіння.
Multi-window: 1-5 хв (швидкий канал) + 30-60 хв (стійкий тренд).
Чутливість: debounce/for: 2-5 хвилин проти флапінгу.
Кореляція: зв'язуйте аптайм-алерт з лейєр-метриками (edge, DNS, WAF, origin).
Maintenance windows: придушення алертів за тегами'maintenance = true'.

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

9) Багато-регіонні і багато-вендорні перевірки

Мінімум 3 географії (EU/NA/APAC) і різні ASN.
Продублюйте: власні проби + зовнішній аптайм-провайдер.
IPv4/IPv6, HTTP/2/3, різні CDN РОР'и і WAF-профілі.

10) Безпека перевірок

Allowlist IP діапазонів проб на WAF/LB.
Rate-limits і капча-байпас для ендпоінтів health/проб.
Підпис заголовків (HMAC) для приватних health.
Роздільні домени: публічні проби і приватні (/internal/health).
Не повертайте внутрішні версії/конфіги в/healthz; тільки статуси.

11) SLO та звітність по аптайму

SLI Availability: частка успішних HTTP-проб 2xx/3xx.
SLO приклад: ≥ 99. 95% за 28 днів по більшості регіонів.
Помилковий бюджет: '1 − SLO'→ управляє релізами.
Burn-rate алерти: швидкий/повільний канал для частки провалів проб.

12) Heartbeat для платіжних і критичних джоб

Джоби «навколо грошей» (трансфери, реєстри) - подвійний контроль: heartbeat + бізнес-лічильники (скільки записів оброблено).
Алерти по «тиші» (немає нових подій> N хвилин) і по лагу (відставання від real-time).

13) Статус-сторінки

Розділяйте компоненти (API, платежі, бекенди, CDN).
Автоматичні апдейти з алертів, ручні коментарі через Comms-роль.
Історія інцидентів, постмортем-посилання, заплановані роботи.

14) Інтеграція з інцидент-процесом

Алерт SEV за правилами quorum + тривалість.
Auto-створення картки інциденту, war-room, призначення IC.
Шаблони комунікацій (внутрішні/зовнішні), Legal Hold при необхідності.
Пост-верифікація: синтетика зелена ≥ X хвилин до «Resolved».

15) Продуктивність і вартість

Частота проб: критичні - кожну 30-60с; вторинні - 1-5 хв.
Зберігання: downsampling/recording rules для довгих вікон.
Бюджет зовнішніх провайдерів: обмежте просунуті браузерні сценарії за розкладом.

16) Чек-лист якості

• Є/healthz ,/readyz ,/startupz з чіткою семантикою.
• Проби з ≥3 регіонів/ASN, IPv4/IPv6.
• TLS/DNS перевірки і алерти T-30/T-7/T-1 днів.
• Heartbeat всіх критичних джоб (і бізнес- «тиша»).
• Multi-window + quorum, без флапінгу.
• Drilldown: кнопки до логів/трас/дашбордів.
• Статус-сторінка і шаблони комунікацій.
• Документація SLO/метрик і власників.

17) План впровадження (3 ітерації)

1. Тиждень 1: blackbox-проби HTTP/TLS/DNS по критичних доменах, статус-сторінка, базові алерти.
2. Тиждень 2: багато-регіонність, quorum-правила, heartbeat топ-джоб, Watchdog.
3. Тиждень 3: headless-сценарії (login/deposit), звітність SLO, інтеграція з інцидент-процесом.

18) Міні-FAQ

Чим зовнішні проби краще внутрішніх?
Зовнішні бачать реальний шлях користувача (DNS/CDN/WAF), внутрішні - стан origin. Потрібні обидва.

Чи потрібно перевіряти платні PSP?
Так: синтетика в sandbox і моніторинг статус-сторінок; при деградації - автоматичний smart-routing.

Як зменшити шум?
Quorum, multi-window, for-затримка, suppression на maintenance, чіткі SLO-пороги і володіння.

Підсумок

Аптайм-моніторинг - це не тільки пінг. Це система: багато-регіонні синтетики + якісні health-ендпоінти + heartbeat джоб + SLO/алертинг + статус-сторінки. Стандартизуйте перевірки, знижуйте шум, захищайте проби і пов'язуйте все з інцидент-процесом - так ви зменшите MTTR і збережіть помилковий бюджет.