| 1 | # Справочник: Zabbix (v1) |
| 2 | |
| 3 | > **Назначение:** база для ответов по Zabbix — понятия, где что искать в UI и в документации, типовые задачи. Без привязки к конкретным хостам и паролям. |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | ## 1. Ключевые понятия и иерархия |
| 8 | |
| 9 | - **Хост (host):** верхнеуровневая сущность — мониторируемая конечная точка (сервер, устройство, веб-приложение). У хоста уникальное имя, минимум одна группа хостов (для прав и организации), интерфейсы для сбора данных (Agent, SNMP, JMX, IPMI и т.д.). |
| 10 | - **Шаблон (template):** переиспользуемый набор элементов данных, триггеров и действий; подключается к хостам. Хороший шаблон — гибкий, модульный, по гайдлайнам (см. официальные template guidelines). |
| 11 | - **Элемент данных (item):** метрика, которую Zabbix собирает с хоста. Создаётся на хосте или наследуется из шаблона. Параметры: ключ (key), интервал обновления, единицы, история/тренды, препроцессинг, теги. |
| 12 | - **Триггер (trigger):** условие на основе данных item'ов; при выполнении — событие/проблема и при необходимости уведомление (action). |
| 13 | - **Действие (action):** что делать при срабатывании триггера (уведомление, команда, эскалация и т.д.). |
| 14 | |
| 15 | Поток: Host содержит items и triggers (напрямую или из шаблона) → данные собираются → триггеры оцениваются → при срабатывании — action. |
| 16 | |
| 17 | --- |
| 18 | |
| 19 | ## 2. Типы элементов данных (item types) |
| 20 | |
| 21 | - **Zabbix agent (Agent 2):** сбор через агент на хосте. Ключ задаётся по типу метрики (например `agent.ping`, `vfs.fs.size`). |
| 22 | - **SNMP agent:** для устройств с SNMP. В item указываются OID и параметры SNMP. |
| 23 | - **HTTP agent:** Zabbix как HTTP-клиент — запросы по HTTP/HTTPS, заголовки, авторизация, тело запроса. Выполняется сервером или прокси; подходит для REST API, веб-сервисов, SaaS. С 7.0 — persistent connections, асинхронные запросы. |
| 24 | - **Другие:** JMX, IPMI, расчётные (calculated), **Script items** (выполнение скрипта на агенте), **Prometheus** (сбор метрик в формате Prometheus с хоста или HTTP endpoint), внешние скрипты (trapper, user parameters) и т.д. Документация по типам: `.../manual/config/items/itemtypes/`. |
| 25 | |
| 26 | Ключ (key) у каждого типа свой: у agent — имя метрики, у SNMP — OID, у HTTP — URL и метод. |
| 27 | |
| 28 | --- |
| 29 | |
| 30 | ## 3. Где что искать в веб-интерфейсе |
| 31 | |
| 32 | - **Data collection (Конфигурация):** хосты, шаблоны, элементы данных, триггеры, действия. Структура: Configuration → Hosts / Templates → выбор хоста/шаблона → Items, Triggers, etc. |
| 33 | - **Monitoring:** просмотр данных и проблем — Dashboard, Hosts (список хостов и статусы), Problems, Latest data, Maps, etc. |
| 34 | - **Administration:** настройки системы, пользователи, медиа-типы, скрипты, очереди (queue), настройки сервера/прокси. |
| 35 | |
| 36 | Официальная структура разделов: раздел Manual в документации (см. ниже). |
| 37 | |
| 38 | --- |
| 39 | |
| 40 | ## 4. Документация (официальная) |
| 41 | |
| 42 | - **Базовый URL:** `https://www.zabbix.com/documentation/current/en/manual` (current — актуальная версия; можно подставить версию, напр. `7.0`, `6.0`). |
| 43 | - **Разделы:** introduction, concepts (сервер, агент, прокси), installation, config (конфигурация, items, triggers, templates), quickstart. |
| 44 | - **Конкретные темы:** |
| 45 | - Items (типы): `.../manual/config/items/itemtypes/` (zabbix_agent, http, snmp и др.). |
| 46 | - Templates: `.../manual/config/templates`, guidelines: `https://www.zabbix.com/documentation/guidelines/en/template_guidelines`. |
| 47 | - Web interface: `.../manual/web_interface/frontend_sections/` (monitoring, administration). |
| 48 | |
| 49 | При ответе на вопрос «где в доке про X» — вести к соответствующему подразделу manual. |
| 50 | |
| 51 | --- |
| 52 | |
| 53 | ## 5. Интеграция с nginx (stub_status) |
| 54 | |
| 55 | - **Цель:** собирать метрики nginx (соединения accepted/active/waiting, запросы). |
| 56 | - **Шаблоны:** «Nginx by Zabbix agent» (запросы с хоста через локальный агент к stub_status) и «Nginx by HTTP» (с сервера/прокси по HTTP, с поддержкой auth/HTTPS). |
| 57 | - **На хосте с nginx:** включить `stub_status` в location, ограничить доступ (например только 127.0.0.1 / ::1). Пример: |
| 58 | ```nginx |
| 59 | location = /basic_status { |
| 60 | stub_status; |
| 61 | allow 127.0.0.1; |
| 62 | allow ::1; |
| 63 | deny all; |
| 64 | } |
| 65 | ``` |
| 66 | - **Типовые проблемы:** 403 — нет allow для адреса, с которого идёт запрос (для agent-шаблона запрос идёт с самого хоста на 127.0.0.1). «Failed to fetch stub status» — проверить, что данные реально приходят (Latest data), и условия триггера. |
| 67 | |
| 68 | --- |
| 69 | |
| 70 | ## 6. Типовые проблемы и диагностика |
| 71 | |
| 72 | - **413 Request Entity Too Large:** не лимит Zabbix, а nginx — увеличить `client_max_body_size` в нужном location, затем `nginx -t && nginx -s reload`. При необходимости — триггеры по коду 413 в access log. |
| 73 | - **Нет данных по item:** проверить доступность агента (Availability в UI), интервал опроса, ключ и права на хосте; для HTTP — URL, сеть, таймауты. |
| 74 | - **Шум от триггеров:** не создавать триггеры без порога или с порогом «всегда срабатывает»; проверять синтаксис выражений и зависимость от реальных данных. |
| 75 | - **Очередь и производительность:** Monitoring → Queue (по типу); при перегрузке — смотреть задержки сервера/прокси и количество item'ов. |
| 76 | |
| 77 | Конкретные хосты, шаблоны и пароли — только из локального контекста пользователя, не из этого справочника. |
| 78 | |
| 79 | --- |
| 80 | |
| 81 | ## 7. Анти-паттерны |
| 82 | |
| 83 | - Не делать `nginx -s reload` без `nginx -t`. |
| 84 | - Не хранить пароли/токены Zabbix в репозитории. |
| 85 | - Не плодить триггеры без чёткого порога и без связи с действиями. |
| 86 | |
| 87 | --- |
| 88 | |
| 89 | ## 8. Архитектура: сервер, прокси, агент |
| 90 | |
| 91 | - **Сервер (Zabbix server):** центр — обрабатывает данные, хранит конфигурацию и метрики в БД, оценивает триггеры, выполняет действия. Включает Proxy Group Manager при использовании групп прокси. |
| 92 | - **Прокси (Zabbix proxy):** облегчённый процесс, собирает данные с устройств «за» сервер; разгружает сервер, снижает трафик, упрощает файрвол, мониторит удалённые площадки при нестабильном канале. Конфиг получает с сервера (с 7.0 — инкрементальное обновление раз в 10 с). Группы прокси: отказоустойчивость и балансировка, перераспределение хостов при падении прокси. |
| 93 | - **Агент (Zabbix agent / Agent 2):** ставится на мониторируемый хост, собирает метрики и отдаёт серверу или прокси по протоколу Zabbix agent. |
| 94 | - **High availability (HA):** сервер может работать в кластере (активный/резервные узлы) для отказоустойчивости; документация: `.../manual/concepts/server/ha`. |
| 95 | |
| 96 | Связь: Agent → Proxy или Server; Proxy → Server (протокол server-proxy). Прокси между собой не общаются. |
| 97 | |
| 98 | Документация: `.../manual/concepts/`, `.../appendix/config/zabbix_proxy`, `.../appendix/protocols/`. |
| 99 | |
| 100 | --- |
| 101 | |
| 102 | ## 9. Установка (платформы) |
| 103 | |
| 104 | - **Документация:** `https://www.zabbix.com/documentation/current/en/manual/installation/` — установка из пакетов (Linux), из контейнеров (Docker), из исходников. |
| 105 | - **Пакеты (Linux):** `install_from_packages` — репозитории по дистрибутивам, сервер + фронтенд + БД (MySQL/PostgreSQL). |
| 106 | - **Docker:** официальные образы (hub.docker.com/u/zabbix, github.com/zabbix/zabbix-docker): Server (MySQL/PostgreSQL), Frontend (Apache/Nginx), Agent, Agent 2, Proxy (MySQL/SQLite3), Java Gateway, SNMP traps, Web Service. Минимум: Server + Frontend + БД. Примеры: docker run и docker-compose в доке. |
| 107 | - **Окружение:** для работы сервера нужны БД и (для UI) веб-сервер с **фронтендом**. Фронтенд (PHP) отдаётся Apache/Nginx, обращается к API Zabbix server и к БД только для части операций; основная логика сбора и оценки триггеров — в сервере (backend). Отдельный компонент — Zabbix server; фронтенд лишь интерфейс управления и просмотра. |
| 108 | |
| 109 | --- |
| 110 | |
| 111 | ## 10. Под капотом: БД, конфиг, housekeeper |
| 112 | |
| 113 | - **БД:** сервер хранит конфигурацию и данные в MySQL или PostgreSQL. Выбор при установке; миграции — по инструкциям в доке. |
| 114 | - **Конфиг сервера:** обычно `/etc/zabbix/zabbix_server.conf` (Linux). Параметры: подключение к БД, буферы, воркеры, таймауты. После изменений — перезапуск сервера. |
| 115 | - **Housekeeper:** процесс удаления старых данных из БД. В `zabbix_server.conf`: `HousekeepingFrequency` (как часто запуск, по умолчанию 1 раз в час), `MaxHousekeeperDelete` (сколько записей за один проход, по умолчанию 500). Производительность упирается в скорость БД (диск, лучше SSD; при больших объёмах — партиционирование). Administration → Housekeeping — настройки хранения истории/трендов в UI. |
| 116 | - **Очереди:** Monitoring → Queue — задержки по типам сборов; при перегрузке смотреть число item'ов, таймауты, производительность БД. |
| 117 | |
| 118 | Документация: `.../appendix/config/zabbix_server`, `.../web_interface/frontend_sections/administration/housekeeping`. |
| 119 | |
| 120 | --- |
| 121 | |
| 122 | ## 11. Бэкап, обновление, безопасность |
| 123 | |
| 124 | - **Бэкап:** регулярный бэкап БД (mysqldump/pg_dump) и при необходимости конфигов сервера/прокси/агента и кастомных шаблонов. Восстановление — по инструкциям СУБД и Zabbix. |
| 125 | - **Обновление:** по официальному Upgrade path (документация); бэкап перед обновлением; проверка совместимости версий агентов/прокси с сервером. |
| 126 | - **Безопасность:** пользователи и группы в UI (Administration → Users), права на группы хостов; TLS для агента/прокси/веб-интерфейса — в доке по каждому компоненту. |
| 127 | |
| 128 | --- |
| 129 | |
| 130 | ## 12. Препроцессинг (preprocessing) |
| 131 | |
| 132 | - **Назначение:** преобразование значений item'а до сохранения в БД. Выполняется на сервере или прокси в порядке заданных шагов. Документация: `.../manual/config/items/preprocessing`. |
| 133 | - **Типовые шаги:** Multiplier, Regular expression (match + replace), Replace (строка/подстрока), JSONPath (извлечение из JSON), JavaScript, CSV to JSON, Check for error in JSON, Discard unchanged with heartbeat, Throttling и др. Цепочка выполняется последовательно; при сбое шага item может стать unsupported — для многих шагов есть **Custom on fail** (discard / set value / set error), чтобы не переводить item в unsupported. |
| 134 | - **Value mapping** — только для отображения в UI, не меняет хранимое значение; для сложной логики (несколько маппингов, преобразования) использовать препроцессинг (Replace, regex, JavaScript). |
| 135 | - **Зависимые item'ы:** данные берут из родительского item'а и применяют препроцессинг; сами хост не опрашивают — снижают нагрузку. В LLD на мастер-item часто включают «Discard unchanged with heartbeat». |
| 136 | - **Тестирование:** в форме item есть возможность протестировать препроцессинг на примере значения. Подразделы: Preprocessing testing, Preprocessing details, JSONPath functionality, JavaScript preprocessing. |
| 137 | |
| 138 | --- |
| 139 | |
| 140 | ## 13. Best practices (официальные) |
| 141 | |
| 142 | - **Документация:** `https://www.zabbix.com/documentation/current/en/manual/best_practices`; гайдлайны шаблонов: `documentation/guidelines` (template triggers, key principles). |
| 143 | - **Триггеры:** не опираться на одно последнее значение — использовать окно (например last 5–10 минут: avg(), max(), min()) для снижения дребезга (flapping). В имени триггера: префикс по LLD-объекту, не использовать {HOST.NAME} и {ITEM.LASTVALUE} (для отображения — operational data). В описании — ссылка на доки и вероятные причины. |
| 144 | - **Шаблоны:** модульность, гибкость, переиспользование; не передавать пароли через user macros — создавать read-only пользователей для мониторинга. Предпочитать dependent items и user parameters вместо Zabbix trapper, если сбор < 30 с и регулярный; trapper — для долгих или нерегулярных сборов. Value mappings для дискретных состояний (0/1, статусы). |
| 145 | - **Восстановление триггера (recovery expression):** в выражении восстановления макросы вроде {ITEM.VALUE} в некоторых контекстах работают ненадёжно; предпочтительнее статические строки или корреляция по тегам событий. Документация: trigger expression, recovery operations. |
| 146 | |
| 147 | --- |
| 148 | |
| 149 | ## 14. Low-level discovery (LLD), зависимые item'ы, макросы |
| 150 | |
| 151 | - **Low-level discovery (LLD):** правила обнаружения, которые по одному мастер-item'у (например JSON, SNMP) находят сущности (файловые системы, сетевые интерфейсы, сервисы) и по прототипам создают item'ы и триггеры. Макросы LLD (например `{#FSNAME}`, `{#FSTYPE}`) подставляются в имена и ключи из обнаруженных данных. Документация: `.../manual/config/discovery`, `.../config/macros/lld_macros`. |
| 152 | - **Зависимые item'ы (dependent items):** берут данные из другого item'а (родителя), применяют препроцессинг (JSONPath, регулярные выражения и т.д.) и не опрашивают хост сами — снижают нагрузку на агента и БД. В LLD зависимые item'ы позволяют один раз получить JSON/лог и извлечь из него много метрик. Рекомендация: «Discard unchanged with heartbeat» на мастер-item при использовании в LLD. |
| 153 | - **Value mapping:** сопоставление числовых значений с текстом (0 → Down, 1 → Up) в отображении и триггерах. Для LLD-макросов value mapping напрямую в макросе недоступен; при необходимости — препроцессинг (например JavaScript) на мастер-item, чтобы подставить читаемые значения в JSON до discovery. |
| 154 | - **Макросы (user macros):** в шаблонах и хостах — переменные вида `{$MACRO}` для подстановки портов, путей и т.д.; при линковке шаблона к хосту макросы можно переопределить на уровне хоста или шаблона. **Секреты:** не хранить пароли в обычных макросах в репозитории; использовать secret user macros или внешние хранилища (CyberArk, HashiCorp) — `.../manual/config/secrets`, `.../config/macros/secret_macros`. |
| 155 | |
| 156 | --- |
| 157 | |
| 158 | ## 15. Триггеры: выражение, важность, восстановление |
| 159 | |
| 160 | - **Выражение триггера:** строится из функций (last(), avg(), max(), min(), nodata() и др.) над item'ами и порогов/сравнений. Документация: `.../manual/config/triggers/expression`. Рекомендация по гайдлайнам: не опираться только на последнее значение — использовать окно (например 5–10 минут), чтобы уменьшить дребезг (flapping). **Trigger dependencies:** триггер может зависеть от другого — при срабатывании «родителя» дочерний не генерирует события; упрощает причинно-следственную цепочку. **Event correlation:** trigger-based и global — подавление/объединение событий по правилам. **Predictive functions:** для прогнозных триггеров (timeleft, trend и т.п.) — `.../config/triggers/prediction`. |
| 161 | - **Важность (severity):** Not classified, Information, Warning, Average, High, Critical. Настраивается у триггера; в действиях можно фильтровать по важности и отправлять в разные каналы. Кастомизация набора важностей (с 6.0) — в доке. |
| 162 | - **Восстановление:** при возврате выражения в «норму» триггер переходит в OK; можно задать отдельное выражение восстановления (recovery expression) и сообщение при восстановлении. В выражении восстановления избегать макросов {ITEM.VALUE} при необходимости — использовать статические значения или теги. В действиях — условия «при срабатывании» и «при восстановлении»; recovery operations, escalations. |
| 163 | |
| 164 | --- |
| 165 | |
| 166 | ## 16. Окна обслуживания, медиа-типы, карты, API |
| 167 | |
| 168 | - **Окна обслуживания (maintenance):** период, в который выбранные хосты или группы не генерируют алерты (или генерируют с другим действием). Задаётся по расписанию (одноразово, ежедневно, еженедельно и т.д.). UI: Configuration → Hosts → Maintenance или Administration. API: объект `maintenance`, параметры active_since/active_till, timeperiods, groupids/hostids. Ошибки при создании через API часто из-за неверного типа period (для one-time не указывать start_time и т.п.). |
| 169 | - **Медиа-типы (media types):** каналы уведомлений — Email, SMS, Slack, скрипт, webhook и т.д. Настраиваются в Administration → Media types; у пользователя в профиле указываются контакты (адреса/номера) и когда использовать каждый тип. Действия (actions) при срабатывании триггера выбирают медиа и получателей по условиям (важность, группа, теги). |
| 170 | - **Карты (maps):** визуализация топологии — узлы и связи между ними, статусы из Zabbix (Problems, индикаторы). Data collection → Maps (или Monitoring → Maps в зависимости от версии). Полезны для обзора «где горит». |
| 171 | - **Сервисный мониторинг (IT services):** иерархия бизнес-сервисов и зависимостей от триггеров/хостов; расчёт **SLA** по целям (SLO). Проблемы сопоставляются с сервисами по тегам (problem tags); для точного SLA у сервиса должны совпадать теги с проблемами (AND). Документация: `.../manual/it_services`, `.../it_services/sla`. |
| 172 | - **API:** Zabbix API (JSON-RPC поверх HTTP) — автоматизация: создание хостов, шаблонов, триггеров, получение истории, maintenance, сервисы и SLA и т.д. Документация: `.../manual/api`. Аутентификация по токену или user/password; все сущности конфигурации доступны через API. |
| 173 | |
| 174 | Документация: `.../manual/api/reference/maintenance`, `.../manual/config/triggers/severity`, веб-интерфейс Maps. |
| 175 | |
| 176 | --- |
| 177 | |
| 178 | *Источники: официальная документация Zabbix (zabbix.com/documentation), best practices, гайдлайны по шаблонам и LLD, форум Zabbix. Справочник дополнен: препроцессинг, best practices, секреты/secret macros, зависимости триггеров, event correlation, HA, Prometheus/Script items — картина от установки до тонких настроек и автоматизации.* |
| 179 | |
| 180 | |