---
title: "Zabbix, Graylog и n8n: логи и алерты — Nodbot"
source_url: "https://nodbot.ru/integrations/zabbix-graylog/"
canonical_url: "https://nodbot.ru/integrations/zabbix-graylog/"
language: "ru"
content_type: "IntegrationGuide"
section: "integrations"
generated_at: "2026-05-30"
word_count_source: 842
---

# Zabbix, Graylog и n8n: логи и алерты разбор инцидентов

## AI summary

Как связать Zabbix и Graylog с n8n: JSON-RPC API, webhooks, GELF/HTTP input, error workflows, Telegram alerts, runbook и безопасные токены.

## Best used for

Страница объясняет «Zabbix, Graylog и n8n: логи и алерты — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Архитектура мониторинга
- Zabbix → n8n webhook
- n8n → Zabbix JSON-RPC API
- Логи n8n в Graylog
- Runbook реакции на инцидент
- Ошибки внедрения
- Практический контракт интеграции
- Пример безопасного входного контракта

## Source outline

# Zabbix, Graylog и n8n: логи и алерты разбор инцидентов

Обновлено: 2026-05-29

Zabbix и Graylog закрывают разные части эксплуатации. Zabbix отвечает за метрики, доступность и триггеры, Graylog — за поиск по логам и событиям. n8n в такой схеме не должен заменять monitoring stack: его задача — принять сигнал, обогатить контекстом, открыть задачу, уведомить дежурного и сохранить следы инцидента.

## Архитектура мониторинга

- Компонент | Задача | Что делает n8n
- Zabbix | метрики, host status, triggers | получает webhook или спрашивает JSON-RPC API
- Graylog | логи, search, streams | получает GELF/HTTP события или ищет контекст
- n8n | автоматизация реакции | Telegram alert, Jira task, CRM note, runbook step
- Postgres | журнал обработки | incident_id, dedupe_key, status, timestamps

## Zabbix → n8n webhook

Самый простой сценарий — создать media type/webhook в Zabbix и отправлять событие в n8n Webhook. Payload лучше сразу нормализовать.

```
{
  "source": "zabbix",
  "event_id": "{EVENT.ID}",
  "severity": "{EVENT.SEVERITY}",
  "host": "{HOST.NAME}",
  "trigger": "{TRIGGER.NAME}",
  "status": "{EVENT.STATUS}",
  "started_at": "{EVENT.DATE} {EVENT.TIME}"
}
```
Ключ дедупликации: source + event_id + status . Без него alert recovery и повторные уведомления будут дублироваться.

## n8n → Zabbix JSON-RPC API

Если нужно получить details по host/item/trigger, используйте HTTP Request к Zabbix API. API работает по JSON-RPC: метод, params, auth token и id запроса.

```
{
  "jsonrpc": "2.0",
  "method": "host.get",
  "params": {"output": ["hostid", "host"], "filter": {"host": ["n8n-prod"]}},
  "auth": "ZABBIX_API_TOKEN",
  "id": 1
}
```

## Логи n8n в Graylog

Для Graylog можно использовать Docker logging driver, sidecar/agent или HTTP/GELF input. В сообщениях должны быть поля, по которым реально искать: workflow_id , execution_id , node_type , error_message , environment .

```
{
  "short_message": "n8n execution failed",
  "host": "n8n-prod-1",
  "_workflow_id": "42",
  "_execution_id": "90123",
  "_severity": "error"
}
```

## Runbook реакции на инцидент

- Webhook получает alert.
- IF отделяет problem от recovery.
- Postgres проверяет, был ли alert уже обработан.
- HTTP Request запрашивает Zabbix details и последние ошибки из Graylog.
- Telegram/Jira получает короткий alert: что, где, с какого времени, ссылка на runbook.
- После recovery workflow закрывает или обновляет задачу.

## Ошибки внедрения

- Симптом | Причина | Фикс
- алерты дублируются | нет event_id/status dedupe | хранить ключ инцидента в Postgres
- Zabbix API возвращает auth error | токен не тот или истёк | создать отдельный API token и ограничить права
- Graylog не принимает логи | input выключен, wrong port, TLS | проверить input, firewall, format GELF/HTTP
- дежурный получает стену текста | payload не отфильтрован | собрать короткое сообщение и ссылку на детали

## Практический контракт интеграции

Интеграция «Zabbix, Graylog и n8n» должна начинаться с контракта данных: кто источник, какой внешний ID считается главным, какие поля можно перезаписывать и что делать при повторной доставке. Без этого n8n быстро превращается в слой случайного mapping между сервисами.

Минимально опишите входной item по теме «Zabbix, Graylog и n8n»: источник события, внешний ID, время получения и нормализованные поля. Главный риск — принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «Zabbix, Graylog и n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Zabbix, Graylog и n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}
```

### Критерий готовности

- описан основной external_id и политика upsert/dedupe
- credentials имеют минимально нужные права и понятного владельца
- известно, какие поля можно менять автоматически, а какие только после review
- есть обработка 401/403, 429, 5xx и изменения схемы payload

## Практический контекст для внедрения

Эта страница полезна не как абстрактная справка, а как рабочая инструкция под интеграцию Zabbix, Graylog и n8n: логи и алерты разбор инцидентов с реальными credentials, rate limits и понятным owner процесса. Перед изменением workflow зафиксируйте источник события: входные данные по теме zabbix graylog: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок.

Минимальная проверка перед публикацией workflow: один happy path, один пустой payload, один повтор события и одна ошибка внешнего сервиса. Для мониторинга используйте successful executions, skipped items, retry count, error branch usage; эти показатели быстро покажут, что сценарий работает иначе, чем ожидалось.

## Связанные материалы

- Логи и мониторинг n8n
- Error Trigger
- Incident response
- Telegram alerts

## Документация и источники

- www.zabbix.com/documentation/current/en/manual/api
- go2docs.graylog.org/current/making_sense_of_your_log_data/simple_search_scripting_api.htm
- go2docs.graylog.org/current/setting_up_graylog/rest_api_use_cases.htm
- docs.n8n.io/hosting/logging-monitoring/logging/

## Вопросы и ответы

### n8n может заменить Zabbix или Graylog?

Нет. n8n лучше использовать как слой реакции: принять alert, обогатить, уведомить, открыть задачу и записать результат.

### Какой ключ использовать для дедупликации Zabbix alert?

Обычно source + event_id + status. Для recovery не создавайте новый инцидент, а обновляйте существующий.

### Как связать Graylog и n8n?

Через HTTP/GELF input для отправки событий или через REST/search API для получения контекста по инциденту.

## Related Nodbot pages

- [Основы](/basics/)
- [Ноды](/nodes/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)
- [Блог](/blog/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.