Generalized Message Exchange (GMX)

В рамках работ над #1366 (closed) пришли к выводу, что можно реализовать обобщенный механизм, который может покрыть как потребности будущего Realtime Data Pumping, так и уже существующий функционал отправки сообщений через Notification Group.

Message

Основой механизма является абстрактное сообщение (Message). Сообщение возникает внутри системы и несет полезную информацию получателям за пределами системы. При этом, генератор сообщений не обязательно знает о способах его доставки получателям.

Message Type

Сообщения типизированы. Тип сообщения определяется генератором сообщения. Возможные типы сообщений:

• авария
• инвентарные данные по объекту
• конфиг
• изменение конфига
• перезагрузка
• новая железка
• вход в систему
• итд.

Настройка генерации сообщений

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

message:
  enable_config: true
  enable_config_diff: true
  enable_alarm: ...

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

Передача сообщения

Генератор передает сообщения в поток liftbridge message. В payload передается тело сообщения в машинно-читаемом виде (JSON). Помимо тела сообщения генератор добавляет дополнительные заголовки (Header), которые могут использоваться для маршрутизации сообщения.

Возможные заголовки:

• Message-Type - тип сообщения
• Sharding-Key - ключ шардирования
• Administrative-Domain-ID
• Object-Profile-ID
• ...

В случае, если поток message содержит несколько партиций, генератор отправляет сообщение в партицию

partition = K_{sharding} \mod N_{partitions}

Message Exchanger (MX)

Вводится сервис mx, которые подписывается поток message. Партиция выбирается из номера слота. mx выполняет следующие действия:

• Читает сообщение
• Анализирует header'ы по таблице маршрутизации
• Применяет правила согласно таблице маршрутизации

Таблица маршрутизации

Хранится в коллекции MessageRoute и имеет вид:

• name - название правила
• is_active - признак активности
• description - описание
• order - порядок сообщения
• type - Заголовок Message-Type
• match - правила совпадения в виде набора правил (принцип AND). Список:
  • header - заголовок
  • value - значение
• match_handler - handler (см. далее)
• match_expr - выражение для совпадения (см. далее)
• mutation - правило преобразования
  • None - не изменять сообщени
  • Template - применить шаблон и сгенерировать текст
  • handler - применить handler
• route - список получателей
  • notification_group - группа уведомления
  • stream - имя потока liftbridge для получателя (может содержать макросы)
  • headers - список заголовков для отправки (может содержать макросы)

Развертывание Notification Group

Добавляем метод NotificationGroup.iter_routes, генерирующий пары (<stream>, {Headers: ...}). В случае, если notification group заполнена, stream и headers генерируются автоматически. Если headers уже заданы, они добавляются к сгенерированым, при совпадении - перекрывают сгенерированные.

*sender

Сервисы типа *sender (mailsender, tgsender, ...) принимают сообщения и используют данные в header'ах для определения получателя сообщений. Заголовки могут быть специфичны для каждого сендера. Возможные типы сендеров:

• mailsender - отправка почты по протоколу SMTP
• tgsender - отправка сообщения в telegram
• icqsender - отправка сообщения в icq
• ttsender - создание/закрытие ТТ
• kafkasender - отправка данных в Kafka
• websender - отправка HTTP-сообщений