nxs‑anomaly: open‑source инструмент для алертинга и дежурств

[Rawiiw]

Благодарю за статью, хороший инструмент для алертинга!
Вопрос: а как вы рекомендуете мониторить сам nxs-anomaly? Если упадёт API, worker или PostgreSQL, основной канал оповещения тоже перестанет работать. Предусмотрен ли внешний heartbeat/blackbox-check либо резервный канал, не зависящий от nxs-anomaly? Не нашла в статье информацию

[RukInDaHouse]

Спасибо за отличный вопрос. С версии 1.3.0 предусмотрен внешний heartbeat и отдельный набор алертов «процесс отсутствует». Мы рекомендуем три независимых уровня контроля:

• Heartbeat прямо от воркера, без Prometheus: задаётся переменная NXS_ANOMALY_WORKER_HEARTBEAT_URL, туда подходит адрес проверки во внешнем сервисе, например healthchecks.io. После каждого успешного цикла, воркер делает GET на этот адрес, но не чаще раза в минуту. Если цикл упал из-за базы, пинга не будет. Поэтому одна такая проверка ловит падение воркера, недоступность PostgreSQL и обрыв сети между ними.

• Prometheus-алерты на отсутствие процесса, а не на его деградацию. Правила лежат в prometheus-rules.yaml. В Helm они включаются через prometheusRule.enabled и serviceMonitor.enabled.

• Отдельная маршрутизация в Alertmanager: эти алерты отправляются отдельным ресивером напрямую, в Telegram, почту или SMS, а не в nxs-anomaly.

Также у API и воркера есть эндпоинты /live и /ready. На воркерае это порт NXS_ANOMALY_WORKER_ADDR, по умолчанию :8081. /ready воркера отвечает 503, если пропал доступ к БД или цикл не завершался дольше допустимого окна. Эти адреса можно проверять через blackbox_exporter или внешний uptime-монитор.