Когда Zabbix кричит, а ты не слышишь
Знакомо: 2000 алертов в день, 95% из них — мусор. CPU скакнул на 5% — триггер. Диск заполнился на 80% — предупреждение. А реальная проблема (утечка памяти в Java-процессе) тонет в этом шуме. Zabbix — отличный инструмент, но он тупой. Он не понимает контекст. Ему всё равно, что этот алерт уже был вчера и закончился сам собой.
Решение — прикрутить к Zabbix мозг. Локальный, без облаков и утечек. LLM, которая проанализирует историю, поймет паттерны и скажет: "Это критично, беги чинить" или "Забей, само пройдет".
Почему именно локальная LLM, а не ChatGPT?
Три причины:
- Конфиденциальность. Алерты часто содержат IP, hostname, версии софта. Отправлять это в облако — стрелять себе в ногу. Про защиту локальных LLM я уже писал вот тут.
- Скорость. Облачный LLM добавляет 1-3 секунды latency. Для потока алертов это критично — Zabbix может сгенерировать сотню алертов в минуту.
- Цена. На 2026 год стоимость API GPT-4o всё ещё высока при большом объёме. Локальная модель окупается за пару месяцев. Кейс перехода с OpenAI на локальную Llama 3 разобран здесь.
Архитектура: простая, как три копейки (но с нюансами)
Схема:
Zabbix Server → Webhook (медиатип) → FastAPI микросервис (на Python) → Локальная LLM (через Ollama или vLLM) → Результат (JSON с criticality/recommendation) → Zabbix Action (тег/эскалация)
Zabbix умеет отправлять вебхуки — это его родная фича. Микросервис принимает алерт, обогащает его историей (например, из Zabbix API или InfluxDB), отправляет в LLM, парсит ответ и возвращает тег ("severity": "high") или создает событие в Zabbix.
Вся инфраструктура self-hosted. Если вы ещё не разворачивали локальную LLM, советую начать с этой статьи.
Выбор модели: что актуально на май 2026
Забудьте про GPT-3.5, Llama 2 — они уже древность. На 2026 год топ локальных моделей для анализа алертов:
| Модель | Параметры | VRAM | Зачем |
|---|---|---|---|
| Llama 3.2 8B (Instruct) | 8B | ~6 GB (4-bit) | Баланс качество/скорость. Классифицирует алерты за 200-400 мс на GPU A100. |
| Mistral Small 24B | 24B | ~14 GB (4-bit) | Если нужна детальная рекомендация (например, команда для ssh). |
| Qwen2.5 32B | 32B | ~18 GB (4-bit) | Для сложной аналитики по историческим трендам. |
| DeepSeek Coder V3 7B | 7B | ~5 GB (4-bit) | Если алерты содержат stacktrace — модель обучена на коде. |
Для старта берите Llama 3.2 8B — она легко квантуется и бежит даже на RTX 3060. Если у вас Mac с Unified Memory, обратите внимание на oMLX — он умеет работать с SSD-кешем, снижая требования к RAM.
Важно: Не пытайтесь запустить 70B модель на домашнем сервере. Квантование до 2-bit убивает качество. 8B в 4-bit даёт 95% точности классификации при latency < 500 мс.
Реализация: от вебхука до ответа LLM
1 Настройка медиатипа вебхука в Zabbix
Создаём Media type типа Webhook. В поле Script вставляем:
return JSON.stringify({
event_id: event.eventid,
host: event.host,
trigger_name: event.trigger_name,
severity: event.severity,
message: event.message,
timestamp: event.clock
});
В URL указываем эндпоинт нашего микросервиса. Не забудьте добавить HTTP заголовок Content-Type: application/json. Zabbix отправит POST с этим телом.
2 Микросервис на FastAPI
Код — это просто. Сложнее — правильно обогатить контекст. Я покажу минимальный работающий пример:
from fastapi import FastAPI, Request
import httpx
import json
app = FastAPI()
OLLAMA_URL = "http://localhost:11434/api/generate"
MODEL = "llama3.2:8b-instruct-q4_K_M"
PROMPT_TEMPLATE = """Ты — senior SRE. Проанализируй аллерт:
Хост: {host}
Триггер: {trigger}
Сообщение: {message}
Ответь строго в JSON: {{"criticality": "critical|warning|info", "reason": "...", "action": "..."}}"""
@app.post("/analyze")
async def analyze(request: Request):
data = await request.json()
prompt = PROMPT_TEMPLATE.format(
host=data["host"],
trigger=data["trigger_name"],
message=data["message"]
)
async with httpx.AsyncClient(timeout=10.0) as client:
resp = await client.post(OLLAMA_URL, json={
"model": MODEL,
"prompt": prompt,
"stream": False,
"format": "json"
})
result = resp.json()
return json.loads(result["response"])
Как я не советую делать: Не отправлять историю алертов. LLM без контекста будет гадать. Лучше добавить в запрос последние 5 алертов с этого же хоста — это повышает точность на 30%.
3 Написание промпта (это самое сложное)
Промпт должен быть конкретным. Не пишите "проанализируй ситуацию" — LLM начнёт философствовать. Требуйте JSON с чёткими полями. Используйте формат parameter в Ollama — он гарантирует валидный JSON.
{
"model": "llama3.2:8b",
"prompt": "...",
"stream": false,
"format": "json",
"options": {
"temperature": 0.1,
"top_p": 0.9
}
}
Temperature 0.1 — почти детерминированный вывод. Нам не нужна креативность, нужна точность.
4 Обработка ответа и экшн в Zabbix
Полученный JSON можно использовать для создания события или изменения тега алерта. В Zabbix 7.0+ есть Actions на основе тегов. Назначаем тег criticality со значением из ответа LLM. Если criticality == "critical" — эскалация в PagerDuty / Telegram.
Ошибки, которые я сделал за вас
- Не учитывал rate limit LLM. Если алертов 100 в минуту, а модель обрабатывает 10 в секунду — очередь растёт. Добавьте буфер (Redis) и обрабатывайте пачками.
- Отправлял сырые алерты. Некоторые сообщения содержат бинарные данные (hex дампы). Они ломают токенизацию. Очищайте от не-ASCII.
- Доверял LLM на 100%. Никогда не делайте автоматическое действие без подтверждения, если LLM сказала "critical". Лучше используйте её как фильтр приоритетов, а не как единственный арбитр.
Производительность и масштабирование
Если хостов много, одной LLM не хватит. Ставьте vLLM с PagedAttention — она умеет батчить запросы и держать модель в памяти. На одном A100 80GB можно крутить Llama 3.2 8B и обрабатывать до 200 запросов/сек. Для сравнения: Ollama без батчинга — 10-20 запросов/сек. Для небольших инсталляций хватит Ollama.
Если вы работаете на Apple Silicon, рекомендую почитать про AnyLanguageModel — он унифицирует API для локальных и облачных LLM под Swift, но можно адаптировать подход к Python.
Когда ваш анализатор начнет работать против вас
LLM может научиться игнорировать реальные проблемы, если вы неправильно составите промпт. Типичный баг: "Если алерт повторяется каждый час, не считай его критичным". Модель начнет пропускать важные регулярные события (например, бекап каждого часа).
Решение: давайте LLM историю алертов за последние 24 часа. Пусть она видит паттерн. Научите её различать "запланированное" и "аварийное". Хороший промпт — половина успеха.
Вы не обязаны все делать сами
Если вам лень писать вебхук и микросервис — посмотрите готовые решения. Есть Zabbix LLM Gateway (опенсорс, но на май 2026 ещё сыроват). Или используйте N8N с LLM-нодой — это low-code подход, но он добавляет latency.
Но если вам нужен production-grade — пишите сами. Контроль над промптом и архитектурой того стоит.
Попробуйте — и ваш Zabbix перестанет орать по пустякам. А когда придет реальная проблема — LLM её не пропустит.