Интеграция с RMON#

IncidentRelay может принимать алерты от RMON через отдельную входящую интеграцию. RMON отправляет каждый алерт в IncidentRelay с токеном приёма маршрута, а IncidentRelay обрабатывает его через стандартный конвейер маршрутизации, группировки, подавления, уведомления, эскалации и трассировки объяснения.

Эндпоинт#

КопироватьPOST /api/integrations/rmon

Эндпоинт требует токен приёма активного маршрута IncidentRelay, источником которого является rmon.

КопироватьAuthorization: Bearer <route-intake-token>
Content-Type: application/json

Создание маршрута IncidentRelay#

• Откройте Routes в IncidentRelay.
• Создайте маршрут или отредактируйте существующий.
• Выберите RMON в качестве источника.
• Выберите команду, которой принадлежат алерты.
• Настройте матчеры маршрута.
• Настройте группировку.
• Выберите политику ротации или эскалации.
• Убедитесь, что маршрут активен.
• Скопируйте токен приёма маршрута.

Рекомендуемая группировка:

Копировать[
  "rmon_check_id",
  "rmon_check_type"
]

Пример матчеров:

Копировать{
  "environment": "production",
  "rmon_region": "eu-west"
}

Используйте для группировки только стабильные метки. Не группируйте по значениям, которые меняются между повторными выполнениями одной и той же проверки.

Настройка RMON#

В канале IncidentRelay в RMON задайте:

КопироватьChannel name: https://incidentrelay.example.com
Token: <route-intake-token>

URL канала должен содержать только базовый URL IncidentRelay. RMON автоматически добавляет путь интеграции:

Копировать/api/integrations/rmon

Не помещайте токен в URL.

Жизненный цикл алерта#

RMON отправляет:

Копироватьfiring

для активных сбоев и:

Копироватьresolved

для событий восстановления.

IncidentRelay обновляет существующий алерт, когда уведомления firing и resolved используют один и тот же fingerprint.

Значения, похожие на resolved, такие как перечисленные ниже, также нормализуются в resolved:

Копироватьclear
cleared
closed
info
normal
ok
recover
recovered
resolved
up

Остальные значения трактуются как firing.

Поля полезной нагрузки#

Обязательное поле#

Идентичность алерта#

Контекст проверки#

Маршрутизация и группировка#

Runbook и ссылки#

Дополнительные поля принимаются и сохраняются в сохранённой полезной нагрузке.

Нормализованные метки#

IncidentRelay добавляет следующие метки при наличии соответствующих значений:

Существующие метки, предоставленные RMON, сохраняются.

Выбор команды#

IncidentRelay выбирает опциональную подсказку команды из первого доступного значения:

• team верхнего уровня;
• labels.team;
• labels.oncall_team.

Приоритет остаётся за маршрутом. Подсказка команды не обходит проверки токена маршрута, источника, матчеров или доступа.

Важность#

IncidentRelay выбирает важность из:

• severity верхнего уровня;
• labels.severity;
• warning.

Дедупликация#

Когда fingerprint присутствует и валиден, IncidentRelay использует его в качестве ключа дедупликации.

Значения, подобные перечисленным ниже, игнорируются:

КопироватьNone
null
None None
null null

Когда валидный fingerprint недоступен, IncidentRelay генерирует стабильный ключ из:

• источника rmon;
• внешнего идентификатора или идентификатора проверки;
• заголовка;
• нормализованных меток.

RMON должен сохранять один и тот же fingerprint между уведомлениями firing и восстановления для одного логического сбоя проверки.

Пример полезной нагрузки#

Копировать{
  "title": "[rmon-production] critical: HTTP check failed",
  "message": "critical: HTTP check failed",
  "severity": "critical",
  "status": "firing",
  "fingerprint": "42 7",
  "external_id": 42,
  "rmon_name": "rmon-production",
  "multi_check_id": 42,
  "state_id": 7,
  "check_name": "Public API",
  "check_type": "http",
  "target": "https://api.example.com/health",
  "agent": "eu-west-agent",
  "region": "eu-west",
  "country": "DE",
  "runbook_url": "https://example.com/runbooks/public-api",
  "labels": {
    "team": "sre",
    "environment": "production"
  }
}

Ручной тест#

Сохраните пример полезной нагрузки как rmon-payload.json и выполните:

Копироватьcurl -X POST   "https://incidentrelay.example.com/api/integrations/rmon"   -H "Authorization: Bearer ROUTE_INTAKE_TOKEN"   -H "Content-Type: application/json"   --data-binary @rmon-payload.json

Успешный ответ содержит один результат приёма:

Копировать[
  {
    "created": true,
    "alert_id": 123,
    "group_id": 45,
    "status": "firing",
    "team_id": 2,
    "team_slug": "sre",
    "route_id": 7,
    "routing_error": null,
    "trace_id": "..."
  }
]

HTTP-ответы#

Ответ при сбое маршрутизации включает trace_id. Администраторы могут изучить трассировку объяснения, чтобы увидеть вычисление матчеров маршрута и точную причину сбоя.

Устранение неполадок#

Требуется токен приёма маршрута#

RMON не отправил bearer-токен, или токен канала пуст.

Проверьте конфигурацию канала RMON:

КопироватьToken: <route-intake-token>

Алерт не сопоставился ни с одним активным маршрутом#

Проверьте, что:

• маршрут активен;
• источник маршрута — rmon;
• токен принадлежит этому маршруту;
• каждый настроенный матчер совпадает с полученными метками;
• команда активна;
• у маршрута есть политика ротации или эскалации.

Используйте возвращённый trace_id для проверки маршрутизации.

Восстановление создаёт ещё один алерт#

Убедитесь, что для уведомлений firing и resolved отправляется один и тот же fingerprint.

Fingerprint должен идентифицировать логический сбой проверки и не должен содержать меняющихся временных меток или случайных значений.

Алерты от разных проверок объединяются#

Используйте fingerprint, содержащий идентификатор проверки и идентификатор состояния, либо другую стабильную комбинацию, уникальную для логического события проверки.

Рекомендуемый пример:

Копировать<multi_check_id> <state_id>

Отсутствует ссылка на runbook#

Задайте в runbook_url абсолютный URL http:// или https://. Значение runbook, не являющееся URL, остаётся доступным в сохранённой полезной нагрузке, но не используется как кликабельная ссылка на событие.

Тестовое уведомление ведёт себя иначе#

Тестовые уведомления могут не содержать state_id, метаданные проверки или production-метки. IncidentRelay генерирует запасной ключ дедупликации, когда в тестовой полезной нагрузке нет валидного fingerprint.

Сравните метки, показанные в трассировке объяснения, с матчерами маршрута.

Безопасность#

• Используйте HTTPS.
• Держите токен приёма маршрута в секрете.
• Используйте отдельный токен маршрута для каждого инстанса RMON или границы доверия.
• Немедленно ротируйте раскрытые токены.
• Не отправляйте токен внутри полезной нагрузки JSON.
• Не помещайте токен в URL.
• Ограничивайте матчеры маршрута ожидаемыми метками RMON.