Глава 2. Распределённый мониторинг

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

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

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

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

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

Даже при этих условиях, определение периода времени, которое необходимо прокси выдерживать без какой либо связи со своим сервером может быть достаточно сложным, поскольку это зависит от двух специфических факторов: общего числа подлежащих мониторингу со стороны определённого прокси хостов и, кроме того, общего числа элементов или приобретённых метрик, которые этот прокси должен хранить в своей локальной базе данных. В этом месте будет легче понимать, что такой вид размышлений ведёт к выбору базы данных. В зависимости от того, будет ли обсуждаемый прокси находиться в вашей локальной сетевой среде, или нет, ваше решение придёт к предпочтению легковесной и производительной базы данных наподобие SQLite3; в противном случае мы будем вынуждены выбрать другой вид базы данных, который может поддерживать данные на протяжении длительного промежутка времени и может быть более устойчивым к авариям, то есть, MySQL или PostgreSQL.

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

Когда дело доходит до прокси, обычно целесообразно оставлять вещи лёгкими и простыми настолько, насколько это возможно; конечно, это верно только если сетевая архитектура позволяет нам принять такое решение. База данных прокси будет содержать только настройку и данные измерений, которые, при нормальных учловиях, почти немедленно синхронизируются с главным сервером. Выделение ему полнофункциональной базы данных обычно является излишним, поэтому если только у вас нет специальных требований, опция SQLite предоставит вам наилучший баланс между производительностью и простотой управления.

Если вы не скомпилировали исполняемый прокси при первом развёртывании Zabbix, проста выполните configure вновь с теми параметрами, которые вам нужны для прокси:

$ ./configure --enable-proxy --enable-static --with-sqlite3 --with-netsnmp --with-libcurl --with-ssh2 --with-openipmi
 	   

Скомпилируйте всё снова, воспользовавшись следующей командой:

$ make
 	   

Единственными файлы, которые вы должны скопировать на свою машину прокси являются сам исполняемый прокси и его файл настройки. Переменная $PREFIX должна разрешать применение того же самого пути, что вы используете в команде настройки (по умолчанию /usr/local):

# cp src/zabbix_proxy/zabbix_proxy $PREFIX/sbin/zabbix_proxy

# cp conf/zabbix_proxy.conf $PREFIX/etc/zabbix_proxy.conf
 	   

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

ProxyMode=0
 	   

Это означает, что ваша машина прокси находится в активном режиме. Помните, что вам нужно на главном сервере иметь по крайней мере столько ловцов (trapper) Zabbix, какое количество прокси вы разворачиваете. Установите это значение в 1, если вам нужно, или вы предпочитаете прокси в пассивном режиме. Для обсуждения дополнительных подробностей о режимах прокси обратитесь к разделу Понимание потока данных мониторинга Zabbix. Предыдущий код фиксирует это обсуждение.

Server=n.n.n.n
 	   

Это должен быть IP адрес главного сервера Zabbix или узла Zabbix, которому данный прокси должен отсылать отчёты.

Hostname=Zabbix proxy
 	   

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

LogFile=/tmp/zabbix_proxy.log
LogFileSize=1
DebugLevel=2
 	   

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

{Мы должны определить параметры базы данных прокси. Для SQLite эти поля не требуют заполнения:}

# DBHost=
# DBSchema=
# DBUser=
# DBPassword=
# DBSocket=
# DBPort=
 	   

Нам нужно создать базу данных SQLite; это можно сделать при помощи следующих команд:

$ mkdir –p /var/lib/sqlite/
$ sqlite3 /var/lib/sqlite/zabbix.db < /usr/share/doc/zabbix-proxysqlite3-2.4.4/create/schema.sql
 	   

Теперь в параметре DBName нам нужно определить полный путь к нашей базе данных SQLite:

DBName=/var/lib/sqlite/zabbix.db
 	   

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

ProxyOfflineBuffer=1
 	   

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

CacheSize=8M
 	   

Это размер кэша настроек. Сделайте его большим, если у вас имеется большее количество хостов и элементов мониторинга.

 

Команды времени выполнения прокси Zabbix

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

Вы можете заставить обновиться кэш настроек со своего сервера Zabbix при помощи следующей команды:

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R config_cache_reload
 	   

Данная команда сделает недействительным ваш кэш настроек на стороне прокси и заставит прокси запросить его текущие настройки у нашего сервера Zabbix.

Мы также можем достаточно просто увеличить или уменьшить уровень журналирования во время исполнения при помощи log_level_increase и log_level_decrease:

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf –R log_level_increase
 	   

Данная команда увеличит уровень журналировнаия для процесса прокси; та же самая команда поддерживает получателя, который может здесь идентифицироваться PID, типом процесса или комбинацией типом процесса и их числом. Что показывают следующие несколько примеров.

Увеличение уровня журналирования ваших трёх процессов регистрации:

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,3
 	   

Увеличение уровня журналирования вашего PID 27425:

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=27425
 	   

Увеличение или уменьшение уровня журналирования icmp pinger или любого другого процесса при помощи:

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase="icmp pinger"
zabbix_proxy [28064]: command sent successfully

$ zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="icmp pinger"
zabbix_proxy [28070]: command sent successfully
 	   

Мы можем быстро увидеть изменения, отражённые здесь в файле журнала:

28049:20150412:021435.841 log level has been increased to 4 (debug)

28049:20150412:021443.129 Got signal [signal:10(SIGUSR1),sender_pid:28034,sender_uid:501,value_int:770(0x00000302)].

 28049:20150412:021443.129 log level has been decreased to 3 (warning)
 	   

 

Развёртывание прокси Zabbix при помощи RPM

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

Всё что вам нужно сделать, это просто добавить официальный репозиторий Zabbix при помощи следующей команды, которая должна выполняться от имени root:

$ rpm –ivh http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-2.4.4-1.el6.x86_64.rpm
 	   

Теперь вы можете быстро просматривать перечень доступных пакетов zabbix-proxy при помощи следующих команд, опять же от имени root:

$ yum search zabbix-proxy

============== N/S Matched: zabbix-proxy ================
zabbix-proxy.x86_64 : Zabbix Proxy common files
zabbix-proxy-mysql.x86_64 : Zabbix proxy compiled to use MySQL
zabbix-proxy-pgsql.x86_64 : Zabbix proxy compiled to use PostgreSQL
zabbix-proxy-sqlite3.x86_64 : Zabbix proxy compiled to use SQLite3
 	   

В этом примере вслед за командой идёт связанный с ней вывод, который перечисляет все доступные пакеты zabbix-proxy; здесь вы должны сделать их выбор и установить желаемый пакет:

$ yum install zabbix-proxy-sqlite3
 	   

Теперь у вас уже имеется установленный прокси Zabbix, который может быть запущен следующей командой:

$ service zabbix-proxy start
Starting Zabbix proxy:                                       [ OK ]
 	   

Это сделано, если вы используете iptables, важно добавить правило для разрешения входящего обмена на ваш порт 10051 (который является стандартным портом прокси Zabbix) или, в любом случае, для порта который определён в вашем файле настройки:

ListenPort=10051
 	   

Чтобы сделать это, вам просто нужно изменить свой файл настроек iptables, /etc/sysconfig/iptables и добавить следующую строку в заголовок этого файла:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 10051 -j ACCEPT
 	   

Затем вам нужно перезапустить ваш локальный межсетевой экран от имени root, воспользовавшись следующей командой:

$ service iptables restart
 	   

В Code будет сгенерирован файл журнала:

$ tail -n 40 /var/log/zabbix/zabbix_proxy.log

 62521:20150411:003816.801 **** Enabled features ****
 62521:20150411:003816.801 SNMP monitoring:       YES
 62521:20150411:003816.801 IPMI monitoring:       YES
 62521:20150411:003816.801 WEB monitoring:        YES
 62521:20150411:003816.801 VMware monitoring:     YES
 62521:20150411:003816.801 ODBC:                  YES
 62521:20150411:003816.801 SSH2 support:          YES
 62521:20150411:003816.801 IPv6 support:          YES
 62521:20150411:003816.801 **************************
 62521:20150411:003816.801 using configuration file: /etc/zabbix/zabbix_proxy.conf
 	   

Поскольку вы сможете быстро определить его местоположение, файл настройки по умолчанию расположен в /etc/zabbix/zabbix_proxy.conf.

Единственная вещь, которую вам необходимо сделать, это проинформировать ваш прокси о сервере и добавить в него подлежащие мониторингу объекты. Все эти задачи выполняются через интерфейс Zabbix простым кликом на Admin | Proxies с последующим Create. Это отображено на следующем снимке экрана:

Примите во внимание, пожалуйста, необходимость использования того же самого Proxy name, которое вы применяете в файле настройки, которое, в данном случае, ZabbixProxy; вы можете быстро убедиться в этом:

$ grep Hostname= /etc/zabbix/zabbix_proxy.conf

# Hostname=
Hostname=ZabbixProxy
 	   

Отметим, что в случае с Active прокси вам просто нужно определить данное имя прокси, которое уже установлено в zabbix_proxy.conf. Это уже будет заданием прокси установить контакт с вашим главным сервером. С другой стороны, прокси Passive нуждается в IP адресе или имени хоста вашего главного сервера для соединения, что отображено на снимке экрана ниже:

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

Одно из преимуществ прокси состоит в том, что они не нуждаются в значительных настройках и сопровождении; как только они развёрнуты и вы назначили какие- нибудь хосты одному из них, вся остальная активность мониторинга достаточно прозрачна. Просто помните проверять число значений в секунду, которое должен обеспечивать каждый прокси, как это выражено в колонке Required performance на странице списка ваших прокси:

VPS (Values per second) это численное значение измерений в секунду, которое должен собирать отдельный сервер Zabbix или прокси. Это среднее значение, которое зависит от число элементов и частоты опроса для каждого элемента. Чем выше это значение, тем большую производительность должна иметь машина Zabbix.

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

 

Рассмотрение различных баз данных прокси Zabbix

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

Итак, SQLite3 является хорошим продуктом в качестве автономной и легковесной настройки, однако, если согласно нашему сценарию разворачиваемый нами прокси нуждается в сохранении значительного количества измерений, нам необходимо рассмотреть тот факт, что SQLite3 имеет определённые слабые места:

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

Вот пример базы данных sqlite3 и того, как осуществить к ней доступ с применением сторонней учётной записи:

$ ls -la /tmp/zabbix_proxy.db
-rw-r--r--. 1 zabbix zabbix 867328 Apr 12 09:52 /tmp/zabbix_proxy.db
]# su - adv
[adv@localhost ~]$ sqlite3 /tmp/zabbix_proxy.db
SQLite version 3.6.20
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite>
 	   

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

Чтобы установить прокси Zabbix с MySQL, в случае, когда мы компилируем его из источника, вам нужно применять следующую командную строку:

$ ./configure --enable-proxy --enable-static --with-mysql --with-net-snmp --with-libcurl --with-ssh2 --with-openipmi
 	   

После этого следует как обычно выполнить:

$ make
 	   

Если вместо этого вы используете предварительно скомпилированный rpm, вы просто можете выполнить от имени root:

$ yum install zabbix-proxy-mysql
 	   

Теперь вам необходимо запустить вашу базу данных MySQL и создать необходимую базу данных для вашего прокси:

$ mysql -uroot -p<password>
$ create database zabbix_proxy character set utf8 collate utf8_bin;
$ grant all privileges on zabbix_proxy.* to zabbix@localhost identified by '<password>';
$ quit;
$ mysql -uzabbix -p<password> zabbix_proxy < database/mysql/schema.sql
 	   

Если вы выполняете установку из rpm, предыдущая команда будет иметь вид:

$ mysql -uzabbix -p<password> zabbix_proxy < /usr/share/doc/zabbix-proxymysql-2.4.4/create/schema.sql/schema.sql
 	   

Теперь нам необходимо настроить zabbix_proxy.conf и добавить соответствующее значение в эти параметры:

DBName=zabbix_proxy
DBUser=zabbix
DBPassword=<password>
 	   

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

Наконец, мы должны запустить прокси Zabbix с использованием следующей команды от имени root:

$ service zabbix-proxy start

Starting Zabbix proxy:                                                  [ OK ]
 	   

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

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

Следующая схема представляет упрощённый поток данных, за которым следует элемент Zabbix:

Имейте в виду, что данная схема является упрощённой, удобочитаемой версией полного потока данных, и что она содержит множество других мелких компонентов, которые суммированы в данном рисунке блоком с названием various. Далее, обычно с левой стороны у нас имеются все возможные источники данных, а с правой стороны у нас присутствует GUI, который представляет веб- интерфейс Zabbix и, конечно, базу данных, которая хранит все наши элементы. Теперь, в следующем разделе, мы рассмотрим как реализуются детали нашего прокси Zabbix.

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

ConfigFrequency=3600
DataSenderFrequency=1
 	   

Оба предыдущих значения определяются в секундах. Со стороны сервера, в его файле настроек zabbix_server.conf, вам также необходимо установить соответствующее значение StartTrappers= на величину большую, чем общее число всех разворачиваемых вами активных прокси. Процессы улавливания (trapper) должны будут управлять всей входящей информацией от прокси, узлов и всех настраиваемых для активной проверки элементов. По мере необходимости данный сервер будет разветвлять дополнительные процессы, однако рекомендуется предварительно разветвить столько процессов, сколько вам уже известно, что сервер будет использовать.

В то же время на стороне прокси вы можете также настроить HeartbeatFrequency с тем, чтобы после предварительно заданного числа секунд он осуществлял контакт со своим сервером, даже если у него нет данных для отсылки. Затем вы сможете проверять доступность прокси при помощи следующего элемента, в котором, естественно, proxy name является уникальным идентификатором, который вы назначили данному прокси при развёртывании:

zabbix[proxy, "proxy name", lastaccess]
 	   

Данный элемент, как это отображено, будет выдавать вам общее число секунд прошедших с момента последнего контакта с прокси, значение, которое вы можете затем использовать с соответствующей запускающей функцией (триггером). Хорошей начальной точкой для должной настройки частоты пульсаций жизнеспособности (heartbeat) будет оценка того, сколько времени вы могли быть в состоянии утраты контакта с прокси прежде чем давать оповещение, и полагать что этот интервал в точности превосходит два цикла. Например, если вам нужно знать, будет ли прокси отключён меньше чем на протяжении 5 минут, установите частоту пульсаций на 120 секунд и проверьте что последнее время доступа превосходило 300 секунд. Следующая схема в точности отображает этот случай:

Активный прокси более эффективен при разгрузке занятого вычислениями сервера, поскольку последний просто будет будет свободным и ожидать того, что будет запрошен об изменениях в настройке или на приём новых данных мониторинга. Обратной стороной будет то, что такой прокси будет часто развёртываться для мониторинга безопасных сетей, например, DMZ, и прочих разделов со строгими политиками исходящего обмена. При подобном сценарии будет очень сложно получать разрешение на инициацию контакта данного прокси с сервером. И это связано не только с политиками; DMZ изолируется от внешней сети настолько, насколько это возможно по чрезвычайно полезным и разумным причинам. С другой стороны, часто бывает проще и более приемлемо с очки зрения безопасности инициировать контакт из вашей внешней по отношению к DMZ сети. В этом случае более предпочтительным будет решение с пассивным прокси.

Обладающий большими возможностями соединений и настройки, пассивный прокси является почти зеркальным образом своей активной версии. В настоящее время именно сервер необходим для периодических соединений с таким прокси для отправки изменений настройки и для запросов любых измерений, которые может выполнять данный прокси. В файле настроек прокси, если уж у вас установлен ProxyMode=1 для сигнализации что это пассивный прокси вам больше ничего не нужно делать.На стороне сервера присутствуют три переменные, которые вам необходимо проверить:

Больше никакой разницы между двумя режимами работы прокси не существует. Вы просто можете использовать элемент zabbix[proxy, proxy name", lastaccess] для проверки доступности пассивного прокси, в точности как это мы делали в случае с активным прокси:

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

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

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

Существуют определённые полезные элементы, которые помогут нам, причём все они содержатся в Template App Zabbix Proxy. Важно рассмотреть и применять их в явном виде.

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

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

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

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

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
 	   

Если вы вынуждены выбрать более надёжную базу данных для своего прокси, например, MySQL, тогда UserParameter в файле настройки агента прокси будет следующим:

UserParameter=zabbix.proxy.items.sync.remaining, mysql -u <your username here> -p'<your password here>' <dbname> -e 'SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name=history_lastid' 2>&1
 	   

Теперь, всё что вам нужно сделать, это установить на стороне вашего сервера Zabbix некий элемент со связанным с ним спусковым механизмом (триггером), который будет отслеживать как ваш прокси освобождает свою очередь. Этот элемент отображён на следующем снимке экрана:

Экземпляр спускового механизма, который может быть связан с этим элементом может быть таким:

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

Данный триггер загорится, когда число ожидающих в очереди элементов для отправки достигнет 10000, что является разумным числом; в любом случае, здесь вам нужно отрегулировать данный определённый элемент на число хостов, подлежащих мониторингу, которых вы имеете позади вашего прокси и значения числа элементов, которое получает ваш прокси.

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

{Прим. пер.: Начиная с Zabbix 3.0 обмен данными поддерживает шифрование, выполняемое при помощи TLS, и такая поддержка предоставлена между сервером, агентом и прокси. На момент данного перевода уже можно смело применять её к последующим до конца главы разделами стоит относиться как к расширению кругозора и для понимания задач закрытия каналов и возможных альтернатив их решения.}

Если вы уделили должное внимание подробностям настройки агентов, прокси и узлов, вы должны были заметить, что всем этим компонентам Zabbix необходимо знать для взаимодействия с другим компонентом его IP адрес. Никакая аутентификация не осуществляется, поскольку когда полагаются только на данный IP адрес для идентификации удалённого источника, это по своей природе не может являться безопасным. Более того, все пересылаемые данные являются простым текстом, в чём вы легко можете убедиться, выполнив tcpdump (или применив любой другой пакет для сниффера).

$ zabbix_sender -v -z 10.10.2.9 -s alpha -k sniff.me -o "clear text"

$ tcpdump -s0 -nn -q -A port 10051
00:58:39.263666 IP 10.10.2.11.43654 > 10.10.2.9.10051: tcp 113
E....l@.@.P...........'C..."^......V.......
.Gp|.Gp|{
      "request":"sender data",
      "data":[
            {
              "host":"alpha",
              "key":"sniff.me",
              " value":"clear text data"}]}
 	   

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

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

Если, по какой либо из причин, вы не можете сделать абсолютно ничего ещё, вы должны, по крайней мере, определить IP источника для каждого ловца (trapper) элемента Zabbix таким образом, чтобы было бы не так просто и прямолинейно мистифицировать данные мониторинга при помощи утилиты zabbix_sender. Воспользуйтесь в шаблоне элемента макросом {HOST.CONN} с тем, чтобы каждый хост использовал свой собственный IP адрес автоматически:

Что ещё более важно, убедитесь что удалённые команды не доступны для агентов. То есть, EnableRemoteCommands в файле настройки zabbix_agentd.conf должен быть установлен в значение 0. Вы можете потерять удобство функциональности, однако, если вы не можете защитить и аутентифицировать взаимодействие сервер - агент, риск для безопасности слишком велик чтобы даже рассматривать возможность использования этого.

Многие среды имеют управляющую сетевую среду, которая выделена и изолирована от вашей промышленной сети через немаршрутизируемые сетевые адреса и VLAN. Сетевые коммутаторы, маршрутизаторы и межсетевые экраны обычно обрабатывают обмен в промышленной среде, однако доступ к ним и возможность управления ими доступны только через их сетевые адреса управления. Хотя это и делает их слегка менее удобными для доступа с рабочей станции, это также гарантирует, что любой дефект безопасности в ваших компонентах (возьмём в качестве примера сетевое приложение, которое имеет сбойную реализацию SSL, которую вы не можете использовать, не поддерживающую SNMP v3, или имеющую непреднамеренно оставленным открытым Telnet) продолжает оставаться в отдельной и трудной для доступа сетевой среде. Вы можете захотеть разместить все взаимодействия сервер - прокси и глава - потомок в такой изолированной сети. Вы просто сделаете её более трудной для перехвата данных мониторинга и вы можете пропускать взаимодействие сервер - агент, но изолирование обмена всё- таки ощутимое решение даже если вы собираетесь в последующем шифровать его при помощи одного из наших решений, которые мы обрисуем в последующих разделах.

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

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

 

Безопасная оболочка

К счастью, SSH (Secure Shell, безопасная оболочка) имеет встроенные возможности организации туннеля, поэтому, если вы должны шифровать свой обмен при крайней необходимости, у вас уже имеются все необходимые вам инструменты.

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

$ ssh -N -f user@zabbix.server -L 10053:localhost:10051
 	   

В предыдущей команде -N означает что вы не хотите чтобы клиент SSH выполнял какие- либо команды отличные от простых маршрутизации и вашего обмена; опция -f заставляет клиента SSH перейти в фоновый режим (поэтому у вас нет необходимости оставлять терминал открытым или оставлять исполнение запущенного сценария навсегда); user@zabbix.server является разрешённым пользователем (а также реальным именем хоста или IP адресом) в вашем Zabbix, а -L port:remote-server:port настраивает сам туннель. Первый номер порта является тем, с которым будут соединяться ваши локальные приложения, в то время как следующая комбинация host:port определяет какой хост и порт TCP вашего сервера SSH должны присоединяться к нему с другой стороны туннеля.

Теперь установите свои опции Server и ServerPort в вашем zabbix_proxy.conf для localhost и 10053, соответственно.

Что случится, так это то, что начиная с текущего момент ваш прокси будет отсылать данные на порт 10053 , по которому существует сеанс ожидающий переправки всего обмена через протокол SSH на сервер Zabbix. С данного момента сервер SSH будет, наоборот, переправлять их в локальный порт 10051 и, в конце концов, демону Zabbix. Хотя никакие компоненты Zabbix самостоятельно не поддерживают никакого шифрования данных для своего протокола Zabbix, вы всё ещё будете в состоянии осуществлять их взаимодействие придерживаясь целостности сообщений и их конфиденциальности; всё что вы увидите в своеё сетевой среде при подобной настройке будет стандартным, шифрованным обменом данных SSH через TCP порт 22.

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

Для соединения с узлами Zabbix вам нужно настроить два таких туннеля, один от ведущего к подчинённому и один от подчинённого к ведущему.

На ведущем (master) выполните следующую команду:

$ ssh -N -f user@zabbix.child -L 10053:localhost:10051
 	   

На подчинённом (child) выполните следующую команду:

$ ssh -N -f user@zabbix.master -L 10053:localhost:10051
 	   

ssh -o ServerAliveInterval=60 -N -f user@zabbix.[child|master] -L 10053:localhost:10051
 	   

В предыдущем примере мы увидели как установить пакеты keep-alive; значение ServerAliveInterval выражается в секундах и представляет частоту, используемую для отправки пакетов для поддержания в живых данного сеанса. Кроме того, хорошей практикой будет наблюдение за этим каналом, а также, если возникают проблемы, уничтожать прерванный процесс SSH и повторно запускать его.

 

Stunnel

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

После установки и когда вы создадите копии своих полученных сертификатов SSL, в которых нуждается данная программа, вы можете просто все свои порты на перенаправление в файле /etc/stunnel/stunnel.conf. Для примера рассмотрим простой сценарий с сервером Zabbix, который принимает данные от активного прокси и обменивается данными с другим узлом осле получения установки stunnel и сертификатов SSL на все свои ти машины, вы можете получить следующие настройки.

В файл stunnel.conf сервера Zabbix добавьте следующие строки:

[proxy]
accept = 10055
connect = 10051

[node - send]
accept = localhost:10057
connect = node.server:10057

[node – receive]
accept = 10059
connect = 10051
 	   

В stunnel.conf прокси Zabbix поместите дополнительно следующие строки:

[server]
accept = localhost:10055
connect = zabbix.server:10055
 	   

В stunnel.conf другого узла добавьте такие строки:

[node - send]
accept = localhost:10059
connect = node.server:10059

[node – receive]
accept = 10057
connect = 10051
 	   

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

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

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

Такой обходной путь защитит ваш обмен данными и, при наилучшем сценарии, предоставить вам базовую аутентификацию хоста, однако имейте в виду, что пока не будет поддержки какого либо вида безопасного протокола Zabbix на вашем прикладном уровне, туннелирование и шифрование будут способны только защищать целостность ваших данных мониторинга. Любой пользователь, получающий доступ к компонентам Zabbix (будь то сервер, прокси или агент) будет способен отправлять поддельные данные по зашифрованному каналу, а у вас не будет существовать способа заподозрить грязную игру. Поэтому в добавление к безопасности всех каналов коммуникации, вам также необходимо убедиться, что ы вас имеется в наличии хорошая безопасность на уровне хоста. Начиная с Zabbix 3.0 диалог поддерживает шифрование, выполняемое при помощи TLS, и такая поддержка будет дана между сервером, агентом и прокси. Тем не менее, это будет доступно только начиная с версии Zabbix 3.0 {Прим. пер.: На момент перевода уже можно смело применять её.} До тех пор нам необходимо применять альтернативы, объясняемые в данной главе.

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

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

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

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