kibana-alerting-rules

Официальный skill Elastic для проектирования и сопровождения правил Kibana Alerting через REST API и Terraform. Он раскладывает правило на три связанные части: условие, которое нужно обнаружить, расписание проверки и действия, выполняемые после срабатывания. Условие создаёт alert, а действие отправляет его через connector, поэтому при настройке важно одновременно понимать тип правила, группу действий и канал уведомлений. Skill подходит для правил Elasticsearch Query и Index Threshold, а также для lifecycle-операций: включения, отключения, общего или адресного mute, snooze и удаления. Он не заменяет документацию конкретного rule type: перед созданием рекомендуется запросить GET /api/alerting/rule_types и взять из ответа допустимые параметры, consumer и группы действий. REST API работает по базовому пути /api/alerting, а для Kibana Space путь расширяется префиксом /s/<space_id>. API принимает API key или Basic auth; каждый POST, PUT и DELETE должен содержать заголовок kbn-xsrf с truthy-значением, иначе Kibana возвращает 400. Для работы нужны all-привилегии соответствующего feature, например Stack Rules, Observability или Security, и read-доступ к Actions и Connectors. В POST создания обязательны name, rule_type_id, consumer, params и schedule; пример расписания задаётся интервалом 5m. Действия, tags, enabled, alert_delay и flapping являются дополнительными настройками. alert_delay с active: 3 позволяет дождаться трёх последовательных совпадений и не реагировать на краткий всплеск. При обновлении PUT нужно отправлять полное тело правила. Поля rule_type_id и consumer после создания неизменяемы: смена типа требует удалить правило и создать его заново. Если параллельное изменение приводит к 409 Conflict, сначала нужно получить актуальную версию и повторить операцию. API поддерживает поиск с пагинацией, сортировкой, поиском по имени и KQL-фильтрами, например по production-тегу. Отдельные endpoint доступны для health check, обновления API key и snooze schedule. Правило запускается от ключа пользователя, который его создал или последним обновил, поэтому изменение прав или удаление этого пользователя может нарушить выполнение; для переназначения предусмотрена операция _update_api_key. В Terraform используется ресурс elasticstack_kibana_alerting_rule. Параметры rule передаются как JSON-строка через jsonencode(), а connector для action берётся через ресурс или data source провайдера elasticstack. Существующие правила можно импортировать с пространством и идентификатором. В действиях frequency лучше задавать для каждого action отдельно: rule-level notify_when и throttle считаются устаревшими. onActionGroupChange подходит для paging и ticketing с парой active/recovered, onActiveAlert — для аудита, onThrottleInterval — для повторных уведомлений с ограничением частоты. Recovery action важен для автоматического закрытия инцидентов в PagerDuty, Jira или ServiceNow. Для production полезны интервал не короче рекомендованной минуты, flapping detection, последовательные tags и server.publicBaseUrl для корректных deep links в уведомлениях. Многохостовые правила с большим числом действий могут перегрузить Task Manager, а долгие запросы отменяются по timeout; лучше уменьшать объём запроса и использовать summaries. Workflow-действия отмечены в исходнике как preview-возможность Elastic Stack 9.3 и Elastic Cloud Serverless: workflow ID используется как connector ID, параметры могут быть пустыми, а alert context передаётся через event. Skill особенно полезен инженеру, который хочет держать алертинг в коде и одновременно контролировать права, пространства, частоту уведомлений, recovery и типичные ошибки API.