Анализатор алертов Zabbix + локальная LLM: архитектура и реализация | AiManual
AiManual Logo Ai / Manual.
04 Май 2026 Гайд

Умный анализатор алертов Zabbix на локальной LLM: архитектура, выбор модели и полная реализация

Пошаговое руководство: как интегрировать локальную LLM с Zabbix для автоматического анализа алертов. Архитектура, выбор модели (2026), код вебхука и промпты.

Когда 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". Лучше используйте её как фильтр приоритетов, а не как единственный арбитр.
💡
Совет: Начните с отправки alert в Telegram с пометкой "LLM: criticality = X". Посмотрите, как часто она ошибается. Через неделю скорректируете промпт и включите авто-тегирование.

Производительность и масштабирование

Если хостов много, одной 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 её не пропустит.

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