Ответ
Я использовал Zabbix для мониторинга классической инфраструктуры (виртуальные машины, сетевые устройства). Процесс строится вокруг центрального сервера и агентов.
Архитектура:
- Zabbix Server: Центральный компонент, который опрашивает агентов, обрабатывает данные, вычисляет триггеры и генерирует алерты.
- База данных: Обычно MySQL или PostgreSQL для хранения конфигурации, истории и тенденций.
- Zabbix Agent: Устанавливается на мониторируемые хосты для сбора системных метрик (CPU, память, диски, процессы).
- Zabbix Proxy (опционально): Используется для распределения нагрузки или мониторинга удаленных сетей, собирает данные и отправляет их на сервер.
Типовой процесс настройки:
- Регистрирую хост в веб-интерфейсе Zabbix.
- Привязываю к нему шаблоны (например,
Template OS Linux). Шаблоны содержат предопределенные элементы данных (items) и триггеры. - Настраиваю агент. Основные параметры в
/etc/zabbix/zabbix_agentd.conf:Server=192.168.1.10 # IP Zabbix Server для пассивных проверок ServerActive=192.168.1.10 # IP для активных проверок Hostname=web-server-01 # Должно совпадать с именем хоста в Zabbix - Создаю кастомные элементы данных, если нужно. Например, для мониторинга длины очереди в RabbitMQ:
UserParameter=rabbitmq.queue.length[*], /usr/local/bin/check_rabbitmq_queue.sh $1 - Настраиваю триггеры на основе собранных данных. Триггер — это логическое выражение, которое определяет проблемное состояние. Пример триггера на недоступность веб-сервиса:
{web-server-01:net.tcp.service[http,,80].max(#3)}=0Это означает: если 3 последних проверки HTTP на порту 80 вернули 0 (недоступно), сработает триггер.
- Настраиваю Actions (действия). Когда триггер меняет состояние, запускается действие: отправка email, сообщения в Slack или выполнение скрипта для автоматического исправления.
Плюсы в моем опыте: Глубокая встроенная функциональность, мощные триггеры, поддержка широкого спектра устройств через SNMP, IPMI, JMX. Сложности: Требует больше ручной настройки по сравнению с Prometheus, и масштабирование может быть нетривиальным.