Диагностика алертов Kubernetes агентом n8n через MCP-серверы
Автор с форума n8n собрал сценарий, в котором алерт из Alertmanager запускает ИИ-агента. Агент только читает данные Kubernetes, Grafana и других систем через MCP и пишет отчёт с гипотезами о причине в тред Mattermost.
Что сделали
Вебхук Alertmanager запускает сценарий в n8n. Сценарий убирает дубли алертов за 48 часов и забирает из Prometheus Rules API выражение PromQL, которое сработало. Затем ИИ-агент разбирается в проблеме через MCP-серверы Kubernetes, Grafana, DigitalOcean и GitHub, а также через хранилище Qdrant с внутренней документацией. Агент работает только на чтение. В конце сценарий находит исходный пост с алертом в Mattermost и отвечает в его треде.
Что получилось
Измеренных результатов в источнике нет. Автор описывает отчёт из краткой сводки, хронологии событий, не больше двух гипотез о первопричине и шагов для разбора. Он ещё думает о дополнительных источниках данных, например статистике базы и статусе пайплайнов.
На что обратить внимание
Чтобы агент не зацикливался, ограничьте повтор упавшего вызова инструмента одной попыткой. Шумные метки вроде job и instance из промпта лучше убрать. MCP-эндпоинты и доступы придётся настроить свои.
Кому пригодится
DevOps- и SRE-инженерам, которые хотят получать первичную диагностику алерта до того, как сами откроют дашборды.
Попробуйте сами с n8n
Сделай сценарий в n8n, который принимает вебхуки Alertmanager и запускает ИИ-агента, подключённого к моим MCP-серверам для [Kubernetes, Grafana, другие инструменты]. Агент разбирает алерт только в режиме чтения и публикует ответом в треде [канал Mattermost] диагностический отчёт с доказательствами и гипотезами о первопричине по убыванию вероятности. Готово, когда тестовый алерт даёт отчёт. Агент ничего не меняет в кластере, а перед первой публикацией покажи отчёт мне.
Нужна помощь с запуском? Вступайте в сообщество AI Pack ↗
Ещё 2 источника
Источник: community.n8n.io · · обновлено