Выбор локальной LLM для системы мониторинга: интеграция Zabbix с нейросетью

Тихий убийца внимания дежурного инженера

Каждый, кто хоть раз ночью открывал Zabbix с сотней непрочитанных триггеров, знает это чувство. 80% алертов — мусор: временные пики, плановые перезагрузки, недонастроенные пороги. Остальные 20% — реальные проблемы, которые тонут в шуме. И вот ты сидишь в 3 часа ночи, прокручиваешь список, материшься сквозь зубы и пропускаешь критический чекаут диска, потому что за 15 минут до этого тебя разбудили из-за тестового скрипта.

Классические решения — корреляция триггеров, регулярные выражения, макросы — работают до определенной сложности. Но когда у вас микросервисы на сотне нод, а каждый рестарт под-ов генерит волну однотипных Warning, старые методы пасуют. Нужна голова, которая умеет читать контекст, отличать штатное поведение от аномалии.

Локальная LLM — это такой умный фильтр. Закидываете ей алерт, она возвращает: "Не беги, это плановый deployment v7.23", или "Подними джуниора — упал rate limit на API Gateway". И главное — без утечки данных, без облака, с предсказуемой задержкой. В предыдущей части мы уже собрали архитектуру такого анализатора. Теперь разберемся, какую модель выбрать, чтобы она не сожрала весь GPU и не тормозила на каждом запросе.

Почему не GPT-4o и не Claude

Ладно, давайте сразу про слонов. Если у вас инфраструктура без выхода в интернет (air-gapped) или требования комплаенса не пропускают данные наружу — облачные LLM отпадают. Но даже если нет, я не советую тащить сторонние API в пайплайн мониторинга. Причина простая: алерт может содержать IP, hostname, версию софта, конфиг — и это уже потенциальная утечка. Вдобавок вы зависите от сети, времени ответа (RTT) и ценника, который скачет от масштаба. В статье про утечки я подробно разобрал, как ваши данные могут уплыть. У нас железобетонный аргумент: держать LLM на своём сервере, ближе к Zabbix.

Критерии выбора: сок, а не вода

Выбор модели — это не "возьми самую большую". Это трейд-офф между качеством анализа, скоростью, объёмом контекста и доступным железом. Давай разложу по полкам.

1Контекстное окно — ваша рабочая память

Алерты в Zabbix редко бывают длиннее пары килобайт. Но вы, скорее всего, захотите передавать в промпт не только само сообщение, но и историю срабатываний, теги, предыдущие действия инженеров, метрики за последний час. Если контекстное окно модели меньше 8K токенов — вы будете резать данные, теряя нюансы. Идеально — 32K-128K. На май 2026 года почти все новые модели стартуют от 128K. Llama 4 и Mistral Large 3 держат 256K. Qwen3 — до 1M. Но помните: чем больше контекст, тем выше потребление VRAM и латентность первого токена.

2Размер модели vs железо

Тут работает правило: для анализа алертов (инструкции, классификация, генерация коротких ответов) не нужны 400B-модели. 7B — слишком мало для понимания сложной логики мониторинга и метрик. 13B-30B — золотая середина. 70B — если у вас есть RTX 4090 или старый Tesla V100 с 32 GB, но придётся квантизировать. 120B+ — только если у вас GPU-кластер или DGX. Я рекомендую для продакшна смотреть на модели 30B-70B в 4-битной квантизации. Они дают качество, сопоставимое с 70B FP16, при вдвое меньшем потреблении памяти.

3Скорость вывода и Time-to-First-Token

Если у вас 100 алертов в минуту, вы не можете ждать 30 секунд каждый ответ. LLM должна работать с latency первого токена не более 0.5-1 сек. Этого можно добиться только с батчингом и efficient serving. Инструменты вроде vLLM с PagedAttention и LazyGate (я писал об этом в статье про спасение Time-to-First-Token) позволяют держать пиковые нагрузки без просадок. На май 2026 vLLM стабильно поддерживает все последние архитектуры. Я для Zabbix-интеграции предпочитаю vLLM + LLama.cpp как fallback.

4Поддержка function calling и структурного вывода

Вам же нужно от модели получить не просто текст, а структурированный результат: verdict (critical/warning/info), action (escalate/ignore/acknowledge), confidence score. Нативная способность модели возвращать JSON в едином формате — must have. Проверяйте это до интеграции. Qwen3, DeepSeek v4, Mistral Large 3 отлично справляются с tool use.

Обзор актуальных моделей (май 2026): кто есть кто

Я прогнал через бенчмарки несколько кандидатов для задачи классификации алертов Zabbix. Вот что получилось.

Мой личный выбор для старта — Mistral Large 3 в 4-битной квантизации. Она даёт лучшее качество анализа ошибок при инфраструктурных проблемах (сеть, диск, CPU) и очень стабильно держит контекст. Если у вас ограничены ресурсы, берите Qwen3 72B — она местами умнее Llama 4, но её поддержка в vLLM пока сыровата. Для быстрого POC подойдёт Ollama с моделью типа llama4:8b — да, качество ниже, но встанет на одну RTX 4060 и даст ощутимый процент корректных подсказок.

Архитектура интеграции: от Zabbix до LLM за 200 мс

Мы не будем пихать LLM напрямую в базу данных или триггеры. Всё должно быть асинхронно, очередь обработки обязательна. Вот схема, которая работает у меня в двух дата-центрах.

• Zabbix через webhook(event handler) отправляет JSON с алертом в RabbitMQ/NATS.
• Worker сервис (на Python с FastAPI) подписывается на очередь, достаёт алерт, обогащает его (добавляет данные последних 10 проверок из API Zabbix) и формирует промпт.
• LLM сервер (vLLM или Ollama с API-сервером) отвечает structured output (JSON).
• Worker записывает вердикт в собственную базу (или прямо в Zabbix через API, создавая событие с тегом).

Чтобы снизить RTT, я поднимаю LLM на той же сети, что и Zabbix-сервер, а лучше — на отдельном GPU-ноде через InfiniBand или NVLink для других задач. В гибридной архитектуре я показал, как можно комбинировать локальный инференс с облачным GPU для избыточной мощности.

Пошаговый план: выкатываем первого умного ассистента

1Выберите движок инференса

Я рекомендую vLLM. На май 2026 он поддерживает все популярные архитектуры, а бенчмарки показывают до 2x прироста пропускной способности над Ollama в production. Установка:

# Установка vLLM (версия 0.8.0 на май 2026)
pip install vllm

# Запуск сервера с моделью Mistral Large 3 (квантизация AWQ)
vllm serve mistralai/Mistral-Large-3-AWQ --dtype auto \
  --max-model-len 65536 --port 8000 --api-key secr3t

2Заведите шаблон промпта для классификации

Не надо надеяться на сырой промпт. Используйте structured output via guided decoding:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="secr3t")

response = client.chat.completions.create(
    model="mistralai/Mistral-Large-3-AWQ",
    messages=[
        {"role": "system", "content": "Ты — эксперт по мониторингу Zabbix.
         Анализируй алерт и верни JSON с полями: verdict, reason, action.
         Вердикты: critical, warning, info, ignore.
         Действия: escalate, acknowledge, ignore."},
        {"role": "user", "content": f"Алерт: {alert_text}\nИстория: {history}"}
    ],
    response_format={"type": "json_object"},
    temperature=0.1
)
print(response.choices[0].message.content)

3Свяжите с Zabbix через webhook

В Zabbix 6.4+ это настраивается в Administration -> Media types -> Webhook. Передавайте JSON с host, item key, trigger id, severity. Пример медиатипа доступен в предыдущем гайде.

4Обкатка на истории

Перед включением в прод соберите дамп алертов за месяц, промаркируйте их лейблами (какие реально важные, какие шум) и проверьте модель. Это выявит ложные срабатывания. Доработайте промпт и только потом включайте автоматическое действие.

Типичные грабли и как их избежать

• LLM тормозит, Zabbix таймаутит. Zabbix имеет таймаут на вебхук 30 секунд. Если LLM отвечает дольше, алерт повиснет. Решение: отправлять алерт в очередь немедленно, а не ждать ответа синхронно.
• Модель путает информацию. Если вы передаёте слишком много контекста, а модель не умеет его правильно обрабатывать, она может начать галлюцинировать. Ограничьте историю 10-20 последними событиями.
• Утечка данных через логи. Логи инференс-сервера могут содержать сырые данные. Настройте маскировку чувствительных полей или используйте eBPF-трассировщик, чтобы контролировать, что уходит.
• Не мониторите саму систему. Если LLM-нода упала, вы останетесь без фильтрации. Настройте мониторинг LLM-фермы через Grafana и Prometheus и сделайте fallback — при недоступности LLM пропускайте алерты в исходном виде.

Когда стоит пересмотреть выбор модели

Архитектура мониторинга меняется. Через год у вас может появиться новый тип алертов — от ML-моделей, от edge-устройств. Модель, которая отлично анализирует утечки памяти, может не понять специфику GPU-ошибок. Поэтому планируйте систему так, чтобы замена модели была одной строкой в переменной окружения. LangChain для мониторинга AI-агентов даёт готовые трейсы и метрики, позволяющие сравнивать разные модели в бою.

Ещё один нюанс: анализ постмортемов — это следующая ступень. Если ваша LLM уже умеет классифицировать алерты, добавьте ей задачу собирать контекст по инциденту и формировать черновик разбора. Zalando показал, что это реально.

Финальный совет: не пытайтесь заменить человека

Самая большая ошибка — надеяться, что LLM выключит дежурного вовсе. Моя практика: модель должна делать первый проход, отсекать очевидный шум, прикреплять теги и предлагать действия. Окончательное решение — за инженером. И не давайте модели автоматически создавать тикеты или перезагружать серверы. Только на N-th уровне после ручного подтверждения. Иначе одна галлюцинация положит прод быстрее, чем любой сбой.

И последнее: тестируйте на своих данных. Никакой бенчмарк не заменит прогона на реальных алертах вашей инфраструктуры. Поднимите MCP-сервер для автоматизации, скормите ему датасет — и увидите, где модель тупит.

Подписаться на канал