Мониторинг аптайма и 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/`.
• 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 POP’ы и 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 и сохраните ошибочный бюджет.