40 lines
4.5 KiB
Markdown
40 lines
4.5 KiB
Markdown
# IRM: функционал, назначение и реализация в onGuard24
|
||
|
||
Краткий ориентир для разработки (аналог облачного IRM: инциденты, задачи, эскалации, дежурства).
|
||
|
||
## Матрица: что это, зачем, как у нас, что в Grafana
|
||
|
||
| Область | Назначение | onGuard24 | Grafana / внешнее |
|
||
|---------|------------|-----------|-------------------|
|
||
| **Инциденты** | Учёт сбоев, статусы (open → resolved), связь с алертом | Модуль `incidents`: таблица `incidents`, API, UI, авто-создание из `alert.received` | Contact point **Webhook** → `POST /api/v1/ingress/grafana`; правила алертинга в Grafana |
|
||
| **Задачи** | Подзадачи по инциденту (разбор, фикс) | Модуль `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 |
|
||
|
||
## Поток данных (алерт → инцидент)
|
||
|
||
1. Grafana срабатывает правило → шлёт JSON на **webhook** onGuard24.
|
||
2. Сервис пишет строку в `ingress_events`, публикует **`alert.received`**.
|
||
3. Модуль **incidents** подписан на событие и создаёт запись в **`incidents`** с ссылкой на `ingress_event_id`.
|
||
|
||
## Что настроить в Grafana (обязательно для приёма алертов)
|
||
|
||
### Один URL для всех инстансов и организаций
|
||
|
||
1. **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`).
|
||
2. В **`grafana.ini`** / настройках сервера корректно задайте **`root_url` / `external URL`**, чтобы в вебхук попадал нужный хост (за NPM — публичный URL).
|
||
3. Опционально **`X-OnGuard-Secret`** (если задан **`GRAFANA_WEBHOOK_SECRET`**) и **`X-OnGuard-Service`** (имя сервиса в инциденте).
|
||
4. **Notification policies** — привязать правила к contact point.
|
||
|
||
### Дополнительно: путь `/ingress/grafana/<slug>`
|
||
|
||
Явный ярлык в URL **не требует** записи в `GRAFANA_SOURCES_JSON`. **`GRAFANA_SOURCES_JSON`** нужен в основном для **`/api/v1/status`** (проверка API каждого инстанса) и для **отдельного `webhook_secret` на slug**.
|
||
|
||
Подробнее: [MODULES.md](MODULES.md), [DOMAIN.md](DOMAIN.md).
|