Документация

Heartbeats

Версия v2.3.1 · Обновлено

Heartbeats#

Heartbeats — это проверки типа «выключатель мёртвого человека» (dead-man-switch). Они поднимают тревогу, когда ожидаемый ping об успехе перестаёт приходить.

В отличие от активной проверки HTTP/TCP, heartbeat подтверждает, что производящая система смогла завершить собственную работу и доставить сигнал в IncidentRelay. Это полезно для мониторинга путей, которые нельзя надёжно проверить извне IncidentRelay:

  • Prometheus Watchdog через Alertmanager;
  • задания резервного копирования, которые должны завершаться каждую ночь;
  • ETL-конвейеры, которые должны отправлять маркер успешного завершения;
  • сборщики логов или агенты, которые должны периодически отчитываться;
  • любой cron- или пакетный процесс, где режимом отказа является молчание.

Режимы#

IncidentRelay поддерживает два режима heartbeat.

Ping по интервалу#

Источник должен пинговать IncidentRelay через каждый фиксированный интервал. IncidentRelay помечает heartbeat как просроченный, когда:

last_seen_at + expected_interval + grace_period < now

Это лучше всего подходит для алертов в стиле Watchdog и для непрерывно работающих агентов.

Завершение по расписанию#

Источник должен пинговать IncidentRelay до запланированного крайнего срока, например каждый день в 03:00 или каждый понедельник в 08:00. Это лучше всего подходит для заданий ETL, резервного копирования, биллинга и отчётности.

Heartbeat по расписанию считается просроченным, когда текущее ожидаемое окно прошло, а успешный ping для этого окна не был получен.

Поведение алертов#

Когда heartbeat становится просроченным, IncidentRelay создаёт обычную группу алертов с:

source = heartbeat
alertname = HeartbeatOverdue
dedup_key = heartbeat:<uid>

Алерт проходит через обычный конвейер IR: маршрут, приоритет, эскалация, уведомление, обслуживание и влияние на сервис. Когда ping возвращается, IncidentRelay может автоматически разрешить текущий просроченный алерт.

Маршруты#

Heartbeats используют маршруты с источником heartbeat. Это сохраняет поведение доставки согласованным с другими алертами IR: маршрут решает, какие каналы уведомлений, политику ротации или эскалации использовать, а также опциональные allow-списки матчеров.

URL для ping#

Каждый heartbeat имеет секретный токен и URL для ping:

GET  /api/heartbeats/ping/<token>
POST /api/heartbeats/ping/<token>

Токен показывается только при создании или регенерации heartbeat. Храните его в производящей системе, а не в документации или системе контроля версий.

Пример:

curl -fsS https://incidentrelay.example.com/api/heartbeats/ping/<token>

Для ETL-заданий отправляйте ping только после успешного завершения и проверок качества данных.

Многоэкземплярные heartbeats и автообнаружение#

Для флотов, где один и тот же cronjob запускается на многих серверах, не используйте один плоский heartbeat без ключа экземпляра. Один здоровый сервер удерживал бы heartbeat зелёным, пока другие серверы молча перестали бы отчитываться.

Включите Track instances / auto-discovery и отправляйте идентификатор экземпляра с каждым ping:

curl -fsS -X POST https://incidentrelay.example.com/api/heartbeats/ping/<token> \
  -H 'Content-Type: application/json' \
  -d '{
    "status": "completed",
    "instance": "server-1.example.com",
    "payload": {
      "job": "mysql-backup"
    }
  }'

Затем IncidentRelay отслеживает каждого производителя независимо:

mysql-backup
  server-1.example.com  OK
  server-2.example.com  OK
  server-3.example.com  OVERDUE

Когда один экземпляр просрочен, IR создаёт обычный алерт с:

alertname = HeartbeatInstanceOverdue
dedup_key = heartbeat:<uid>:instance:<instance>
labels.instance = <instance>
labels.heartbeat_instance = <instance>

Если экземпляр снова пингует и включено автоматическое разрешение, алерт этого экземпляра разрешается, не затрагивая другие экземпляры.

Режимы ожидаемых экземпляров#

Режим auto обнаруживает новый экземпляр при первом успешном ping и с этого момента ожидает его. Здоровые автообнаруженные экземпляры могут быть автоматически отключены после настроенного TTL, если они долго не отчитываются и не имеют активного просроченного алерта.

Режим static принимает только настроенный список экземпляров. Он строже и лучше подходит, когда состав флота управляется через инвентарь, Ansible или Terraform.