Сигналы
Рекомендации по проектированию сценариев обработки событий и генерации Сигналов
Доступные примеры сценариев обработки событий
Проектирование сценария
Добавление сценария
В данном разделе документации рассматриваются общие принципы и инструменты обработки событий в Сигналы функционалом Автоматизации.
Рекомендации по проектированию сценариев обработки событий и генерации Сигналов
Вот несколько общих рекомендаций, которые помогут разработать сценарий автоматизации для работы с Сигналами:
-
Изучите первичные события от источника данных. Для закладывания корректной логики работы алгоритма необходимо понимать входные данные. Это позволит избежать возможных ошибок в работе сценария, когда, например, в функцию попадает значение, тип которого она не способна корректно обработать.
- Какие в событии поля обязательны?
- Какие опциональны?
- Какие значения могут принимать?
- Могут ли быть вложенные сообщения и потребуется ли обрабатывать единичные объекты и/или массивы?
- Есть ли в событии идентификаторы, позволяющие связать событие с конкретной КЕ?
-
Изучите или разработайте требования к работе с сигналами конечными пользователями. Необходимо отв етить на вопросы:
- Сигналы должны закрываться только оператором или это может делать автоматика?
- Для закрытия обязательно ли ожидание подтверждающих событий и есть ли они? Или допустимо закрытие через какой-то период времени?
- Нужно ли сигнал помечать какими-либо тегами для их дальнейшей фильтрации или составления отчетности?
- Должна ли выполняться какая-то корреляция по открытым сигналам?
- Есть ли события, которые должны игнорироваться?
- Предполагается ли какая-то автоматизация через бизнес-процессы? Возможно для этого в сигнале потребуется какая-то мета-информация и при их открытии Сигнал необходимо обогатить какими-либо данными (например, из связанной КЕ)?
-
Оцените требования к нагрузке. Необходимо понимать какое количество событий в единицу времени предполагается обрабатывать и сообщения какого размера будут подаваться на вход сценария. Требования к нагрузке позволят определить какие функции автоматизации стоит использовать: необходимы ли batch функции или они не обязательны.
-
Составление схемы. Перед непосредственной разработкой сценария будет полезно задокументировать в схематичном виде шаги сценария (Visio, PowerPoint и др.). Это поможет выявить до начала разработки возможные развилки сценария и предусмотреть их корректное разрешение. А также при необходимости доработки сценария иметь отправную точку от "AS IS" на пути к новому "TO BE".
-
Проведите негативное тестирование сценария. Подайте недопустимые входные данные, чтобы посмотреть, как сценарий справится с этими данными. Это позволит выявить все ли возможные ошибки будут корректно обработаны и в том числе не "уйдет ли сценарий в цикл?".
-
Проведите нагрузочное тестирование. Справляется ли сценарий с постующей нагрузкой? Накапливаются ли очереди? Устраивает ли вас время выполнения полученного сценария? Если ответ на один из вопросов выше "Да", то сценарий необходимо оптимизировать (рассмотреть использование batch-функций, кеширование части данных) или спланировать увеличивать количества обработчкиков. Также стоит обратить внимание на потребление памяти обработчиком при выполнении сценария - есть ли риски возникновения OOM?
-
Соберите обратную связь от конечных пользователей. Достаточно ли данных о проблеме в Сигнале? Нет ли дублирующих или проущенных событий и лишнего шума? Что можно улучшить?
Доступные примеры сценариев обработки событий
В качестве дополнительного контента, команда разработчиков предоставляет доступ к типовым сценариям обработки первичных событий.
Все сценарии доступны в публичном репозитории Monq на платформе GitHub
Проектирование сценария
Давайте рассмотрим следующий алгоритм обработки событий в Сигналы и создадим по нему наш сц енарий:
- Первичное событие - анализируем, что есть у нас на входе сценария и с какими данными предстоит работать
- Фильтрация событий по потоку данных и определение переменных - отбрасываем лишние события из сценария, которые могут вызввать ошибки в работе сценария из-за отличающейся структуры первичного события. А также определяем переменные для удобства работы со сценарием на холсте.
- Поиск открытых сигналов по первичному событию - производим базовую дедупликацию событий, схлопывая повторяющиеся события в одном Сигнале
- Есть от крытый сигнал? - определяем дальнейший ход в сценарии (создание/закрытие/подтверждение)
Далее перейдем к добавлению сценария в системе.
Перед непосредственным созданием вашего первого сценария обработки событий рекомендуется ознакомиться с терминологией и общими понятиями о функционале Автоматизации:
Добавление сценария
-
Перейдите через основное меню в раздел Автоматизация - Сценарии - откроется экран управления сценариями.
-
Для добавления в систему нового сценария нажмите кнопку ➕ Создать сценарий в правом верхнем углу экрана.
-
Заполните основные параметры создаваемого сценария:
- Владелец сценария - Рабочая группа, которой будет принадлежать сценарий.
- Название - логически понятное название сценария.
- Тип - Signals Processor.
- Описание (опционально).
- Импорт сценария (опционально).
-
Нажмите кнопку Создать - сценарий будет создан и откроется конструктор сценария.
-
Каждый сценарий начинает работу с События запуска - блока
OnLogEvent
,
автоматически добавляемого при создании каждого сценария.- Удалить или изменить блок
OnLogEvent
нельзя. - В исходящем пине
Value
блокаOnLogEvent
содержится значение того самого события, которое мы рассматриваем
- Удалить или изменить блок
Пример события из Prometheus
Перед созданием любого сценария обработки первичных событий, нужно ознакомится с телом этого события. Рассмотрим модель события из "Prometheus Alert Manager":
{
"status": "firing",
"labels": {
"alertname": "KubeDaemonSetNotScheduled",
"container": "kube-state-metrics",
"daemonset": "fluent-bit",
"instance": "10.244.4.75:8080",
"job": "kube-state-metrics",
"namespace": "kube-system",
"prometheus": "monitoring/k8s",
"severity": "warning"
},
"annotations": {
"description": "3 Pods of DaemonSet kube-system/fluent-bit are not scheduled.",
"runbook_url": "https://runbooks.prometheus-operator.dev/runbooks/kubernetes/kubedaemonsetnotscheduled",
"summary": "DaemonSet pods are not scheduled."
},
"startsAt": "2024-02-01T05:48:08.4Z",
"endsAt": "0001-01-01T00:00:00Z",
"generatorURL": "http://prometheus-k8s-0:9090/graph?g0.expr=kube_daemonset_status_desired_number_scheduled%7Bjob%3D%22kube-state-metrics%22%7D+-+kube_daemonset_status_current_number_scheduled%7Bjob%3D%22kube-state-metrics%22%7D+%3E+0&g0.tab=1",
"fingerprint": "f96a727d3fa9501d"
}
Сп ерва нужно проанализировать содержимое события и понять, какие данные из него нам понадобятся. Давайте рассмотрим из каких же полей состоит данное событие:
status
- информация о статусе события, произошел какой-то сбой или наоборот восстановилась работа какого-либо сервиса. Возможные значения:firing
- авария,resolved
- восстановление.labels
- объект содержащий метки, переданные в событие из метрики. Набор меток может быть произвольным, но должен как минимум иметь набор меток для осуществления привязки к КЕ (например:daemonset
иnamespace
). А также полеseverity
, отражающее важность данного события.annotations
- объект содержащий аннотации из правила Alert Manager.startsAt
- время начала аварии.endsAt
- время восстановления. Содержит информацию только, еслиstatus
=resolved
.generatorURL
- ссылка на информацию с сырыми данными в Prometheus.fingerprint
- "отпечаток пальца", он же идентификатор события об аварии.
Проанализировав информацию, содержащуюся в событии, можно сделать вывод, что нам в первую очередь потребуются поля:
status
- в зависимости от значения данного поля мы будем понимать, что нам делать с сигналом - "открывать или закрывать?"fingerprint
- данное поле позволит нам осуществить дедупликацию событий и найти уже имеющийся сигнал в системе, если он естьlabels.severity
- поле, которое дает нам понять, сигнал какой критичность нужно открытьlabels.namespace
иlabels.daemonset
- поля, которые будем использовать для поиска конфигурационных единицannotations.description
- используем для указания названия сигнала
Следующим действием необходимо произвести фильтрацию поступающих событий в наш сценарий.