• Перевод

Тех, кто использует или собирается использовать Zabbix в промышленных масштабах, всегда волновал вопрос: сколько реально данных сможет Заббикс «переварить» перед тем как окончательно поперхнется и подавится? Часть моей недавней работы как раз касалось этого вопроса. Дело в том, что у меня есть огромная сеть, насчитывающая более 32000 узлов, и которая потенциально может полностью мониториться Заббиксом в будущем. На форуме давно идут обсуждения о том, как оптимизировать Zabbix для работы в больших масштабах, но, к сожалению, мне так и не удалось найти законченное решение.

В этой статье я хочу показать, как я настраивал свою систему, способную обрабатывать реально много данных. Чтобы вы понимали, о чем речь, вот просто картинка со статистикой системы:

Для начала хочется обговорить, что реально означает пункт «Required server performance, new values per second (далее NVPS) (Требуемое быстродействие в секунду)». Так вот, он не соответствует тому, сколько реально данных попадает в систему в секунду, а является простым математических подсчетом всех активных элементов данных с учетом интервалов опроса. И тогда получается, что Zabbix-trapper в расчете не участвует. В нашей сети trapper использовался достаточно активно, так что давайте посмотрим, сколько реально NVPS в рассматриваемом окружении:

Как показано на графике, в среднем Zabbix обрабатывает около 9260 запросов в секунду. Кроме того, в сети бывали и короткие всплески до 15000 NVPS , с которыми сервер без проблем справился. Честно говоря, это здорово!

Архитектура

Давайте рассмотрим каждый вопрос детально. Если быть честным, то вопрос сети я не рассматривал при разворачивании системы, что привело к проблемам, которые в дальнейшем было трудно продиагностировать. Итак, вот общая схема архитектуры системы мониторинга:

Железо

Конечно, ЦПУ и память тоже очень важны для MySQL. Большое количество ОЗУ позволяет Заббиксу хранить часто читаемые данные в памяти, что естественно способствует быстродействию системы. Изначально я планировал для сервера БД 64ГБ памяти, однако все замечательно работает и на 32ГБ до сих пор.

Сервера, на которых стоит сам zabbix_server, тоже должен иметь достаточно быстрые ЦПУ, так как необходимо, чтобы он спокойно обрабатывал сотни тысяч триггеров. Памяти же хватило бы и 12ГБ - так как на самом Заббикс сервере не так много процессов (практически весь мониторинг идет через прокси).

В отличии от СУБД и zabbix_server, Zabbix-прокси не требуют серьезного железа, поэтому я использовал «виртуалки». В основном собираются активные элементы данных, так что прокси служат как точки сбора данных, сами же практически ничего не опрашивают.

Вот сводная таблица, что я использовал в своей системе:

Отказоустойчивость Zabbix server

Поэтому я решил воспользоваться Linux HA с Pacemaker и CMAN. Для базовой настройки прошу глянуть мануал RedHat 6.4 . К сожалению, инструкция была изменена с момента, как я ее использовал, однако конечный результат должен получиться таким же. После базовой настройки дополнительно я настроил:

1. 1. Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
      • Всегда легко найти какой сервер активен
      • Все соединения от Zabbix сервера всегда с одного и того же IP (После установки параметра SourceIP= в zabbix_server.conf)
      • Всем Zabbix-прокси и Zabbix-агентам в качестве сервера просто указывается общий IP
2. Процесс zabbix_server
   • в случае фейловера zabbix_server будет остановлен на старом сервере и запущен на новом
3. Symlink для заданий cron
   1. Симлинк указывает на директорию, в которой лежат задания, которые должны выполняться только на активном Zabbix-сервере. Crontab должен иметь доступ ко всем задания через этот симлинк
   2. В случае фейловера симлинк удаляется на старом сервере и создается на новом
4. crond
   • В случае фейловера crond останавливается на старом сервере и запускается на новом активном сервере

Отказоустойчивость СУБД

Я также использовал Linux HA с Pacemaker и CMAN и для базы данных. Как оказалось, в нем есть пару отличный возможностей для управления репликацией MySQL. Я использую (использовал, смотри раздел «открытые проблемы») репликацию для синхронизации данных между активным(master) и резервным(slave) MySQL. Для начала, точно также как и для серверов Zabbix-сервера, мы делаем базовую настройку кластера. Затем в дополнении я настроил:

1. Общий IP-адрес (shared IP address)
   1. В случае фейловера, IP-адрес переходит на сервер, который становится активным
   2. Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует два преимущества:
      • Всегда легко найти, какой сервер активен
      • В случае фейловера, на самом Zabbix-сервере не требуется никаких действий, чтобы указать адрес нового активного сервера MySQL
2. Общий дополнительный (slave) IP-адрес
   1. Этот IP-адрес может использоваться, когда к происходит запрос на чтение к базе. Таким образом, запрос может обработать slave-сервер MySQL, если он доступен
   2. дополнительный адрес может быть у любого из серверов, это зависит от следующего:
      • если slave-сервер доступен, и часы не отстают на более чем 60 секунд, то адрес будет у него
      • В обратном случае адрес будет у master-сервера MySQL
3. mysqld
   • В случае фейловера новый сервер MySQL станет активным. Если после этого старый сервер вернется в строй, то он останется slave для уже новоиспечённого master.

Zabbix-прокси

Работая с Заббикс прокси важно помнить:

1. Заббикс прокси способны обрабатывать очень серьезные объемы данных, если их настроить как следует. Так, например, во время тестов, прокси (назовем ее Proxy А) обрабатывала 1500-1750 NVPS без каких либо проблем. И это виртуалка с двумя виртуальными ЦПУ, 4ГБ ОЗУ и БД SQLite3. При этом прокси находилась на одной площадки с самим сервером, так что задержки на сети можно было просто не учитывать. Также почти все, что собиралась, было активными элементами данных Заббикс агента
2. Ранее я уже упоминал, как важна задержка на сети при мониторинге. Так вот, это действительно так, когда речь идет о крупных системах. Фактически, количество данных, которое может отослать прокси, не отставая, напрямую зависит от сети.

   На графике ниже хорошо видно как накапливаются проблемы, когда задержка сети не учитывается. Прокси, который не успевает:

Пожалуй, достаточно очевидно, что очередь из данных для передачи не должна увеличиваться. График относится к другому Заббикс-прокси (Proxy B), которая ничем по железу не отличается от Proxy A, но может передавать без проблем только 500NVPS а не 1500NVPS, как Proxy A. Отличие как раз в том, что B находится в Сингапуре а сам сервер в Северной Америке, и задержка между площадками порядка 230мс. Данная задержка имеет серьезный эффект, учитывая способ пересылки данных. В нашем случае, Proxy B может отправить только по 1000 собранных элементов Заббикс серверу каждые 2-3 секунды. По моим наблюдениям, вот что происходит:

• Прокси устанавливает соединение до сервера
• Прокси максимум отправляет за раз 1000 собранных значений элементов данных
• Прокси закрывает соединение

• Первичное подключение очень медленное. В моем случае оно происходит за 0,25 секунды. Уф!
• Так как соединение закрывается после отправки 1000 элементов данных, то TCP-соединение никогда не длится достаточно долго, чтобы успеть использовать всю доступную пропускную способность канала.

Производительность базы данных

• Изначально в системе я использовал MySQL 5.5.18. Сначала никаких видимых проблем с производительностью не наблюдалось, однако, после 700-750 NVPS MySQL стал загружать процессор на 100% и система буквально «замерла». Дальнейшие мои попытки исправить ситуацию, подкручивая параметры в конфигурационном файле, активируя large pages или partitioning ни к чему не привели. Более хорошее решение предложила моя жена: сначала обновиться MySQL до 5.6 и потом разбираться. На мое удивление, простой апдейт решил все проблемы с производительностью, который я никак победить в 5.5.18. На всякий случай, вот копия my.cnf .

Обратите внимание, что больше всего запросов «Com_update». Причина кроется в том, что каждое полученное значение влечет Update в таблицу «items». Также в базе данных в основном операции на запись, так что MySQL query cache никак не поможет. По сути, он может быть даже вредным для производительности, учитывая, что постоянно придется маркировать запросы как неверные.

Другой проблемой для производительности может стать Zabbix Housekeeper. В больших сетях его настоятельно рекомендую отключать. Для этого в конфиг-файле выставите DisableHousekeeping=1. Понятно, что без Housekeeping старые данные(элементы данных, события, действия) не будут удаляться из базы. Тогда удаление можно организовать через partitioning.

Однако, одно из ограничений MySQL 5.6.12 в том, что partitioning не может быть использован в таблицах с foreign keys и как раз они присутствуют почти повсеместно в базе Заббикс. Но кроме таблиц history, которые нам и нужны. Partitioning дает нам два преимущества:

1. Все исторические данные таблицы разбитые по днем/неделям/месяцам/и т.д. могут находиться в отдельных файлах, что позволяет в дальнейшем удалять данные без каких либо последствий для базы. Также очень просто понимать сколько данных собирается за определенный период времени.
2. После очистки таблиц InnoDB не возвращает место диску, оставляя его себе для новых данных. В итоге с InnoDB невозможно очистить место на диске. В случае с partitioning это не проблема, место может быть освобождено, простым удалением старых партиций.

Собирать или слушать

Разница в производительности может быть серьезной при выборе одного или другого способа как основного. Пассивный мониторинг требует запущенных процессов на Заббикс сервере, которые будут регулярно посылать запрос к Заббикс агенту и ждать ответа, в некоторых случаях ожидание может затянуться даже до нескольких секунд. Теперь умножьте это время хотя бы на тысячу серверов, и становится ясно, что «поллинг» может занять время.

В случае активного мониторинга процессов опроса нет, сервер находится в состоянии ожидания, когда агенты сами начнут подключаться к Zabbix-серверу, чтобы получить список элементов данных, которые требуется мониторить.

Далее, агент начнет сам собирать элементы данных с учетом полученного с сервера интервала и отправлять их, при этом соединение будет открыто только тогда, когда агенту есть что отправить. Таким образом, отпадает необходимость в проверке до получения данных, которая присутствует при пассивном мониторинге. Вывод: активный мониторинг увеличивает скорость сбора данных, что и требуется в нашей большой сети.

Мониторинг самого Заббикса

Одной полезной метрикой является свободное место в History Write Cache (HistoryCacheSize в в конфиг-файле сервера). Данный параметр должен всегда быть близок к 100%. Если же кэш переполняется - это означает, что Zabbix не успевает добавлять в базу поступающие данные.

К сожалению, подобный параметр не поддерживается Zabbix-прокси. Кроме того, в Zabbix, отсутствует элемент данных, указывающий, сколько данных ожидает отправки на Zabbix-сервер. Впрочем, этот элемент данных легко сделать самому через SQL-запрос к базе прокси:

SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name="history_lastid"

Запрос вернет необходимо число. Если у вас стоит SQLite3 в качестве БД для Zabbix-прокси, то просто добавьте следующую команду как UserParameter в конфиг-файле Zabbix-агента, установленного на машине, где крутится Zabbix-прокси.

UserParameter=zabbix.proxy.items.sync.remaining,/usr/bin/sqlite3 /path/to/the/sqlite/database "SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name="history_lastid"" 2>&1

{Hostname:zabbix.proxy.items.sync.remaining.min(10m)}>100000

Итого статистика

А вот графики с сервера базы данных. Приросты трафика каждый день соответствуют времени снятия дампа(mysqldump). Также провал 16 июля на графике запросов(qps) относится к той же проблеме, что я описывал выше.

Управление

Открытые проблемы

У меня есть идеи, как данную проблему можно решить, но еще не было времени это имплементировать:

• Использовать Linux-HA с DRBD для partitioning БД.
• LUN-репликация на SAN с репликацией на другой LUN
• Percona XtraDB cluster. В версии 5.6 еще недоступен, так что с этим придется подождать(как я писал, были проблемы с производительностью в MySQL 5.5)

Мониторинг был и остается важнейшей частью системного и сетевого администрирования. Но если для маленькой локальной сети зачастую достаточно время от времени смотреть логи, то в случае крупных систем приходится использовать специализированные средства. Об одном из них - Zabbix и поговорим сегодня.

Введение

Начнем с архитектуры. Система мониторинга Zabbix состоит из нескольких подсистем, причем все они могут размещаться на разных машинах:

• сервер мониторинга, который периодически получает и обрабатывает данные, анализирует их и производит в зависимости от ситуации определенные действия, в основном оповещение администратора;
• база данных - в качестве таковой могут использоваться SQLite, MySQL, PostgreSQL и Oracle;
• веб-интерфейс на PHP, который отвечает за управление мониторингом и действиями, а также за визуализацию;
• агент Zabbix, запускается на той машине/устройстве, с которой необходимо снимать данные. Его наличие хоть и желательно, но, если установить его на устройство невозможно, можно обойтись SNMP;
• Zabbix proxy - используется в основном в тех случаях, когда необходимо мониторить сотни и тысячи устройств для снижения нагрузки на собственно сервер мониторинга.

Логическая единица мониторинга - узел. Каждому узлу присваивается описание и адрес - в качестве адреса можно использовать как доменное имя, так и IP. Узлы могут объединяться в группы, к примеру группа роутеров, для удобства наблюдения. Каждому серверу соответствует несколько элементов данных, то есть отслеживаемых параметров. Поскольку для каждого сервера настраивать параметры, за которыми нужно следить, неудобно (особенно это верно для больших сетей), можно создавать узлы-шаблоны и каждому серверу или группе серверов будет соответствовать несколько шаблонов.

В статье будут рассмотрены интересные сценарии использования Zabbix, но сначала опишем установку этого решения на RHEL-подобные системы с MySQL в качестве БД.

Установка и первичная настройка

Перво-наперво надо подключить репозиторий EPEL:

# yum install http://ftp.yandex.ru/epel/6/i386/epel-release-6-8.noarch.rpm

Затем поставить нужные пакеты:

# yum install zabbix20-server zabbix20-agent zabbix20-web-mysql nmap httpd policycoreutils-python net-snmp net-snmp-utils # yum groupinstall "MySQL Database Client" "MySQL Database Server"

Для чего нужен httpd и утилиты SNMP, полагаю, понятно. А вот Nmap нужен для некоторых проверок, чтобы заполнить элементы данных. Теперь необходимо настроить автозапуск служб и их запустить.

# chkconfig httpd on # chkconfig mysqld on # chkconfig zabbix-server on # chkconfig zabbix-agent on # service mysqld start

И конечно же, надо произвести начальную настройку MySQL.

# mysql_secure_installation

Затем заходим в консоль MySQL и создаем БД и пользователя:

Mysql> CREATE DATABASE zabbix CHARACTER SET utf8; mysql> GRANT ALL PRIVILEGES ON zabbix.* TO "zabbix"@"localhost" IDENTIFIED BY "zabbixpassword";

Теперь импортируем базы данных:

# mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/schema.sql # mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/images.sql # mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/data.sql

Редактируем файл конфигурации сервера Zabbix (/etc/zabbix_server.conf):

# <...> DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix

Слегка подкрутим конфигурацию PHP (/etc/php.ini):

# <...> max_execution_time = 300 max_input_time = 300 post_max_size = 16M date.timezone = Asia/Omsk

Настраиваем SELinux:

# semanage port -a -t http_port_t -p tcp 10051 # setsebool -P httpd_can_network_connect on

Наконец, запускаем оставшиеся службы:

# service httpd start # service zabbix-server start # service zabbix-agent start

В браузере подключаемся к http://server_name/zabbix и производим начальную конфигурацию фронтенда Zabbix (то есть имя БД, имя пользователя и пароль). После этого начальную настройку можно считать завершенной.

Мониторинг nginx и memcache

Для мониторинга nginx можно, разумеется, использовать самописные скрипты. Но в некоторых случаях, когда времени катастрофически не хватает, хочется найти что-нибудь готовое. В случае с nginx таким готовым решением будет набор питоновских скриптов ZTC. Для их установки сперва нужно установить некоторые пакеты:

# yum install lm_sensors smartmontools

Затем используй следующие команды:

# wget https://bitbucket.org/rvs/ztc/downloads/ztc-12.02.1-1.el6.noarch.rpm # rpm -ivh --nodeps ztc-12.02.1-1.el6.noarch.rpm

Опция —nodeps нужна по причине того, что пакет требует версию Zabbix 1.8, но ничто не мешает попробовать ZTC и на последних его версиях.

Теперь добавим еще один конфиг nginx (/etc/nginx/conf.d/nginx_status.conf):

Server { listen localhost; server_name nginx_status.localhost; location /server-status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }

И поправим конфиг nginx в ZTC (/etc/ztc/nginx.conf):

# <...> proto=http host=localhost port=80 resource=/server-status

Проверим работу скрипта ZTC:

# /opt/ztc/bin/nginx.py ping # /opt/ztc/bin/nginx.py ping

Если все нормально, настраиваем Zabbix-agent на нужной машине (/etc/zabbix-agentd.conf):

# <...> UserParameter=nginx[*],/opt/ztc/bin/nginx.py $1

Теперь нужно настроить веб-интерфейс. Для этого необходимо импортировать шаблон Template_app_nginx.xml , что лежит в /opt/ztc/templates/ . Замечу, что лежит он именно на том компьютере, где установлен ZTC, так что если у тебя на сервере нет GUI, то файл придется копировать на машину, на которой установлен браузер и с которой собственно и ведется мониторинг.

Не стоит забывать, что в этом наборе скриптов кроме мониторинга nginx есть еще мониторинг и других приложений, таких, например, как MongoDB. Настраивается он аналогично, поэтому рассматривать его смысла нет.

А вот для memcache среди этих скриптов нет ничего, так что придется нам его написать самим. Проверим его работо- и дееспособность:

# echo -e "stats\nquit" | nc -q2 127.0.0.1 11211

В ответ должны посыпаться статистические данные. Теперь пишем скрипт-однострочник /etc/zabbix/scripts/memcache.sh (при этом не забываем сделать его исполняемым):

#!/bin/bash echo -e "stats\nquit" | nc 127.0.0.1 11211 | grep "STAT $1 " | awk "{print $3}"

Как и в случае с nginx, правим конфиг Zabbix-agent (/etc/zabbix-agentd.conf) и не забываем его рестартовать:

# <...> UserParameter=memcache[*],/etc/zabbix/scripts/memcache.sh $1

Берем шаблон отсюда и импортируем его в веб-интерфейс.

INFO

Мониторинг различных устройств с помощью Zabbix

В основном Zabbix используется для мониторинга серверов, но помимо собственно серверов есть еще множество других устройств, которые также нуждаются в мониторинге. Далее будет описана настройка Zabbix для мониторинга некоторых из них.

В большинстве сетей среднего и крупного размера имеется гремучая смесь всевозможного железа, которая досталась нынешнему админу со времен развертывания (и, скорее всего, это развертывание происходило еще при царе Горохе). По счастью, абсолютное большинство сетевого (да и не только) оборудования поддерживает открытый протокол SNMP, с помощью которого можно как получать о нем информацию, так и управлять параметрами. В данном случае нас интересует первое. Вкратце опишу нужные действия:

• включить поддержку SNMP на устройствах. Не забывай о безопасности - по возможности используй третью версию протокола, устанавливай авторизацию и изменяй имена community;
• добавить нужные элементы в Zabbix. Одному параметру SNMP соответствует один элемент; также нужно указать OID (идентификатор параметра) версию SNMP и, в зависимости от нее, параметры авторизации;
• добавить триггеры на нежелательное изменение параметров.

У каждой железки могут быть десятки отслеживаемых параметров, и вручную их добавлять замучаешься. Но в Сети можно найти множество шаблонов, которые уже содержат в себе все необходимые элементы, триггеры и графики, - остается только их импортировать и подключить нужные хосты. Также существуют стандартные OID, которые описаны в RFC. К таковым относится, например, uptime с OID .1.3.6.1.2.1.1.3.0 или - для коммутаторов - статус порта с OID .1.3.6.1.2.1.2.2.1.8.X, где X - номер порта.

Существует онлайн-генератор шаблонов , который генерирует их на основе стандартных OID. В основном он предназначен для железа от Cisco, но ничто не мешает его использовать для другого оборудования.

Zabbix также поддерживает и карту сети. К сожалению, ее нужно составлять вручную. Есть возможность поставить над соединительными линиями скорость - для этого требуется добавить в подпись нужный элемент в фигурных скобках. Помимо этого, в случае падения соединения можно раскрашивать соединительные линии красным цветом.

Тот же человек, что написал упомянутый генератор шаблонов, написал также и дополнение к фронтенду, которое отображает в удобном виде статус порта (скрипт для второго Zabbix лежит ). Установка его, как его автор сам и признает, достаточно заморочена - скрипт писался в первую очередь для внутреннего применения.

SNMP Traps в Zabbix

Протокол SNMP, помимо пассивного получения данных устройства, поддерживает также и активную их рассылку со стороны устройства. В англоязычной документации это именуется SNMP Trap, в русскоязычной же используется термин SNMP-трап. Трапы удобны, когда нужно срочно уведомить систему мониторинга об изменении какого-либо параметра. Для отлова трапов в Zabbix имеется три способа (во всех трех случаях нужен еще и демон snmptrapd):

• с помощью SNMPTT (SNMP Trap Translator);
• используя скрипт на Perl;
• используя скрипт на bash.

Далее описан первый вариант. Прежде всего, не забываем разрешить 161-й порт UDP и по необходимости временно отключить SELinux. Затем ставим нужные пакеты (предполагается, что репозиторий EPEL у тебя подключен):

# yum install net-snmp net-snmp-utils net-snmp-perl snmptt

Настраиваем snmptrapd (/etc/snmp/snmptrapd.conf):

DisableAuthorization yes traphandle default snmptthandler

Первая строчка отключает проверки доступа, что, в общем-то, крайне не рекомендуется делать в условиях промышленного использования (здесь она исключительно для простоты конфигурации), вторая указывает обработчик всех поступивших трапов, коим и является snmptthandler.

Затем настраиваем snmptt (/etc/snmp/snmptt.ini):

# <...> net_snmp_perl_enable = 1 mibs_environment = ALL date_time_format = %H:%M:%S %Y/%m/%d

Теперь нужно настроить шаблоны для маппинга трапов на Zabbix SNMP. Ниже будет приведен пример такого шаблона для двух видов трапов - coldStart и всех остальных (/etc/snmp/snmptt.conf).

# <...> EVENT general .* "General event" Normal FORMAT ZBXTRAP $aA $1 EVENT coldStart .1.3.6.1.6.3.1.1.5.1.0.33 "Status Events" Normal FORMAT ZBXTRAP $aA Device reinitialized (coldStart)

Первые две строчки описывают любые трапы, а вторая пара - конкретный трап с OID. Замечу, что для того, чтобы Zabbix ловил эти трапы, они должны быть именно в формате «ZBXTRAP адрес».

Включаем нужные службы:

# chkconfig snmptt on # chkconfig snmptrapd on # service snmptt start # service snmptrapd start

Посылаем тестовые трапы и смотрим логи:

# snmptrap -v 1 -c public 127.0.0.1 ".1.3.6.1.6.3.1.1.5.1" "0.0.0.0" 6 1 "55" .1.3.6.1.6.3.1.1.5.1 s "teststring000" # snmptrap -v 1 -c public 127.0.0.1 ".1.3.6.1.6.3.1.1.5.1" "0.0.0.0" 6 33 "55" .1.3.6.1.6.3.1.1.5.1 s "teststring000" # tail /var/log/snmptt/snmptt.log

Если все нормально, переходим к конфигурированию Zabbix. В файле /etc/zabbix_server.conf укажем местонахождение лога и включим встроенный SNMPTrapper:

# <...> SNMPTrapperFile=/var/log/snmptt/snmptt.log StartSNMPTrapper=1

После этого нужно зайти в веб-интерфейс Zabbix, по необходимости добавить в узле сети интерфейс SNMP и добавить элемент для трапа. Ставим все необходимые действия, если это нужно, и проверяем, для чего точно так же создаем тестовый трап.

INFO

Мониторинг VPN-туннелей на оборудовании Cisco

Возникла необходимость мониторинга загрузки кучи туннелей VPN на цисках. Все хорошо, SNMP как на циске, так и на Zabbix настроен, но есть одна загвоздка - OID для каждого соединения формируются динамически, как и их списки. Это связано с особенностями протокола IPsec, в которые я вдаваться не буду - скажу лишь, что это связано с процедурой установления соединения. Алгоритм извлечения нужных счетчиков, таким образом, настолько замудрен, что реализовать его встроенными средствами Zabbix не представляется возможным.

По счастью, имеется скрипт , который это делает сам. Его нужно скачать и закинуть в каталог ExternalScripts (в моем случае это был /var/lib/zabbixsrv/externalscripts). Проверим его работоспособность:

# /var/lib/zabbixsrv/externalscripts/query_asa_lan2lan.pl ciscocom 192.168.10.1 ASA get RX 94.251.99.1

Если проверка прошла успешно, применим комбинацию LLD с этим скриптом. Создаем шаблон с правилом обнаружения (OID 1.3.6.1.4.1.9.9.171.1.2.3.1.7) и двумя элементами данных с внешней проверкой и ключами ‘queryasa lan2lan.pl[«{$SNMPCOMMUNITY}», «{HOST.IP}», «ASA», «get, «RX», «{#SNMPVALUE}»]’ и ‘queryasa lan2lan.pl[«{$SNMP COMMUNITY}», «{HOST.IP}», «ASA», «get», «TX», «{#SNMPVALUE}»]’, назвав их соответственно «Incoming traffic in tunnel to {#SNMPVALUE}» и «Outgoing traffic in tunnel to {#SNMPVALUE}». После этого применяем шаблон к нужным узлам и ждем автообнаружения.

К сожалению, LLD сейчас не поддерживает объединение графиков из нескольких прототипов данных, так что приходится добавлять нужные элементы ручками. По окончании этой работы любуемся графиками.

Прикручиваем MIB к Zabbix

Сам по себе Zabbix не поддерживает MIB (Management Information Base), а готовые шаблоны есть отнюдь не для всех устройств. Конечно, все OID можно добавить и вручную (с помощью snmpwalk), но это работает, только если их у тебя не очень много. Однако существует плагин для веб-интерфейса Zabbix под названием SNMP Builder, который позволяет конвертировать MIB-файлы в шаблоны и уже эти шаблоны допиливать под свои нужды. Берем его из Git-репозитория:

# git clone https://github.com/atimonin/snmpbuilder.git

Накладываем патч (в твоем случае, разумеется, имена каталогов могут быть другими, и подразумевается, что ты находишься в каталоге, где размещен фронтенд Zabbix - в случае с RHEL-based системами это /usr/share/zabbix):

# patch -p1 < /home/centos/snmpbuilder/snmpbuilder-2.0.5.patch

Копируем недостающие файлы и распаковываем картинки:

# tar xzvf /home/centos/snmpbuilder/snmpbuilder-2.0_imgs.tar.gz # cp -r /home/centos/snmpbuilder/zabbix/* .

По необходимости редактируем переменную MIBSALL PATH в файле snmp_builder.php . В отдельных случаях может также понадобиться слегка подправить его код, начиная со строки foreach(glob($path.»/*.mib»). Код в этом случае будет выглядеть примерно так:

# <...> foreach(glob($path."/*.mib") as $filename){ if (preg_match("/^".preg_quote($path,"/")."\/(.+)\.mib$/",$filename,$matches)){ $result=exec("cat ".$filename."| grep -i "DEFINITIONS.*::=.*BEGIN"|awk "{print $1}""); $cmbMibs->addItem($result,$result); } }

Теперь можно уже использовать.

Прежде всего нужно найти MIB-файлы для твоего железа. Некоторые производители их скрывают, некоторые - нет. После того как ты их нашел, эти файлы нужно поместить в папку, которую ты указал в вышеуказанной переменной. В отдельных случаях могут возникнуть зависимости - в подобной ситуации нужно найти соответствующий MIB-файл, чтобы их разрешить. Итак, выбери шаблон, MIB-файл и укажи адрес устройства. Если все нормально, ты увидишь список OID, которые нужно затем выбрать для добавления к шаблону. После выбора нужно нажать кнопку «Сохранить». Добавленные элементы появятся в указанном шаблоне.

В отдельных ситуациях нужно отредактировать новодобавленные элементы, поскольку по дефолту интервал обновления 60 секунд, что в случае, например, с именем хоста не имеет особого смысла - лучше в подобных ситуациях ставить его равным 86 400 секунд (24 часа). Для счетчиков же нужно изменить формат хранения на «Дельта в секунду». Кроме того, с некоторыми элементами нужно настроить еще и преобразование их значений в удобочитаемый вид. Для этого перейди в «Администрирование -> Общие» и в выпадающем меню выбери «Преобразование значений», а там уже добавляй его.

В общем-то, модуль мы настроили - все остальное ты уже настраивай самостоятельно.

Версии протокола SNMP

Существует несколько версий SNMP. Первая версия появилась в 1988 году и на данный момент, хоть и считается устаревшей, все еще очень популярна. Версия 2 (фактически сейчас под ней подразумевают версию 2c) появилась в апреле 1993 года. Она была несовместима с первой версией. Основные новшества второй версии протокола заключались в обмене информацией между управляющими компьютерами. Кроме того, появилась команда получения сразу нескольких переменных (GetBulk).

Во времена разработки первой версии мало кто заботился о безопасности, поэтому о какой-либо защите в SNMPv1 и говорить нечего. Аутентификации как таковой не было - не считать же за нее строку Community, передаваемую в открытом виде? Были, конечно, попытки реализовать безопасность SNMPv1, но успехом они не увенчались. Во второй версии кардинальных изменений тоже не появилось. А вот SNMPv3 уже начала поддерживать как безопасность сообщений (USM), так и контроль доступа (VACM). В USM поддерживаются MD5 и SHA-1 для обеспечения защиты от модификации данных и DES (сейчас уже AES) для шифрования. VACM же вводит как возможность авторизации, так и возможность указывать, какой управляющий компьютер какими атрибутами может манипулировать.

Несмотря на то что настраивать SNMPv3 сложнее, крайне рекомендуется использовать именно его, а остальные версии протокола отключать.

Заключение

В данной статье я рассмотрел интересные возможности системы мониторинга Zabbix. Полагаю, если ты хороший админ, то эти возможности можешь применить с пользой для себя. Но не стоит забывать, что мониторинг не вещь в себе - его нужно применять в комплексе с организационными мерами.

2 Требования

Аппаратное обеспечение

Память

Zabbix требуется и оперативная память, и физическая память на жестком диске. Отправной точкой могут быть 128 МБ оперативной памяти и 256 МБ свободного места на жестком диске. Впрочем, очевидно, что объем необходимой дисковой памяти зависит от количества наблюдаемых узлов сети и наблюдаемых параметров. Если вы планируете достаточно долго хранить историю наблюдаемых параметров, то потребуется по крайней мере несколько гигабайт для хранения данных истории в базе данных. Каждый процесс демона Zabbix требует несколько подключений к базе данных. Объем памяти требуемый каждым подключением к базе данных зависит от настроек базы данных.

Чем больше оперативной памяти у вас имеется, тем быстрее работает база данных (а следовательно, и Zabbix)!

CPU

Zabbix и особенно база данных может потребовать значительных процессорных ресурсов в зависимости от количества наблюдаемых параметров и выбранной базы данных.

Другое оборудование

Для использования SMS уведомлений встроенных в Zabbix потребуется последовательный порт передачи данных и GSM модем. Конвертер USB-to-serial также будет работать.

Примеры конфигураций оборудования

В таблице приводятся несколько вариантов аппаратных конфигураций:

Поддерживаемые платформы

В связи с требованиями безопасности и критически важным характером работы системы мониторинга, единственной операционной системой, которая может обеспечить необходимую производительность, отказоустойчивость и гибкость является операционная система UNIX. Zabbix работает на всех ведущих версиях ОС.

Zabbix протестирован на следующих платформах:

Windows: все версии для рабочих станций и серверов начиная с 2000 (только Zabbix агент)

Также Zabbix может работать и на других Unix-подобных операционных системах.

Zabbix отключает дампы памяти на UNIX платформах, если он скомпилирован с шифрованием и не запускается в случае, если система (например по причине политики SELinux) не дает возможности отключения дампов памяти.

Программное обеспечение

Zabbix построен на современном веб-сервере Apache, ведущих СУБД, и языке сценариев PHP.

Системы управления базами данных

Поддержка IBM DB2 является экспериментальной!

SQLite3 может использоваться с Zabbix прокси без каких либо проблем, однако использование SQLite3 с Zabbix сервером не рекомендуется. Начиная с версии Zabbix 2.4.0, одновременный доступ сервера и веб-интерфейса к базе данных SQLite3 может привести к ее порче.

Веб-интерфейс

Следующее программное обеспечение потребуется для работы веб-интерфейса Zabbix:

Также Zabbix может работать и с предыдущими версиями Apache, MySQL, Oracle, и PostgreSQL.

Для шрифтов, кроме DejaVu, который установлен по умолчанию, нужна функция PHP imagerotate . Если функция не установлена, то эти шрифты могут неправильно отображаться на графиках. Эта функция доступна только если PHP скомпилирован вместе с GD, которого нет для Debian и для некоторых других дистрибутивов.

Веб-браузер на стороне клиента

Cookies и Java Script должны быть включены.

Поддерживаются последние версии Google Chrome, Mozilla Firefox, Microsoft Internet Explorer и Opera. Также и другие браузеры (Apple Safari, Konqueror) могут работать с Zabbix.

Начиная с Zabbix 3.0.13, реализована одна и та же политика источника для IFrames, что означает, что Zabbix веб-интерфейс нельзя поместить во фреймы на другом домене.

Всё еще, страницы помещенные в Zabbix фреймы будут иметь доступ к веб-интерфейсу Zabbix (посредством JavaScript), если страница, которая помещена во фрейм и веб-интерфейс Zabbix располагаются на одном домене..html , если помещена в комплексные экраны на http://secure-сайт/zabbix/ , будет иметь полный доступ к Zabbix посредством JS.

Сервер

Java gateway

Если вы получили Zabbix из репозитория исходных кодов или скачали архив, то необходимые зависимости уже включены в дерево исходного кода.

Если вы получили Zabbix как пакет вашего дистрибутива, то необходимые зависимости обеспечиваются системой управления пакетами.

В обоих вышеупомянутых случаях, программное обеспечение готово к использованию и скачивать какие-либо дополнительные файлы не нужно.

Однако, если вы хотите использовать другие версии этих зависимостей (например, если вы готовите пакет для определенного дистрибутива Linux), ниже приведен список версий библиотек, для которых подтверждена работоспособность Java gateway. Zabbix может также работать с другими версиями этих библиотек.

Следующая таблица содержит список JAR файлов, которые поставляются вместе в Java gateway в оригинальном коде:

Java gateway компилируется и запускается при наличии Java версии 1.6 или выше. Если вы готовите прекомпилированную версию Zabbix gateway для использования ее другими, то рекомендуется использовать для компиляции Java 1.6, в этом случае Zabbix gateway будет работать на всех версиях Java вплоть до самой последней.

Размер базы данных

Данные конфигурации Zabbix требуют фиксированное количество дискового пространства и сильно не увеличиваются.

Размер базы данных Zabbix в основном зависит от следующих переменных, которые определяют объем хранимых данных истории:

Количество обрабатываемых запросов в секунду

Это среднее количество новых значений, которые Zabbix сервер получает каждую секунду. Например: Если имеется 3000 элементов данных с интервалом проверки 60 секунд, то количество обрабатываемых запросов за секунду рассчитывается 3000/60 = 50 .

Это означает, что каждую секунду в базу данных Zabbix добавляется 50 новых записей.

Настройки очистки истории в базе данных

Zabbix хранит значения определенный период времени, обычно несколько недель или месяцев. Каждое новое значение требует определенный объем дискового пространства для данных и индексов.

Таким образом, если требуется сохранение 30 дней истории и каждую секунду в базу данных добавляется 50 новых записей, общее количество значений будет равно примерно (30 *24*3600)* 50 = 129.600.000 или около 130М значений.

В зависимости от типа базы данных, типа полученных значений (с плавающей точкой, целочисленный, строки, файлы журналов и т.д.) может потребоваться от 40 байт до сотен байт дискового пространства для хранения значения. Обычно одно значение занимает около 90 байт по числовым элементам данных. В нашем случае это означает, что 130M значений потребуют 130M * 90 байт = 10.9ГБ дискового пространства.

Размер значений текстовых/журнальных элементов данных невозможно предугадать, но вы можете ожидать около 500 байт на значение.

Настройки очистки динамики изменений в базе данных

Zabbix хранит ежечасную статистику значений max/min/avg/count для каждого элемента данных в таблице trends . Эти данные используются для отслеживания динамики изменений и для графиков при отображении большого периода времени. Период в 1 час не является настраиваемым.

Базе данных Zabbix, в зависимости от типа базы данных, требуется около 90 байт на один элемент. Предположим, что если требуется хранить динамику изменений в течении 5 лет. Значения 3000 элементов данных потребуют 3000*24*365* 90 = 2.2ГБ за год, или 11ГБ за 5 лет.

Настройки очистки событий в базе данных

Каждое событие требует около 170 байт дискового пространства. Сложно точно оценить количество событий, ежедневно генерируемых Zabbix сервером. В самом худшем случае, мы можем предположить, что Zabbix генерирует одно событие в секунду.

Это означает, что для того, чтобы хранить события 3 года, потребуется 3 *365*24*3600* 170 = 15ГБ дискового пространства.

Представленная ниже таблица содержит формулы для расчета требуемого пространства жесткого диска для системы мониторинга Zabbix:

Средние значения, такие как ~90 байт по числовым элементам данных, ~170 байт по событиям собраны по статистике из реальной жизни при использовании базы данных MySQL.

Общее количество требуемого места на жестком диске рассчитывается:
Конфигурация + История + Динамика изменений + События
После установки Zabbix такое дисковое пространство более НЕ будет использовано сразу. Размер базы данных будет постепенно увеличиваться и остановится по достижении определенного момента, зависящего от настроек очистки базы данных.

Необходимое свободное место на жестком диске, при использовании распределенного мониторинга, рассчитывается аналогичным образом, но оно так же будет зависеть от количества подчиненных нод, связанных с нодой рассчитываемого узла.

Синхронизация времени

Очень важно иметь точную дату и время системы на сервере с запущенным Zabbix. ntpd один из наиболее популярных демонов синхронизации времени хоста с временем на остальных серверах. Настоятельно рекомендуется поддерживать синхронизированное время на всех системах, где работают Zabbix компоненты.

Если время не синхронизировано, Zabbix будет конвертировать штампы времени собранных данных на время Zabbix сервера путем получения штампов времени клиента/сервера после установки соединения для передачи данных и корректировки штампов времени у полученных значений элементов данных при помощи разницы между клиент-сервер временем. Чтобы не усложнять работу и избежать возможные сложности, задержка в соединении игнорируется. По этой причине задержка в соединении добавляется к штампам времени полученных данных с активных подключений (активный агент, активный прокси, sender) и вычитается из штампов времени полученных данных с пассивных подключений (пассивный прокси). Все остальные проверки выполняются по времени сервера и их штампы времени не корректируются.

• Сбор данных
  • проверки доступности и производительности
  • поддержка мониторинга по SNMP, IPMI, JMX
  • пользовательские проверки
  • сбор желаемых данных за выборочные интервалы
• Широкие возможности визуализация
  • Графики в режиме реального времени
  • Карты сети
  • Пользовательские экраны и слайд шоу
  • Отчеты
• Хранение истории
• Гибкая настройка
  • Определение порогов
  • Настраиваемые оповещения
  • Автоматические реакции на события, в том числе удаленные команды
  • Шаблонизация
  • Система прав доступа
• Возможности web-мониторинга
• Веб интерфейс
• Zabbix API
• Наличие нативных клиентов под разные ОС
• Готовое решение Zabbix, основанное на Open SUSE

Архитектура и основные понятия Zabbix

Zabbix Сервер

Zabbix сервер - является главным компонентом, которому агенты сообщают информацию и статистику о доступности и целостности. Сервер является главным хранилищем, в котором хранятся все данные конфигурации, статистики, а также оперативные данные. Сервер выполняет опрос и захват данных, он вычисляет триггеры, отправляет оповещения пользователям. Это главный компонент которому Zabbix агенты и прокси отправляют данные доступности и целостности системы. Сервер может самостоятельно удаленно проверять сетевые устройства (так же как и веб сервера и почтовые сервера) используя простые проверки сервиса.

Сервер является главным хранилищем, в котором хранятся все данные конфигурации, статистики, оперативные данные, а так же эта сущность в Zabbix, которая будет активно уведомлять администраторов в случае возникновения проблем в любой из наблюдаемых систем.

Функционал базового Zabbix сервера разделен на три отдельных компонента; это: Zabbix сервер, веб интерфейс и хранилище в базе данных.

Zabbix Агент

Zabbix агенты разворачиваются на наблюдаемых целях для активного мониторинга за локальными ресурсами и приложениями (статистика жестких диски, памяти, процессоров и т.д.).

Агент собирает локальную оперативную информацию и отправляет данные Zabbix серверу для дальнейшей обработкиg. В случае проблем (таких как рабочий жесткий диск заполнен или упал процесс сервиса), Zabbix сервер может быстро уведомить администраторов конкретного сервера, который сообщил об ошибке.

Zabbix агенты чрезвычайно эффективны, потому что используют нативные системные вызовы для сбора информации статистики.

Zabbix Прокси

Zabbix прокси - это процесс, который может собирать данные мониторинга с одного или нескольких наблюдаемых устройств и отправлять эту информацию Zabbix серверу, впринципе прокси работает от имени сервера. Все собранные данные локально буферизуются и затем отправляются Zabbix серверу, которому принадлежит этот прокси.

Развертывание прокси опционально, но может быть очень полезна для распределения нагрузки на одиночный Zabbix сервер. Если данные собирают только прокси, то обработка этих данных на сервере значительно уменьшает загрузку ЦПУ и I/O диска.

Zabbix прокси - идеальное решение для централизованного мониторинга удаленных мест, филиалов и сетей без местных администраторов. Для Zabbix прокси требуется отдельная база данных.

Java gateway

В Zabbix 2.0 добавлена нативная поддержка для мониторинга JMX приложений введением нового демона Zabbix, называемого Zabbix Java gateway .

Zabbix Java gateway - это демон написанный на языке Java. Когда Zabbix сервер хочет знать значение конкретного JMX счетчика у узла сети, он опрашивает Zabbix Java gateway, который использует API управления JMX для опроса интересующего удаленного приложения. Приложению не требуется никаких дополнительных программ, оно просто должно быть запущено с опцией командной строки -Dcom.sun.management.jmxremote.

Установка Zabbix

Установка серверной части

1. Загрузить и распаковать архив исходных кодов

2. Создать группу и пользователя zabbix, от имени которого будут работать демоны zabbix

3. Создать БД для хранения настроек и данных мониторинга.