Для хранения данных используется MySQL , PostgreSQL , SQLite или Oracle . Веб-интерфейс написан на PHP . ZABBIX поддерживает несколько видов мониторинга:
- Simple checks - может проверять доступность и реакцию стандартных сервисов, таких как SMTP или HTTP, без установки какого-либо программного обеспечения на наблюдаемом хосте.
- ZABBIX agent - может быть установлен на UNIX-подобных или Windows -хостах для получения данных о нагрузке процессора , использования сети, дисковом пространстве и т. д.
- External check - выполнение внешних программ. ZABBIX также поддерживает мониторинг через SNMP .
История
Zabbix начался в 1998 году как проект внутреннего программного обеспечения. Спустя 3 года, в 2001 году, он был выпущен публично под лицензией GPL . Прошло более трёх лет до выхода первой стабильной версии - 1.0, которая была выпущена в 2004.
| График релизов | |
|---|---|
| Дата | Релиз |
| Zabbix 1.0 | |
| 1998 | ПО Zabbix началось как внутренний проект в банке Алексеем Владышевым |
| 7 Апреля 2001 | Zabbix 1.0alpha1 был выпущен с лицензией GPL |
| 23 Марта 2004 | Выпущен Zabbix 1.0 |
| Zabbix 1.1 | |
| 6 Февраля 2006 | Выпущен Zabbix 1.1 |
| Zabbix 1.4 | |
| 29 Мая 2007 | Выпущен Zabbix 1.4 |
| Zabbix 1.6 | |
| 11 Сентября 2008 | Выпущен Zabbix 1.6 |
| Zabbix 1.8 | |
| 7 Декабря 2009 | Выпущен Zabbix 1.8 |
| Zabbix 2.0 | |
| 21 Мая 2012 | Выпущен Zabbix 2.0 |
| Zabbix 2.2.1 | |
| 21 Декабря 2013 | Выпущен Zabbix 2.2.1 |
| Zabbix 2.4.0 | |
| 11 Сентября 2014 | Выпущен Zabbix 2.4.0 |
| Zabbix 3.0 | |
| 16 Февраля 2016 | Выпущен Zabbix 3.0 |
Архитектура
- Zabbix-сервер - это ядро программного обеспечения Zabbix. Сервер может удаленно проверять сетевые сервисы, является хранилищем, в котором хранятся все конфигурационные, статистические и оперативные данные, и он является тем субъектом в программном обеспечении Zabbix, который оповестит администраторов в случае возникновения проблем с любым контролируемым оборудованием.
- Zabbix-прокси - собирает данные о производительности и доступности от имени Zabbix-сервера. Все собранные данные заносятся в буфер на локальном уровне и передаются Zabbix-серверу, к которому принадлежит прокси-сервер. Zabbix-прокси является идеальным решением для централизованного удаленного мониторинга мест, филиалов, сетей, не имеющих локальных администраторов. Он может быть также использован для распределения нагрузки одного Zabbix-сервера. В этом случае, прокси только собирает данные, тем самым на сервер ложится меньшая нагрузка на ЦПУ и на ввод-вывод диска.
- Zabbix-агент - контроль локальных ресурсов и приложений (таких как жесткие диски, память, статистика процессора и т. д.) на сетевых системах, эти системы должны работать с запущенным Zabbix-агентом. Zabbix-агенты являются чрезвычайно эффективными из-за использования родных системных вызовов для сбора информации о статистике.
- Веб-интерфейс - интерфейс является частью Zabbix-сервера, и, как правило (но не обязательно), запущен на том же физическом сервере, что и Zabbix-сервер. Работает на PHP , требует веб сервер (например, Apache).
Обзор возможностей
- Распределённый мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящимися на более высоком уровне иерархии.
- Сценарии на основе мониторинга
- Автоматическое обнаружение
- Централизованный мониторинг лог-файлов
- Веб-интерфейс для администрирования и настройки
- Отчетность и тенденции
- SLA мониторинг
- Поддержка высокопроизводительных агентов (zabbix-agent) практически для всех платформ
- Комплексная реакция на события
- Поддержка SNMP v1, 2, 3
- Поддержка SNMP ловушек
- Поддержка IPMI
- Поддержка мониторинга JMX приложений из коробки
- Поддержка выполнения запросов в различные базы данных без необходимости использования скриптовой обвязки
- Расширение за счет выполнения внешних скриптов
- Гибкая система шаблонов и групп
- Возможность создавать карты сетей
Автоматическое обнаружение
- Автоматическое обнаружение по диапазону IP-адресов, доступным сервисам и SNMP проверка
- Автоматический мониторинг обнаруженных устройств
- Автоматическое удаление отсутствующих хостов
- Распределение по группам и шаблонам в зависимости от возвращаемого результата
Низкоуровневое обнаружение
Низкоуровневое обнаружение может быть использовано для обнаружения и для начала мониторинга файловых систем, сетевых интерфейсов. Начиная с Zabbix 2.0, поддерживаются три встроенных механизма низкоуровневого обнаружения:
- обнаружение файловых систем
- обнаружение сетевых интерфейсов
- обнаружение нескольких SNMP OID’ов
Системные требования для установки ZABBIX-сервера
Поддерживаемые платформы
| Платформа | ZABBIX-сервер | ZABBIX-агент |
|---|---|---|
| AIX | Поддерживается | Поддерживается |
| FreeBSD | Поддерживается | Поддерживается |
| HP-UX | Поддерживается | Поддерживается |
| Linux | Поддерживается | Поддерживается |
| Mac OS X | Поддерживается | Поддерживается |
| Novell Netware | - | Поддерживается |
| OpenBSD | Поддерживается | Поддерживается |
| SCO Open Server | Поддерживается | Поддерживается |
| Solaris | Поддерживается | Поддерживается |
| Tru64/OSF | Поддерживается | Поддерживается |
| Windows NT 4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista | - | Поддерживается |
См. также
Напишите отзыв о статье "Zabbix"
Примечания
Ссылки
- во FreeBSD
- во FreeBSD
- = =
Отрывок, характеризующий Zabbix
– Вы? – сказал он. – Как счастливо!Наташа быстрым, но осторожным движением подвинулась к нему на коленях и, взяв осторожно его руку, нагнулась над ней лицом и стала целовать ее, чуть дотрогиваясь губами.
– Простите! – сказала она шепотом, подняв голову и взглядывая на него. – Простите меня!
– Я вас люблю, – сказал князь Андрей.
– Простите…
– Что простить? – спросил князь Андрей.
– Простите меня за то, что я сделала, – чуть слышным, прерывным шепотом проговорила Наташа и чаще стала, чуть дотрогиваясь губами, целовать руку.
– Я люблю тебя больше, лучше, чем прежде, – сказал князь Андрей, поднимая рукой ее лицо так, чтобы он мог глядеть в ее глаза.
Глаза эти, налитые счастливыми слезами, робко, сострадательно и радостно любовно смотрели на него. Худое и бледное лицо Наташи с распухшими губами было более чем некрасиво, оно было страшно. Но князь Андрей не видел этого лица, он видел сияющие глаза, которые были прекрасны. Сзади их послышался говор.
Петр камердинер, теперь совсем очнувшийся от сна, разбудил доктора. Тимохин, не спавший все время от боли в ноге, давно уже видел все, что делалось, и, старательно закрывая простыней свое неодетое тело, ежился на лавке.
– Это что такое? – сказал доктор, приподнявшись с своего ложа. – Извольте идти, сударыня.
В это же время в дверь стучалась девушка, посланная графиней, хватившейся дочери.
Как сомнамбулка, которую разбудили в середине ее сна, Наташа вышла из комнаты и, вернувшись в свою избу, рыдая упала на свою постель.
С этого дня, во время всего дальнейшего путешествия Ростовых, на всех отдыхах и ночлегах, Наташа не отходила от раненого Болконского, и доктор должен был признаться, что он не ожидал от девицы ни такой твердости, ни такого искусства ходить за раненым.
Как ни страшна казалась для графини мысль, что князь Андрей мог (весьма вероятно, по словам доктора) умереть во время дороги на руках ее дочери, она не могла противиться Наташе. Хотя вследствие теперь установившегося сближения между раненым князем Андреем и Наташей приходило в голову, что в случае выздоровления прежние отношения жениха и невесты будут возобновлены, никто, еще менее Наташа и князь Андрей, не говорил об этом: нерешенный, висящий вопрос жизни или смерти не только над Болконским, но над Россией заслонял все другие предположения.
Пьер проснулся 3 го сентября поздно. Голова его болела, платье, в котором он спал не раздеваясь, тяготило его тело, и на душе было смутное сознание чего то постыдного, совершенного накануне; это постыдное был вчерашний разговор с капитаном Рамбалем.
Часы показывали одиннадцать, но на дворе казалось особенно пасмурно. Пьер встал, протер глаза и, увидав пистолет с вырезным ложем, который Герасим положил опять на письменный стол, Пьер вспомнил то, где он находился и что ему предстояло именно в нынешний день.
«Уж не опоздал ли я? – подумал Пьер. – Нет, вероятно, он сделает свой въезд в Москву не ранее двенадцати». Пьер не позволял себе размышлять о том, что ему предстояло, но торопился поскорее действовать.
Оправив на себе платье, Пьер взял в руки пистолет и сбирался уже идти. Но тут ему в первый раз пришла мысль о том, каким образом, не в руке же, по улице нести ему это оружие. Даже и под широким кафтаном трудно было спрятать большой пистолет. Ни за поясом, ни под мышкой нельзя было поместить его незаметным. Кроме того, пистолет был разряжен, а Пьер не успел зарядить его. «Все равно, кинжал», – сказал себе Пьер, хотя он не раз, обсуживая исполнение своего намерения, решал сам с собою, что главная ошибка студента в 1809 году состояла в том, что он хотел убить Наполеона кинжалом. Но, как будто главная цель Пьера состояла не в том, чтобы исполнить задуманное дело, а в том, чтобы показать самому себе, что не отрекается от своего намерения и делает все для исполнения его, Пьер поспешно взял купленный им у Сухаревой башни вместе с пистолетом тупой зазубренный кинжал в зеленых ножнах и спрятал его под жилет.
Подпоясав кафтан и надвинув шапку, Пьер, стараясь не шуметь и не встретить капитана, прошел по коридору и вышел на улицу.
Тот пожар, на который так равнодушно смотрел он накануне вечером, за ночь значительно увеличился. Москва горела уже с разных сторон. Горели в одно и то же время Каретный ряд, Замоскворечье, Гостиный двор, Поварская, барки на Москве реке и дровяной рынок у Дорогомиловского моста.
Путь Пьера лежал через переулки на Поварскую и оттуда на Арбат, к Николе Явленному, у которого он в воображении своем давно определил место, на котором должно быть совершено его дело. У большей части домов были заперты ворота и ставни. Улицы и переулки были пустынны. В воздухе пахло гарью и дымом. Изредка встречались русские с беспокойно робкими лицами и французы с негородским, лагерным видом, шедшие по серединам улиц. И те и другие с удивлением смотрели на Пьера. Кроме большого роста и толщины, кроме странного мрачно сосредоточенного и страдальческого выражения лица и всей фигуры, русские присматривались к Пьеру, потому что не понимали, к какому сословию мог принадлежать этот человек. Французы же с удивлением провожали его глазами, в особенности потому, что Пьер, противно всем другим русским, испуганно или любопытна смотревшим на французов, не обращал на них никакого внимания. У ворот одного дома три француза, толковавшие что то не понимавшим их русским людям, остановили Пьера, спрашивая, не знает ли он по французски?
Пьер отрицательно покачал головой и пошел дальше. В другом переулке на него крикнул часовой, стоявший у зеленого ящика, и Пьер только на повторенный грозный крик и звук ружья, взятого часовым на руку, понял, что он должен был обойти другой стороной улицы. Он ничего не слышал и не видел вокруг себя. Он, как что то страшное и чуждое ему, с поспешностью и ужасом нес в себе свое намерение, боясь – наученный опытом прошлой ночи – как нибудь растерять его. Но Пьеру не суждено было донести в целости свое настроение до того места, куда он направлялся. Кроме того, ежели бы даже он и не был ничем задержан на пути, намерение его не могло быть исполнено уже потому, что Наполеон тому назад более четырех часов проехал из Дорогомиловского предместья через Арбат в Кремль и теперь в самом мрачном расположении духа сидел в царском кабинете кремлевского дворца и отдавал подробные, обстоятельные приказания о мерах, которые немедленно должны были бытт, приняты для тушения пожара, предупреждения мародерства и успокоения жителей. Но Пьер не знал этого; он, весь поглощенный предстоящим, мучился, как мучаются люди, упрямо предпринявшие дело невозможное – не по трудностям, но по несвойственности дела с своей природой; он мучился страхом того, что он ослабеет в решительную минуту и, вследствие того, потеряет уважение к себе.
Он хотя ничего не видел и не слышал вокруг себя, но инстинктом соображал дорогу и не ошибался переулками, выводившими его на Поварскую.
По мере того как Пьер приближался к Поварской, дым становился сильнее и сильнее, становилось даже тепло от огня пожара. Изредка взвивались огненные языка из за крыш домов. Больше народу встречалось на улицах, и народ этот был тревожнее. Но Пьер, хотя и чувствовал, что что то такое необыкновенное творилось вокруг него, не отдавал себе отчета о том, что он подходил к пожару. Проходя по тропинке, шедшей по большому незастроенному месту, примыкавшему одной стороной к Поварской, другой к садам дома князя Грузинского, Пьер вдруг услыхал подле самого себя отчаянный плач женщины. Он остановился, как бы пробудившись от сна, и поднял голову.
2 Сервер
Обзор
Zabbix сервер - центральный процесс программного обеспечения Zabbix.
Сервер выполняет опрос и отлов данных, вычисляет триггеры, отправляет оповещения пользователям. Он является центральным компонентом, которому Zabbix агенты и прокси сообщают данные о доступности и целостности систем. Сервер может самостоятельно удаленно проверять сетевые службы (такие как веб-сервера и почтовые сервера), используя простые проверки сервисов.
Сервер является главным хранилищем, в котором хранятся все конфигурационные, статистические и оперативные данные, так же он рассылает уведомления администраторам в случае возникновения проблем с любой из наблюдаемых систем.
Функционал базового Zabbix сервера разделен на три отдельных компонента; это: Zabbix сервер, веб-интерфейс и хранилище в базе данных.
Все данные о конфигурации Zabbix хранятся в базе данных, с которой взаимодействует и сервер и веб-интерфейс. Например, когда вы создаете новый элемент данных используя веб-интерфейс (или API), запись об этом добавляется в таблицу элементов данных в базе данных. Затем, раз в минуту Zabbix сервер опрашивает таблицу элементов данных для получения списка активных элементов данных, и сохраняет этот список в кэш Zabbix сервера. Именно поэтому любые изменения в веб-интерфейсе Zabbix будут отображены в разделе последних данных с задержкой до двух минут.
Процесс сервера
Если установлен из пакета
Zabbix сервер работает как демон. Для запуска сервера выполните:
Shell> service zabbix-server start
Эта команда будет работать на большинстве GNU/Linux системах. На других системах вам, возможно, потребуется выполнить:
Shell> /etc/init.d/zabbix-server start
Аналогично, для остановки/перезапуска/просмотра состояния, используйте следующие команды:
Shell> service zabbix-server stop shell> service zabbix-server restart shell> service zabbix-server status
Запуск вручную
Если выше приведенные команды не работают, вам необходимо запустить сервер вручную. Найдите путь к бинарному файлу zabbix_server и выполните:
Shell> zabbix_server
Можно использовать следующие параметры командной строки с Zabbix сервером:
C --config <файл> абсолютный путь к файлу конфигурации (по умолчанию /usr/local/etc/zabbix_server.conf) -R --runtime-control <опция> выполнение административных функций -h --help вывод этого сообщения помощи -V --version вывод номера версии
Выполнение административных функций не поддерживается в OpenBSD и NetBSD.
Примеры запуска Zabbix сервера с параметрами командой строки:
Shell> zabbix_server -c /usr/local/etc/zabbix_server.conf shell> zabbix_server --help shell> zabbix_server -V
Управление работой
Опции управления работой:
| Опция | Описание | Цель |
|---|---|---|
| config_cache_reload | Перезагрузка кэша конфигурации. Игнорируется, если кэш уже загружается в текущий момент времени. | |
| housekeeper_execute | Запуск процедуры очистки базы данных. Игнорируется, если процедура очистки выполняется в данный момент. | |
| log_level_increase[=<цель >] | Увеличение уровня журналирования, действует на все процессы, если цель не указана. | pid
- Идентификатор процесса (1 до 65535) тип процесса - Все процессы указанного типа (например, poller) тип процесса,N - Тип процесса и номер (например, poller,3) |
| log_level_decrease[=<цель >] | Уменьшение уровня журналирования, действует на все процессы, если цель не указана. |
Допустимый диапазон PID изменения уровня журналирования одного процесса с 1 до 65535. На системах с PID > 65535 как вариант решения для изменения уровня журналирования отдельных процессов (например, "history syncer,6") можно использовать опцию <тип процесса,N>.
Пример использования административных функций для перезагрузки кэша конфигурации сервера:
Shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload
Пример использования административных функций для вызова выполнения очистки базы данных:
Shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute
Примеры использования административных функций по изменению уровня журналирования:
Увеличение уровня журналирования по всем процессам: shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase Увеличение уровня журналирования у второго процесса поллера: shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2 Увеличение уровня журналирования у процесса с PID 1234: shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234 Уменьшение уровня журналирования по всем http поллер процессам: shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"
Пользователь процесса
Zabbix сервер спроектирован для запуска от непривилегированного пользователя (non-root). Он будет работать от любого непривилегированного пользователя от которого был запущен. Таким образом, вы можете запускать сервер от имени любого непривилегированного пользователя, без каких либо последствий.
Если вы попытаетесь запустить сервер от "root", сервер сразу переключится на пользователя "zabbix", который должен присутствовать в вашей системе. Единственный способ запустить сервер от пользователя "root" - соответствующим образом отредактировать параметр "AllowRoot" в файле конфигурации сервера.
Если Zabbix сервер и агент работают на одном сервере, то рекомендуется использовать разных пользователей для запуска сервера и для запуска агента. В противном случае, если сервер и агент запущены под одним пользователем, агент будет иметь доступ к файлу конфигурации сервера и любой пользователь с правами Администратора в Zabbix может с легкостью получить, например, пароль от базы данных.
Файл конфигурации
Скрипты запуска
Скрипты используются для автоматического запуска/остановки процессов Zabbix при включении/выключении системы. Скрипты находятся в директории misc/init.d.
Поддерживаемые платформы
В связи с требованиями безопасности и критически важного характера работы сервера, UNIX является единственной операционной системой, которая может обеспечить необходимую производительность, отказоустойчивость и гибкость. Zabbix работает с ведущими на рынке версиями операционных систем.
Zabbix сервер протестирован на следующих платформах:
Также Zabbix может работать и на других Unix-подобных операционных системах.
Региональные настройки (локаль)
Обратите внимание, что сервер требует UTF-8 локаль, чтобы некоторые текстовые элементы данных интерпретировались корректно. Большинство современных Unix-подобных систем уже имеют локаль UTF-8 по умолчанию, тем не менее, есть некоторые системы где это необходимо указывать вручную.
Доброго
времени суток. В данную серию статей я хочу посвятить одной из
замечательных систем мониторинга - zabbix. По долгу службы пришлось мне
искать систему мониторинга. Я останавливался на nagios, cacti, mrtg. Но
они мне не подошли. И вот я нашел zabbix. Ознакомившись с документацией,
я понял, что zabbix - это то, что надо...
И
так, что же такое zabbix? Zabbix - это система распределенного
мониторинга, которая позволяет мониторить многочисленные параметры сети и
узлов сети. Zabbix распространяется под лицензией GPL, а это означает -
она бесплатна.
Возможности zabbix
Как я уже говорил выше, zabbix обладает огромными возможностями, а конкретно:- мониторинг доступности
- мониторинг по SNMP
- мониторинг по IPMI
- мониторинг по JMX
- собственная настройка порогов срабатывание проблемы
- настройка оповещений
- группировка по хостам, по собираемым данным
- использование шаблонов
- система прав доступа
- и многое другое
Подготовка к установке zabbix
Сразу хочу отметить, что установку я буду производить на Linux, а точнее на Ubuntu Server.Установку я буду производить из исходников. Поэтому давайте в начале скачаем исходный код Zabbix с . Разархивируем скачанный архив. Для этого переходим в директорию с архивом и вводим комманду:
$ tar -zxvf zabbix-2.0.0.tar.gz
Отлично. Следующим этапом необходимо подготовить нашу систему к установке zabbix. Нам понадобятся следующие пакеты:
- snmp
- libsnmp-dev
- snmpd
- libcurl4-openssl-dev
- fping
Если данные пакеты не установлены в системе, установим их:
sudo apt-get install snmp libsnmp-dev snmpd libcurl4-openssl-dev fping
После того как все необходимые пакеты установлены, необходимо создать группу zabbix и пользователя zabbix:
groupadd zabbix
useradd -g zabbix zabbix
Теперь нужно подготовить базу данных. Zabbix может работать как с MySQL, так и с PostgreSQL. (поддерживает и другие, Вы можете ознакомиться в официальной документации). Производитель рекомендует использовать в качестве сервера базы данных PostgreSQL, если Вы собираетесь мониторить более 50 узлов.
Но я использую MySQL и на данный момент у меня на мониторинге стоит 123 узла - пока проблем не наблюдал. В дальнейшем планируется увеличение узлов, тогда и посмотрим. И так, создаем базу данных в MySQL:
shell> mysql -u <имя пользователя> -p
<пароль>
mysql> create database zabbix character set utf8
mysql> quit
Теперь заходим в директорию с разархивированными исходниками zabbix. В ней в директории./database/mysql/ находятся три файла:
- schema.sql
- images.sql
- data.sql
mysql -u <пользователь> -p < schema.sql
или из самого mysql:
mysql>use zabbix
mysql>source schema.sql
По аналогии запускаем и остальные файлы images.sql и data.sql
Порядок обязателен.
Все на этом этап подготовки к установке завершен. Теперь можно приступить к самой установке zabbix.
Установка мониторинга zabbix
Переходим в директорию с кодом zabbix и запускаем:sudo ./configure --enable-server --enable-agent --with-mysql --with-net-snmp --with-libcurl
Мы подключаем сам zabbix сервер, zabbix агент, поддержку snmp.
Если все прошло хорошо (а об ошибках с которыми я столкнулся и как их решить я опишу ниже) запускаем установку:
sudo make install
На этом установка завершена. Осталось произвести небольшую конфигурацию сервера и агента zabbix.
Первоначальная настройка zabbix
Для работы zabbix сервера необходимо произвести первоначальные настройки. Открываем файл конфигурации /usr/local/etc/zabbix_server.conf (так в Ubuntu) и редактируем его:DBName=[имя базы данных, у меня zabbix]
DBUser = [имя пользователя доступа к MySQL]
DBPassword = [пароль доступа к базе данных]
Вот в принципе и все. Если у Вас MySQL настроен по умолчанию, то все должно заработать.
Теперь настроим агент zabbix. Если zabbix агент находится на той же машине, где и zabbix сервер, то ничего менять не надо. Если же zabbix агент находиться на другой машине, то открываем /usr/local/etx/zabbix_agentd.conf ищем строку Server=127.0.0.1 и заменяем на Server=[адрес zabbix сервера]
Вот и все. Запускаем zabbix сервер и агент командами:
zabbix_server
zabbix_agentd
Пришло время к установке web интерфейса для zabbix.
Установка web интерфейса zabbix
Создаем виртуальный хост zabbix, как это сделать я писал в своей статье про . Копируем в директорию созданного виртуального хоста файлы из директории с zabbix/frontends/phpЗаходим на наш хост. Тут нужно немного подправить наш php.ini согласно требованиям zabbix.
- memory_limit - задает максимальную величину использования памяти скриптом
- post_max_size - устанавливает максимальный размер данных передаваемых методом POST
- upload_max_filesize - максимальный размер загружаемого файла
- max_execution_time - время выполнения скрипта
- max_input_time - максимальное время в секундах, в течение которого скрипт должен разобрать все входные данные
- timezone - в php.ini date.timezone, устанавливает часовой пояс
- datebase support - тип базы данных
- bcmath - вычисления с произвольной точностью
- mbstring - работа с многобайтными строками
- sockets - работа с сокетами
- gd - графическая библиотека
- и др.
После того как все требования zabbix будут удовлетворены, можно перейти к следующему шагу.
На этом шаге нам надо выбрать тип базы данных (в моем случае это MySQL), укаазать адрес сервера (у меня localhost), название базы данных (для моего случае это zabbix), логин и пароль для доступа к базе данных:
На этом установка завершена.
Давайте рассмотрим проблемы с которыми я столкнулся при установке zabbix и как их решить.
Проблемы возникающие при установке zabbix и их решение
Во время установки мониторинга я столкнулся с двумя ошибками:
- При выполнении configure у меня выскочила ошибка “MySQL library not found”. Решается данная проблема легко, путем установки libmysqlclient16-dev
- Вторая ошибка выскочила при выполнении make install “The programm ‘make’ is currently not installed”. Тут все просто, у меня не установлена программа make.
А на этом я завершаю статью, посвященную установке мониторинга zabbix. В следующей статье мы познакомимся с основными понятиями, затем разберем интерфейс и перейдем к настройке мониторинга хостов (устройств нашей сети). Так, что следите за выходом новых статей.
Примеры применения
31.10.2018При выборе системы мониторинга ИТ-инфраструктуры предприятия нужно учесть ряд факторов: в первую очередь оценить соответствие функционала системы мониторинга вашим техническим и бизнес-требованиям и рассмотреть особенности развёртывания и сопровождения, чтобы подобрать инструмент, соответствующий вашей инфраструктуре и уровню компетенции ИТ-специалистов.
В этой статье мы рассмотрим особенности, различия и схожие черты двух популярных систем мониторинга Zabbix vs Nagios .
Краткий обзор продуктов
Использование систем мониторинга с оборудованием NetPing
Ранее в нашем блоге мы неоднократно рассматривали возможность использования систем мониторинга Zabbix и Nagios с и компании .
Процесс подключения устройств к системам мониторинга рассматривается в следующих статьях:
Процесс организации мониторинга при помощи интеграции устройств и систем мониторинга Zabbix и Nagios рассматривается в статьях:
Процесс организации отправки пользовательских сообщений о событиях из систем мониторинга Zabbix или Nagios посредством SMS-сообщений с использованием GSM-модема встроенного в устройства рассматривается в статьях:
Также в нашем блоге доступны для более удобного добавления устройств к мониторингу в системе Zabbix и другие статьи о практическом применении интеграции системы мониторинга Zabbix с устройствами :
- Карта пользователя и уведомления от устройств NetPing в Zabbix
Достоинства и недостатки
Zabbix
Достоинства | Недостатки |
|---|---|
Полностью бесплатный. | Мониторинг серверов и рабочих станций осуществляется через постоянно запущенный агент. |
Конфигурирование через web-интерфейс и с помощью API. | Все данные мониторинга хранятся в базе, что в крупных сетях требует выделения дополнительных вычислительных мощностей для обслуживания базы данных. |
Вся конфигурация хранится в базе, управляется через web-интерфейс. | Не обеспечивается отказоустойчивость. |
Единая точка доступа для пользователей. | |
Разграничение доступа к данным и конфигурации. | |
Минимальный интервал между замерами – 1 секунда. | |
С серверов собираются не результаты проверок (сломалось или нет), а количественные характеристики работы, которые анализируются на стороне сервера. | |
Время хранения данных ограничено лишь дисковым пространством. | |
Развитые возможности анализа собранных данных. |
Nagios
Достоинства | Недостатки |
|---|---|
Простой формат конфигурационного файла. При наличии минимального опыта в программировании можно писать собственные плагины для Nagios. | Нет возможности конфигурирования через web-интерфейс (для бесплатной версии). Все изменения конфигурации выполняются правкой файлов конфигурации с последующим полным перезапуском сервера Nagios (~10-15 минут). |
Позволяет оставлять комментарии с меткой времени. | Слишком большой интервал между проверками и замерами параметров. |
Существуют плагины на все случаи жизни от сторонних производителей. |
- Перевод
Тех, кто использует или собирается использовать 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 БД | Zabbix proxies | SAN |
|---|---|---|---|
| HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 16GB memory 128GB disk CentOS 6.2 x64 Zabbix 2.0.6 |
HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 32GB memory 2TB SAN-backed storage (4Gbps FC) CentOS 6.2 x64 MySQL 5.6.12 |
VMware Virtual Machine 4x vCPU 8GB memory 50GB disk CentOS 6.2 x64 Zabbix 2.0.6 MySQL 5.5.18 |
Hitachi Unified Storage VM 2x 2TB LUN Tiered storage (with 2TB SSD) |
Отказоустойчивость Zabbix server
Вернемся к архитектурным вопросам, что я озвучивал выше. В больших сетях по понятным причинам не работающий мониторинг является настоящей катастрофой. Однако, архитектура Заббикса не позволяет запускать больше одного экземпляра процесса zabbix server.Поэтому я решил воспользоваться Linux HA с Pacemaker и CMAN. Для базовой настройки прошу глянуть мануал RedHat 6.4 . К сожалению, инструкция была изменена с момента, как я ее использовал, однако конечный результат должен получиться таким же. После базовой настройки дополнительно я настроил:
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
- Всегда легко найти какой сервер активен
- Все соединения от Zabbix сервера всегда с одного и того же IP (После установки параметра SourceIP= в zabbix_server.conf)
- Всем Zabbix-прокси и Zabbix-агентам в качестве сервера просто указывается общий IP
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует три преимущества:
- Процесс zabbix_server
- в случае фейловера zabbix_server будет остановлен на старом сервере и запущен на новом
- Symlink для заданий cron
- Симлинк указывает на директорию, в которой лежат задания, которые должны выполняться только на активном Zabbix-сервере. Crontab должен иметь доступ ко всем задания через этот симлинк
- В случае фейловера симлинк удаляется на старом сервере и создается на новом
- crond
- В случае фейловера crond останавливается на старом сервере и запускается на новом активном сервере
Отказоустойчивость СУБД
Очевидно, что никакой пользы от отказоустойчивости серверов с Zabbix-серверами, если база данных может упасть в любой момент. Для MySQL есть огромное количество путей создать кластер, я расскажу о способе, что я использовал.Я также использовал Linux HA с Pacemaker и CMAN и для базы данных. Как оказалось, в нем есть пару отличный возможностей для управления репликацией MySQL. Я использую (использовал, смотри раздел «открытые проблемы») репликацию для синхронизации данных между активным(master) и резервным(slave) MySQL. Для начала, точно также как и для серверов Zabbix-сервера, мы делаем базовую настройку кластера. Затем в дополнении я настроил:
- Общий IP-адрес (shared IP address)
- В случае фейловера, IP-адрес переходит на сервер, который становится активным
- Так как общий IP-адрес всегда используется активным Zabbix-сервером, то отсюда следует два преимущества:
- Всегда легко найти, какой сервер активен
- В случае фейловера, на самом Zabbix-сервере не требуется никаких действий, чтобы указать адрес нового активного сервера MySQL
- Общий дополнительный (slave) IP-адрес
- Этот IP-адрес может использоваться, когда к происходит запрос на чтение к базе. Таким образом, запрос может обработать slave-сервер MySQL, если он доступен
- дополнительный адрес может быть у любого из серверов, это зависит от следующего:
- если slave-сервер доступен, и часы не отстают на более чем 60 секунд, то адрес будет у него
- В обратном случае адрес будет у master-сервера MySQL
- mysqld
- В случае фейловера новый сервер MySQL станет активным. Если после этого старый сервер вернется в строй, то он останется slave для уже новоиспечённого master.
Zabbix-прокси
Если по какой-то причине вы не слышали о Zabbix-прокси, то, пожалуйста, срочно посмотрите в документации . Прокси позволяют Заббиксу распределить нагрузку мониторинга на несколько машин. После этого уже каждый Заббикс прокси отсылает все собранные данные на Заббикс сервер.Работая с Заббикс прокси важно помнить:
- Заббикс прокси способны обрабатывать очень серьезные объемы данных, если их настроить как следует. Так, например, во время тестов, прокси (назовем ее Proxy А) обрабатывала 1500-1750 NVPS без каких либо проблем. И это виртуалка с двумя виртуальными ЦПУ, 4ГБ ОЗУ и БД SQLite3. При этом прокси находилась на одной площадки с самим сервером, так что задержки на сети можно было просто не учитывать. Также почти все, что собиралась, было активными элементами данных Заббикс агента
- Ранее я уже упоминал, как важна задержка на сети при мониторинге. Так вот, это действительно так, когда речь идет о крупных системах. Фактически, количество данных, которое может отослать прокси, не отставая, напрямую зависит от сети.
На графике ниже хорошо видно как накапливаются проблемы, когда задержка сети не учитывается. Прокси, который не успевает:
Пожалуй, достаточно очевидно, что очередь из данных для передачи не должна увеличиваться. График относится к другому Заббикс-прокси (Proxy B), которая ничем по железу не отличается от Proxy A, но может передавать без проблем только 500NVPS а не 1500NVPS, как Proxy A. Отличие как раз в том, что B находится в Сингапуре а сам сервер в Северной Америке, и задержка между площадками порядка 230мс. Данная задержка имеет серьезный эффект, учитывая способ пересылки данных. В нашем случае, Proxy B может отправить только по 1000 собранных элементов Заббикс серверу каждые 2-3 секунды. По моим наблюдениям, вот что происходит:
- Прокси устанавливает соединение до сервера
- Прокси максимум отправляет за раз 1000 собранных значений элементов данных
- Прокси закрывает соединение
- Первичное подключение очень медленное. В моем случае оно происходит за 0,25 секунды. Уф!
- Так как соединение закрывается после отправки 1000 элементов данных, то TCP-соединение никогда не длится достаточно долго, чтобы успеть использовать всю доступную пропускную способность канала.
Производительность базы данных
Высокая производительность базы данных является ключевой для системы мониторинга, так как абсолютно вся собранная информация попадает туда. При этом, с учетом большого количества операций записи в базу, производительность дисков - это первое бутылочное горлышко с которым сталкиваешься. Мне повезло и у меня в распоряжении оказались SSD-диски, однако все равно это не является гарантией быстрой работы базы. Вот пример:- Изначально в системе я использовал MySQL 5.5.18. Сначала никаких видимых проблем с производительностью не наблюдалось, однако, после 700-750 NVPS MySQL стал загружать процессор на 100% и система буквально «замерла». Дальнейшие мои попытки исправить ситуацию, подкручивая параметры в конфигурационном файле, активируя large pages или partitioning ни к чему не привели. Более хорошее решение предложила моя жена: сначала обновиться MySQL до 5.6 и потом разбираться. На мое удивление, простой апдейт решил все проблемы с производительностью, который я никак победить в 5.5.18. На всякий случай, вот копия my.cnf .
Обратите внимание, что больше всего запросов «Com_update». Причина кроется в том, что каждое полученное значение влечет Update в таблицу «items». Также в базе данных в основном операции на запись, так что MySQL query cache никак не поможет. По сути, он может быть даже вредным для производительности, учитывая, что постоянно придется маркировать запросы как неверные.
Другой проблемой для производительности может стать Zabbix Housekeeper. В больших сетях его настоятельно рекомендую отключать. Для этого в конфиг-файле выставите DisableHousekeeping=1. Понятно, что без Housekeeping старые данные(элементы данных, события, действия) не будут удаляться из базы. Тогда удаление можно организовать через partitioning.
Однако, одно из ограничений MySQL 5.6.12 в том, что partitioning не может быть использован в таблицах с foreign keys и как раз они присутствуют почти повсеместно в базе Заббикс. Но кроме таблиц history, которые нам и нужны. Partitioning дает нам два преимущества:
- Все исторические данные таблицы разбитые по днем/неделям/месяцам/и т.д. могут находиться в отдельных файлах, что позволяет в дальнейшем удалять данные без каких либо последствий для базы. Также очень просто понимать сколько данных собирается за определенный период времени.
- После очистки таблиц InnoDB не возвращает место диску, оставляя его себе для новых данных. В итоге с InnoDB невозможно очистить место на диске. В случае с 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
{Hostname:zabbix.proxy.items.sync.remaining.min(10m)}>100000
Итого статистика
Напоследок предлагаю графики загрузки системы. Сразу говорю, что не знаю, что произошло 16 июля - мне пришлось пересоздать все базы прокси (SQLite на тот момент), чтобы решить проблему. С тех пор я перевел все прокси на MySQL и проблема не повторялась. Остальные «неровности» графиков совпадают со временем проведения нагрузочного тестирования. В целом, из графиков видно, что у используемого железа большой запас прочности.
А вот графики с сервера базы данных. Приросты трафика каждый день соответствуют времени снятия дампа(mysqldump). Также провал 16 июля на графике запросов(qps) относится к той же проблеме, что я описывал выше.
Управление
Итого в системе используется 2 сервера под Zabbix-сервера, 2 сервера под MySQL, 16 виртуальных серверов под Zabbix-прокси и тысячи наблюдаемых серверов с Zabbix-агентами. При таком количестве хостов о внесении изменений руками не могло быть и речи. И решением стал Git-репозиторий, к которому имеют доступ все сервера, и где я расположил все конфигурационные файлы, скрипты, и все остальное, что нужно распространять. Далее, я написал скрипт, который вызывается через UserParameter в агенте. После запуска скрипта сервер подключается к Git-репозиторию, скачивает все необходимые файлы и обновления и затем перезагружает Zabbix-агента/прокси/сервера, если конфиг-файлы имели изменения. Обновление стало не сложнее, чем запустить zabbix_get!Открытые проблемы
Несмотря на все усилия, которые я приложил, осталась одна существенная проблема, которую мне только предстоит решить. Речь о том, что когда система достигает 8000-9000NVPS, то резервная база MySQL больше не успевает за основной, таким образом никакой отказоустойчивости на самом деле и нет.У меня есть идеи, как данную проблему можно решить, но еще не было времени это имплементировать:
- Использовать Linux-HA с DRBD для partitioning БД.
- LUN-репликация на SAN с репликацией на другой LUN
- Percona XtraDB cluster. В версии 5.6 еще недоступен, так что с этим придется подождать(как я писал, были проблемы с производительностью в MySQL 5.5)
