зачем нужен zabbix proxy

Установка и настройка zabbix прокси на CentOS 7

Для построения распределенной системы мониторинга zabbix рекомендует использовать proxy серверы. Это штатный функционал заббикса, который позволяет регулировать нагрузку и организовывать мониторинг распределенной сетевой инфраструктуры. Подробнее об установке и настройке zabbix proxy будет рассказано ниже.

Зачем нужен Zabbix proxy

Расскажу своими словами что такое zabbix proxy и зачем он нужен. Допустим у вас есть распределенная сеть, где отдельные сегменты никак не связаны друг с другом. То есть условно, у вас 5 разных сетей с адресацией 192.168.0.0/24. Вам нужно настроить мониторинг узлов в этих сетях. Сети ничего не знаю друг о друге, у них нет прямого IP, только доступ в интернет.

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

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

Вроде понятно и доступно объяснил. Приступим теперь к установке zabbix proxy. Устанавливать будем на сервер под управлением CentOS 7. Если у вас его еще нет, то читайте об установке centos 7 и его первоначальной настройке. Требования к железу зависят от нагрузки на прокси, но в общем случае они будут не высоки. Для мониторинга 20-30 узлов я использовал виртуальную машину с 512 мб оперативной памяти и 10 гб диском. Сама прокси почти ничего не хранит, отправялет данные на сервер.

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

Установка Zabbix proxy

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

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

Устанавливаем прокси и агента. Агент, кстати, ставить не обязательно, но я обычно ставлю, чтобы мониторить сам сервер.

Распаковываем файл со схемой базы:

Создаем папку для базы данных и саму базу:

Устанавливаем владельцем базы заббикс:

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

Настройка Zabbix proxy

Открываем файл конфигурации zabbix proxy для настройки:

Необходимо изменить несколько параметров, все остальное можно не трогать:

Добавляем proxy в автозагрузку и запускаем:

Если сейчас посмотреть лог, то увидим там следующее:

Заполняете необходимые поля. В данном случае обязательное только одно поле Proxy name.

После добавление proxy на основной сервер, можно перезапустить сам прокси сервер и посмотреть лог:

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

В качестве теста запустим на самом прокси сервере zabbix agent и подключим его к основному серверу мониторинга через proxy. Для этого открываем конфиг агента и устанавливаем следующие параметры:

192.168.56.10 — локальный ip адрес прокси сервера.

Сохраняем файл, агента пока не запускаем. Идем в веб интерфейс и добавляем новый хост.

Имя указываем такое же, как Hostname у агента, ip адрес — локальный адрес агента, Monitored by proxy выбираем в выпадающем списке нужный proxy сервер. Когда добавите их несколько, они все будут в этом списке. Не забудьте назначить какой-нибудь шаблон. Если этого не сделать, то можно долго ждать поступления данных и недоумевать, почему ничего не поступает, хотя на вид все в порядке и ошибок в логах нет. Я много раз с подобным сталкивался в своей практике.

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

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

Проверяем лог агента:

Все в порядке, ошибок нет. Через некоторое время данные начнут поступать на основной сервер мониторинга с помощью посредника zabbix proxy.

Заключение

Когда я только начинал настраивать распределенный мониторинг, мне очень хотелось иметь возможность установить zabbix proxy на windows. Это бы очень упростило задачу разворачиания мониторинга на всяких мелких удаленных объектах. Но увы, это не возможно. Программа есть только под linux, на windows только агент. Можно без проблем развернуть на любой виртуалке — hyperv, или даже virtualbox.

Я планирую написать подробню статью на основе своего опыта построения распределенного мониторинга в очень разнородной среде. Но пока не сделал это, дам подсказку для тех, кто будет разворачивать много proxy серверов. Сделайте образ виртуальной машины и просто копируйте его на новых объектах. Достаточно будет изменить только сетевые настройки и hostname в конфигурации proxy.

Источник

Масштабируя Zabbix

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

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

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

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

Архитектура

Первое, в чем стоит разобраться это архитектура системы мониторинга. Должен ли Zabbix быть отказоустойчивым? Будут ли иметь значение один-два часа простоя? Какие последствия ждут, если упадет база данных? Какие потребуются диски для базы, и какой настраивать RAID? Какая нужна пропускная способность между Zabbix-сервером и Zabbix-proxy? Какая максимальная задержка? Как собирать данные? Опрашивать сеть (пассивный мониторинг) или слушать сеть (активный мониторинг)?

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

Железо

Точно подобрать правильное железо процесс не из легких. Главное что я здесь сделал, это использовал SAN для хранения данных, так как база Заббикса требует много I/O дисковой системы. Проще говоря, чем быстрее диски у сервера БД, тем больше данных сможет обработать Заббикс.

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

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

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

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

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

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

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

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

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

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

Zabbix-прокси

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Без мониторинга самого Zabbix эффективная работа большой системы просто не представляется возможной — критически важно понимать в каком месте произойдет «затык», когда система откажется принимать новые данные. Существующие элементы данных для мониторинга Заббикса могут быть найдены тут. В версиях 2.х Заббикса они были любезно собраны в шаблон для мониторинга Zabbix server, предоставляемый «из коробки». Пользуйтесь!

Одной полезной метрикой является свободное место в 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

Далее просто ставите триггер, который будет оповещать о том, что прокси не справляется:

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

Напоследок предлагаю графики загрузки системы. Сразу говорю, что не знаю, что произошло 16 июля — мне пришлось пересоздать все базы прокси (SQLite на тот момент), чтобы решить проблему. С тех пор я перевел все прокси на MySQL и проблема не повторялась. Остальные «неровности» графиков совпадают со временем проведения нагрузочного тестирования. В целом, из графиков видно, что у используемого железа большой запас прочности.

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

Управление

Итого в системе используется 2 сервера под Zabbix-сервера, 2 сервера под MySQL, 16 виртуальных серверов под Zabbix-прокси и тысячи наблюдаемых серверов с Zabbix-агентами. При таком количестве хостов о внесении изменений руками не могло быть и речи. И решением стал Git-репозиторий, к которому имеют доступ все сервера, и где я расположил все конфигурационные файлы, скрипты, и все остальное, что нужно распространять. Далее, я написал скрипт, который вызывается через UserParameter в агенте. После запуска скрипта сервер подключается к Git-репозиторию, скачивает все необходимые файлы и обновления и затем перезагружает Zabbix-агента/прокси/сервера, если конфиг-файлы имели изменения. Обновление стало не сложнее, чем запустить zabbix_get!

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

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

Несмотря на все усилия, которые я приложил, осталась одна существенная проблема, которую мне только предстоит решить. Речь о том, что когда система достигает 8000-9000NVPS, то резервная база MySQL больше не успевает за основной, таким образом никакой отказоустойчивости на самом деле и нет.

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

Источник

Установка и настройка zabbix прокси на CentOS 7

Для построения распределенной системы мониторинга zabbix рекомендует использовать proxy серверы. Это штатный функционал заббикса, который позволяет регулировать нагрузку и организовывать мониторинг распределенной сетевой инфраструктуры. Подробнее об установке и настройке zabbix proxy будет рассказано ниже.

Зачем нужен Zabbix proxy

Расскажу своими словами что такое zabbix proxy и зачем он нужен. Допустим у вас есть распределенная сеть, где отдельные сегменты никак не связаны друг с другом. То есть условно, у вас 5 разных сетей с адресацией 192.168.0.0/24. Вам нужно настроить мониторинг узлов в этих сетях. Сети ничего не знаю друг о друге, у них нет прямого IP, только доступ в интернет.

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

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

Вроде понятно и доступно объяснил. Приступим теперь к установке zabbix proxy. Устанавливать будем на сервер под управлением CentOS 7. Если у вас его еще нет, то читайте об установке centos 7 и его первоначальной настройке. Требования к железу зависят от нагрузки на прокси, но в общем случае они будут не высоки. Для мониторинга 20-30 узлов я использовал виртуальную машину с 512 мб оперативной памяти и 10 гб диском. Сама прокси почти ничего не хранит, отправялет данные на сервер.

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

Установка Zabbix proxy

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

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

Устанавливаем прокси и агента. Агент, кстати, ставить не обязательно, но я обычно ставлю, чтобы мониторить сам сервер.

Распаковываем файл со схемой базы:

Создаем папку для базы данных и саму базу:

Устанавливаем владельцем базы заббикс:

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

Настройка Zabbix proxy

Открываем файл конфигурации zabbix proxy для настройки:

Необходимо изменить несколько параметров, все остальное можно не трогать:

Добавляем proxy в автозагрузку и запускаем:

Если сейчас посмотреть лог, то увидим там следующее:

Заполняете необходимые поля. В данном случае обязательное только одно поле Proxy name.

После добавление proxy на основной сервер, можно перезапустить сам прокси сервер и посмотреть лог:

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

В качестве теста запустим на самом прокси сервере zabbix agent и подключим его к основному серверу мониторинга через proxy. Для этого открываем конфиг агента и устанавливаем следующие параметры:

Сохраняем файл, агента пока не запускаем. Идем в веб интерфейс и добавляем новый хост.

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

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

Проверяем лог агента:

Все в порядке, ошибок нет. Через некоторое время данные начнут поступать на основной сервер мониторинга с помощью посредника zabbix proxy.

Заключение

Я планирую написать подробню статью на основе своего опыта построения распределенного мониторинга в очень разнородной среде. Но пока не сделал это, дам подсказку для тех, кто будет разворачивать много proxy серверов. Сделайте образ виртуальной машины и просто копируйте его на новых объектах. Достаточно будет изменить только сетевые настройки и hostname в конфигурации proxy.

Источник