admin/onGuard24

Fork 0

Files

Alexandr a8ccf1d35c

Deploy / deploy (push) Has been cancelled

Details

CI / test (push) Successful in 37s

Details

release: v1.9.0 — IRM-алерты отдельно от инцидентов

- Alembic 005: таблицы irm_alerts и incident_alert_links
- Модуль alerts: API/UI, Ack/Resolve, привязка к инциденту через alert_ids
- Вебхук Grafana: одна транзакция ingress + irm_alerts; разбор payload в grafana_payload
- По умолчанию инцидент из вебхука не создаётся (AUTO_INCIDENT_FROM_ALERT)
- Документация IRM_GRAFANA_PARITY.md, обновления IRM.md и CHANGELOG

Made-with: Cursor

2026-04-03 15:26:38 +03:00

5.2 KiB

Raw Permalink Blame History

IRM: функционал, назначение и реализация в onGuard24

Краткий ориентир для разработки (аналог облачного IRM: инциденты, задачи, эскалации, дежурства).

Матрица: что это, зачем, как у нас, что в Grafana

Область	Назначение	onGuard24	Grafana / внешнее
Инциденты	Учёт сбоев, статусы (open → resolved), связь с алертами	Модуль `incidents`: `incidents`, `incident_alert_links`, API, UI; создание вручную или с `alert_ids`	См. Алерты; IRM_GRAFANA_PARITY.md
Алерты (IRM)	Приём, Ack/Resolve, не смешивать с инцидентом	Модуль `alerts`: `irm_alerts`, UI/API, вебхук пишет в одной транзакции с `ingress_events`	Grafana IRM Alert Groups; у нас без группировки/эскалации на уровне алерта
Задачи	Подзадачи по инциденту (разбор, фикс)	Модуль `tasks`: таблица `tasks`, привязка к `incident_id`	Опционально: ссылки из алерта; основная работа в onGuard24
Цепочки эскалаций	Кого звать и в каком порядке при таймаутах	Модуль `escalations`: таблица `escalation_policies` (JSON `steps`), API/UI заготовка	Маршрутизация уведомлений может дублироваться в Grafana contact points; целевая логика — в onGuard24
Календарь дежурств	Кто в смене, расписание	Модуль `schedules` (развитие)	Календари/команды — данные в onGuard24; уведомления — через интеграции
Контакты	Люди, каналы	Модуль `contacts`	Получатели в Contact points (email, Slack, webhook)
Светофор / статус сервисов	Агрегат здоровья	Модуль `statusboard`	Источник метрик — Prometheus/Loki; правила — Grafana
Группы алертов	Группировка шумных алертов	План: отдельная сущность / правила	Alertmanager / группировка в Grafana Alerting
Интеграции	Внешние системы	`integrations/`, статус в `/api/v1/status`	API-ключи Grafana, Vault, Forgejo в `.env`
Пользователи / права	RBAC	Пока нет	SSO Grafana, сеть за reverse proxy
SLO	Цели по доступности	Вне скоупа v1	Grafana SLO / Mimir

Поток данных (как в Grafana IRM)

Grafana срабатывает правило → JSON на webhook onGuard24.
В одной транзакции: ingress_events + irm_alerts (статус firing), публикуется alert.received.
Дежурный в модуле Алерты читает заголовок, лейблы, Acknowledge / Resolve — это не создание инцидента.
Инцидент создаётся отдельно (вручную или из карточки алерта), опционально с привязкой alert_ids. Авто-инцидент из вебхука только при AUTO_INCIDENT_FROM_ALERT=1 (legacy).

Что настроить в Grafana (обязательно для приёма алертов)

Один URL для всех инстансов и организаций

Contact point → Webhook, URL: https://<ваш-хост>/api/v1/ingress/grafana (POST). Не нужно заводить slug в .env: источник в БД определяется из JSON Grafana — externalURL (хост Grafana), при наличии orgId / org_id, иначе лейблы первого алерта (__org_id__, grafana_org, tenant, cluster, namespace).
В grafana.ini / настройках сервера корректно задайте root_url / external URL, чтобы в вебхук попадал нужный хост (за NPM — публичный URL).
Опционально X-OnGuard-Secret (если задан GRAFANA_WEBHOOK_SECRET) и X-OnGuard-Service (имя сервиса в инциденте).
Notification policies — привязать правила к contact point.

Дополнительно: путь `/ingress/grafana/<slug>`

Явный ярлык в URL не требует записи в GRAFANA_SOURCES_JSON. GRAFANA_SOURCES_JSON нужен в основном для /api/v1/status (проверка API каждого инстанса) и для отдельного webhook_secret на slug.

Подробнее: MODULES.md, DOMAIN.md.

5.2 KiB Raw Permalink Blame History Unescape Escape