Пассивный прокси zabbix и глава 3. Агенты abbix и основные протоколы. Следите за агентами

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

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

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

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

Прокси Zabbix

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

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

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

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

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

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

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

Прокси 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 install и не копировать новый исполняемый
сервер Zabbix поверх старого в каталог назначения.

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

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

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

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

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

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

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

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

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

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

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

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

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

Команды времени выполнения прокси 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, типом процесса или комбинацией типом процесса и их числом.
Что показывают следующие несколько примеров.

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

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

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

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

Развёртывание прокси 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, который может быть запущен следующей командой:

Удостоверьтесь также, пожалуйста, что вы включили прокси когда загрузится ваш сервер при помощи
команды $ chkconfig zabbix-proxy on.

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

Чтобы сделать это, вам просто нужно изменить свой файл настроек 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.

Примите во внимание, пожалуйста, необходимость использования того же самого 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 страдает при записях больших объёмов
• SQLite3 не реализует никакого механизма аутентификации пользователей

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

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

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

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

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

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

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

$ yum install zabbix-proxy-mysql

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

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

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

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

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

Понимание потока данных мониторинга Zabbix

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

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

• Агент Zabbix
• Команда отправитель Zabbix zabbix_send
• Индивидуально созданные сторонние агенты
• Прокси Zabbix

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

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

Понимание потока данных мониторинга с прокси

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

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

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

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

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

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

• StartProxyPollers=:Представляет число процессов, предназначенных для управления пассивными прокси и должно соответствовать
  числу развёрнутых вами пассивных прокси.
• ProxyConfigFrequency=:Ваш сервер будет обновлять пассивный прокси изменениями настроек через число секунд, которое вы должны
  установить в предыдущей переменной.
• ProxyDataFrequency=:Этот интервал, также указываемый в секундах, между двумя последовательными запросами вашего сервера к
  пассивному прокси за результатами мониторинга.

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

Мониторинг прокси Zabbix

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

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

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

Рассмотрение безопасности

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

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

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

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

Отсутствие настройки сетевой среды

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

Изоляция сетевой среды

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

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

Простые туннели

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

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

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

Теперь установите свои опции 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) выполните следующую команду:

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

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

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

Одним из способов наблюдения за тем, жив ли туннель SSH или не может быть реализован, состоит в
добавлении следующей опции:
ExitOnForwatdFailure=yes
Это необходимо определить в командной строке. Сделав это, нам понадобится только наблюдать за тем
жив ли (alive) процесс или SSH закончится если существуют отказы.

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

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

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

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

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

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

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

Полномасштабный VPN

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

Выводы

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

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

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

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

Zabbix monitoring system consists of components that communicate with each other. Here is a summary of the TCP ports and some configuration characteristics of various connections.

Active agent: The Zabbix agent periodically asks the Zabbix proxy (or Zabbix server, if configured to use the server directly) for the list of items that should be collected, and then the agent will keep collecting the item values using the configured intervals and sending the values to the proxy. The proxy does not need to poll all the clients for the values, so this is more efficient way of working.

Passive agent: The Zabbix agent passively waits for connections. When the Zabbix proxy requires the item values from a client, it connects to the client and gets the item values. This requires the proxy to schedule and initiate the connections to all agents, so it requires more work from the proxy.

Depending on the agent and item configurations, the same agent can be in active mode for some items and in passive mode for other items, if both ways are configured properly. Usually it is simpliest to just use one mode in items, preferably active (especially in large deployments).

Note that the active/passive mode used in proxy is not related to the active/passive mode of the agent. The proxy active/passive mode is only related to the communication between the Zabbix server and the Zabbix proxy: Active = proxy will connect to server, passive = server will connect to proxy. If a proxy is in passive mode, meaning that Zabbix server will poll Zabbix proxy for available data, an agent associated with that proxy can still be in active mode.

If you are running Zabbix server and Zabbix proxy on the same server (design used in some scenarios), you need to change the default port (10051) in either of the components (and change also other configurations accordingly) as they obviously cannot run on the same server otherwise.

Пассивная проверка

1, проактивные и пассивные относины к ссылке, здесь мы сказали, что инициатива и пассивная относится к «агенту».

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

3. Тип элемента мониторинга мониторинга пассивного режима, вам необходимо выбрать «Zabbix Agent» в интерфейсе настроек интерфейса.

Пассивные параметры конфигурации

Используя пассивный агент, вам необходимо указать следующие параметры конфигурации в файле конфигурации Zabbix_agentd.conf:

##### Passive checks related
​
### Option: Server
# List of comma delimited IP addresses, optionally in CIDR notation, or DNS names of Zabbix servers and Zabbix proxies.
# Incoming connections will be accepted only from the hosts listed here.
# If IPv6 support is enabled then ‘127.0.0.1’, ‘::127.0.0.1’, ‘::ffff:127.0.0.1’ are treated equally
# and ‘::/0’ will allow any IPv4 or IPv6 address.
# ‘0.0.0.0/0’ can be used to allow any IPv4 address.
# Example: Server=127.0.0.1,192.168.1.0/24,::1,2001:db8::/32,zabbix.example.com
#
# Mandatory: yes, if StartAgents is not explicitly set to 0
# Default:
# Server=
​
Server=127.0.0.1
​
### Option: ListenPort
# Agent will listen on this port for connections from the server.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# ListenPort=10050
​
### Option: ListenIP
# List of comma delimited IP addresses that the agent should listen on.
# First IP address is sent to Zabbix server if connecting to it to retrieve list of active checks.
#
# Mandatory: no
# Default:
# ListenIP=0.0.0.0
​
### Option: StartAgents
# Number of pre-forked instances of zabbix_agentd that process passive checks.
# If set to 0, disables passive checks and the agent will not listen on any TCP port.
#
# Mandatory: no
# Range: 0-100
# Default:
# StartAgents=3

• ListenPort: Номер порта, используемый для указания слушателя агента Zabbix, значение по умолчанию составляет 10050, диапазон значения составляет 1024-32767.
• StartAgents: Используется для указания количества экземпляров процессов Zabbix_Agentd заранее для обработки элементов пассивного мониторинга, значение по умолчанию составляет 3. Если этот параметр установлен на 0, пассивный режим агента отключен, а агент не будет прослушивать любой порт TCP.

Zabbix_get Tool.

Инструмент ZABBIX_GET может использоваться для моделирования процесса связи сети между пассивным агентом и сервером Zabbix. Zabbix_get применяется на стороне сервера и запрашивает данные агенту.

пример: Выполните следующую команду на сервере Zabbix:

Рабочий процесс

Примечание. Для обработки потока «Данные мониторинга запросов» см. Следующий анализ.