Пайплайн Zabbix с локальной LLM и контролируемыми решениями

Локальная LLM может сделать уведомления Zabbix полезнее: отфильтровать часть шума, кратко объяснить контекст события и подготовить шаги первичной диагностики. Для такого контура важны границы ответственности. Модель хорошо работает как узкий компонент внутри заранее описанного процесса, где правила маршрутизации, формат данных и опасные действия контролирует приложение.

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

Сначала фиксируем контракт системы

До реализации полезно подготовить три уровня описания: требования к сервису, схему взаимодействия компонентов и детализацию модулей. В них следует определить, какие данные принимает webhook, какие поля становятся нормализованным событием, кто принимает решение о доставке и где хранится аудит.

Это ограничивает область каждой задачи. Например, alert-receiver принимает webhook Zabbix, проверяет токен, валидирует payload и создаёт нормализованное событие. Enrichment, корреляция, запрос к модели и отправка в Matrix или почту остаются за пределами этого компонента.

Для реализации отдельного модуля полезен короткий и конкретный контекст:

• назначение компонента и его входы;
• утверждённые технологии и интерфейсы;
• список обязательных операций;
• явно запрещённые зоны соседних модулей;
• ожидаемый формат результата.

Такой подход сохраняет архитектурные границы и упрощает ревью. Он также делает генерацию кода более предсказуемой: модель получает следующую небольшую задачу вместо большого запроса на весь сервис.

Разделяем приём событий и тяжёлую обработку

Webhook должен отвечать быстро. Анализ алерта локальной моделью может занять заметное время, особенно при нескольких одновременных событиях или ограниченных ресурсах хоста. Поэтому практичная схема выглядит так:

Zabbix -> receiver -> ingest/queue -> worker -> notifications + audit

receiver выполняет только критический минимум и передаёт событие во внутреннюю очередь, например Redis. Worker забирает его асинхронно, применяет политики, обогащает контекст, запускает триаж и формирует уведомление. Очередь отделяет доступность внешнего webhook от скорости LLM и помогает пережить короткие всплески нагрузки.

Отдельно стоит предусмотреть идентификатор задания, состояние обработки и журнал этапов. Аудит должен показать, когда событие было принято, какая политика сработала, применялась ли модель, какое решение получилось и куда ушло уведомление. Эти данные особенно важны при разборе пропущенного или неожиданно подавленного алерта.

Детерминированные правила остаются основой

Критичные события не стоит передавать на усмотрение модели. Для уровней High и Disaster система может сразу выбрать обязательные каналы доставки. Для recovery полезно зафиксировать отдельный сценарий, а для повторяющихся событий — правила подавления и контроля flapping.

Корреляция также требует детерминированного базового слоя. YAML-правила или кодовые политики способны надёжно связать известные зависимости: падение контейнера и недоступность фронтенда, проблему сети и серию проверок доступности. Модель допускается использовать как ограниченный fallback, когда строгие правила не дали результата.

В таком контуре LLM не управляет инцидентом целиком. Она дополняет решение системы: классифицирует низкоприоритетный алерт, предлагает вероятную связь событий или готовит краткое объяснение для оператора. Неопределённость должна приводить к консервативному исходу: сохранить событие, передать его человеку или оставить без эскалации согласно политике.

JSON, валидация и fallback для ответа модели

Свободный текст неудобен для автоматики. Для каждого сценария задайте небольшую JSON-схему и допустимые значения. Триаж низкоприоритетного события, например, может вернуть только notify, suppress или hold, а также короткую причину. Результат проходит валидацию Pydantic до использования в пайплайне.

Полезные ограничения промпта:

• короткий контекст конкретного события;
• строгий формат JSON без пояснений вокруг него;
• перечисленные значения полей;
• консервативное поведение при недостатке данных;
• запрет на выход за заданную роль.

Если ответ не проходит схему, содержит неизвестное значение или модель недоступна, worker применяет безопасную запасную ветку. Например, записывает событие в аудит и отправляет стандартное уведомление без LLM-обогащения. Ошибка инференса не должна блокировать доставку алерта.

Рекомендации должны оставаться диагностикой

Генерация remediation — самая чувствительная часть. Рекомендации модели следует ограничить read-only действиями: проверить статус сервиса, слушающие порты, свежие журналы, сетевую доступность. Команды перезапуска, удаления данных, очистки ресурсов и изменения конфигурации должны быть исключены из контракта и дополнительно отфильтрованы guardrails в коде.

Контекст тоже влияет на качество подсказок. Алерт хоста требует команд диагностики Linux, а контейнерный алерт — сведений о Docker или другом рантайме. Имя узла ещё не доказывает, что проблема находится в контейнере. Полезно передавать модели тип области: host_os, container, service, а также сервис, домен и метки из Zabbix.

Даже при такой подготовке рекомендация остаётся подсказкой оператору. Автоматическое исполнение действий требует отдельного контура согласований, проверок и ответственности.

Что проверять на домашнем стенде

Перед эксплуатацией стоит пройти функциональные сценарии: корректный webhook, неверный токен, события разной критичности, recovery, подавление повторов, доставку в каждый канал и ошибки модели. Для корреляции нужны связанные инциденты, а не одиночный алерт: например, остановка контейнера и последующая недоступность страницы за reverse proxy.

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

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