RCA-агент поверх Zabbix + Loki: где он ошибается и почему мы его не отключаем

Разговоры про «AI для дежурного» шли давно, но большинство предложений на рынке сводилось к: вот красивый дашборд, вот аномалия, разберитесь сами. Automated root cause analysis - это другое. Агент не просто сигнализирует, он пытается ответить на вопрос «почему». Несколько AIOps-платформ уже заявляют это как продуктовую фичу, и мы решили не ждать готового продукта, а собрать небольшой агент самостоятельно - поверх стека, который у нас и так есть.

Как устроен агент

Стек у нас стандартный для большинства наших клиентов: Zabbix как основной источник алертов, Loki для хранения логов, Grafana как фронт. К этому мы добавили LLM-агента - Python-скрипт, который получает вебхук от Zabbix при срабатывании алерта и дальше работает самостоятельно.

Цикл выглядит так:

1. Zabbix стреляет алерт - триггер сработал, хост известен, метрика известна.
2. Агент получает вебхук, извлекает имя хоста, метрику и время срабатывания.
3. Агент идёт в Loki API с LogQL-запросом: логи по хосту за 15 минут до момента алерта. Берёт всё - systemd, application, nginx, postgresql - фильтрует по уровню warn и выше.
4. Агент идёт в Zabbix API и забирает историю метрик по хосту за то же окно: CPU, память, disk I/O, сетевые счётчики.
5. Собранный контекст - метрики + логи + описание триггера - упаковывается в промпт и отправляется в LLM.
6. Ответ агента пишется в комментарий к проблеме в Zabbix и дублируется в Mattermost-канал дежурного.

Агент не принимает никаких автоматических действий - только анализирует и пишет. Это осознанное решение: сначала проверить, насколько хорошо он вообще диагностирует.

Где агент ошибается

Честно: ошибается регулярно. Но ошибки разного качества, и это важно.

Ложные корреляции по времени. Если в 15-минутном окне есть несколько событий - допустим, плановый cron в 03:00 и сбой сервиса в 03:02, - агент иногда называет cron причиной сбоя. Он видит, что cron был раньше, и строит гипотезу. Иногда это правда, иногда совпадение. Дежурный это знает, агент - нет.

Контекст без инфраструктурной карты. Агент не знает топологии. Он видит, что на хосте db-replica-2 выросла задержка репликации, и честно пишет: «вероятно, проблема с сетью или нагрузкой на источник». Но он не знает, что db-replica-2 реплицируется с db-primary-1, и не идёт туда проверять. Связи между хостами для него невидимы.

Избыточная уверенность в формулировках. LLM пишет «основная причина - исчерпание файловых дескрипторов» даже когда логи содержат только косвенные намёки, а не явное Too many open files. Это не ложь - это особенность языковой модели, которая предпочитает уверенный ответ размытому. Дежурный научился смотреть не только на вывод, но и на то, что именно агент процитировал из логов.

Шум в логах перегружает контекст. Некоторые сервисы пишут предупреждения при каждом запросе - это норма для конкретного приложения, но агент воспринимает их как сигнал и строит вокруг них гипотезу. Пришлось добавить стоп-список шаблонов для LogQL - мусор теперь вырезается до отправки в LLM.

Почему мы его не отключаем

При всех ошибках агент делает одну очень конкретную вещь: он собирает контекст за 15 минут до алерта и укладывает его в читаемый текст быстрее, чем дежурный успевает открыть Grafana.

Раньше первые несколько минут дежурного уходили на ориентирование: что за хост, что за метрика, что было в логах, есть ли смежные проблемы. Это небыстро, особенно в два часа ночи. Сейчас агент уже написал в Mattermost что-то вроде: «За 12 минут до алерта на хосте появились ошибки подключения к Redis, затем рост latency на эндпоинте /api/cart. Вероятная причина - недоступность Redis.» Иногда это точно. Иногда нет. Но в обоих случаях дежурный уже знает, куда смотреть первым делом.

Это не замена диагностике - это сокращение времени до первой осмысленной гипотезы.

Что мы поменяли после первых недель

Несколько уроков, которые стоили нам нескольких ложных диагнозов:

• Окно 15 минут иногда мало, иногда много. Для медленных деградаций полчаса лучше. Для flash-инцидентов достаточно пяти. Сделали параметр в зависимости от категории алерта.

• Промпт с явным запретом на уверенность. Добавили в системный промпт инструкцию: если данных недостаточно для однозначного вывода - говорить «вероятно» и перечислять гипотезы списком. Не идеально работает, но стало заметно аккуратнее.

• Ссылки на источники. Просим агента цитировать конкретные строки из логов, на которых основан вывод. Это помогает дежурному сразу оценить, насколько серьёзна доказательная база. Без этого агент звучал убедительнее, чем заслуживал.

Задача дать агенту видимость топологии - подключить cmdb или хотя бы статический граф зависимостей хостов - на нашем листе. Это должно убрать большую часть ложных корреляций. Сейчас это открытый вопрос, потому что нормальной актуальной cmdb у заказчика нет, а поддерживать статический граф вручную - отдельная работа.

Но и в нынешнем виде агент работает. Дежурный привык к его ошибкам и знает, как с ними обращаться. Это, наверное, честный итог для первых недель эксплуатации.