mirror of
https://gitverse.ru/kpa39l/monitoring.git
synced 2026-09-29 01:50:07 +00:00
3.8 KiB
3.8 KiB
Design
Механизм алертов
В стеке /opt/monitoring алерты реализованы Prometheus Alerting rules (prometheus.yml
rule_files: /etc/prometheus/alerts.yml, Prometheus 3.1+ встроенный алертинг с мульти-секционной
группировкой groups:/rules:). Формат rules (алерты на базе PromQL-выражений с for = время
удержания условия, labels.severity, annotations.summary). Доставка уведомлений — согласно
существующей конфигурации (webhook/канал, настроенный в Prometheus или в той же alerts.yml
внешним получателем — проверить фактический механизм доставки в стеке; в референсах скилла
указано, что уведомления приходят в чат).
Метрики VESTI (textfile-коллектор, job node, label component="vesti")
| Метрика | Смысл | Алерт |
|---|---|---|
| vesti_web_up | web :8400 (systemd) | ==0 → critical |
| vesti_publisher_health | publisher :8410 /healthz | ==0 → critical |
| vesti_publisher_docker | контейнер publisher (docker ps) | ==0 → critical |
| vesti_telegram_tunnel | SOCKS5-туннель :1080 | ==0 → critical |
| vesti_db_ok | SQLite vesti.db доступна | ==0 → critical |
| vesti_db_last_run_ts | Unix-ts последнего рan краулера | time()-ts >1800 → warning |
Формат rules (из alerts.yml)
groups:
- name: vesti
rules:
- alert: VestiWebDown
expr: vesti_web_up{component="vesti"} == 0
for: 2m
labels:
severity: critical
annotations:
summary: VESTI web (:8400) is down
Время реакции: for: 2m — алерт срабатывает после 2 минут непрерывного условия
(метрики обновляются раз в минуту скриптом vesti-metrics.sh → 2-3 пробы подряд).
Верификация
docker exec prometheus promtool check config /etc/prometheus/prometheus.yml→ OK (проверяет и rule_files).docker compose restart prometheus(перечитывает alerts.yml).- Запрос в Prometheus API: значения метрик vesti_* присутствуют.
- Проверка алертов: имитация (временно выставить метрику в 0, убедиться что алерт firing, вернуть обратно) — или проверка через Prometheus /api/v1/rules/дубликат.
- Обновить README.md + EXPERIENCE.md, openspec validate + archive.
Риски
- При
for: 2mи интервале скрипта 1 мин алерт может срабатывать с задержкой до 3 мин (приемлемо для внутреннего сервиса). - Метрики пишутся только при успешном выполнении скрипта; если textfile-файл пропадёт
(сломан скрипт) — метрики исчезнут и алерт по
==0не сработает. Для этого естьVestiDbStale(time() - ts) — он тоже покроет случай пропадания данных? Нет: если файл пропал, ts не обновится → last_run_ts останется старым → VestiDbStale сработает. Дополнительно можно добавить expr на отсутствие данных (deadman), но это выходит за рамки текущего change — зафиксировать в EXPERIENCE.md как известное ограничение.