Pull to refresh

Универсальная система мониторинга Zabbix — введение

Reading time 4 min
Views 407K
LogoВ любой сети, где есть больше, чем один сервер, очень полезно бывает иметь перед глазами полную картину происходящего. В крупных сетях, где количество хостов переваливает за несколько десятков, следить за каждым в отдельности — непосильная задача для администраторов. Для облегчения задачи наблюдения применяются системы мониторинга, и я расскажу об одной из них, которой на Хабре не посвящено ни одной полноценной статьи.

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

Zabbix состоит из
  • собственно сервера мониторинга, который выполняет периодическое получение данных, обработку, анализ и запуск скриптов оповещения
  • базы данных (MySQL, PostgreSQL, SQLite или Oracle)
  • веб-интерфейса на PHP
  • агента — демона, который запускается на отслеживаемых объектах и предоставляет данные серверу. Агент опционален, мониторинг можно производить не только с помощью него, но и по SNMP (версий 1, 2, 3), запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как ping, запрос по http, ssh, ftp и другим протоколам, а так же замер времени ответа этих сервисов.


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

Основная логическая единица — Узлы сети (host), сервера, находящиеся под наблюдением. Каждому серверу присваивается описание и адрес (dns или ip, можно оба, причем с возможностью выбирать, что использовать для соединения).



Узлы объеднияются в группы, например веб-сервера или сервера баз данных. Группы служат для вывода только определенных серверов при наблюдении.



Каждый узел имеет несколько Элементов данных (items) — параметров, за которыми ведется мониторинг. К примеру, на всех серверах у меня есть параметр ping, (он получается с помощью встроенной проверки), который равняется 1, если ответ на последний ping-запрос был получен, иначе 0. А на одном из серверов у меня есть параметр «количество пользователей онлайн», который собирается самописным скриптом из базы данных сайта. Для каждого элемента данных можно указать свой период обновления, способ хранения(сам параметр или скорость его изменения), множитель, временной интервал сбора (например только в рабочее время).



Создавать элементы данных для каждого из множества серверов — сложно, поэтому можно создать узлы-шаблоны. Эти узлы тоже содержат элементы данных, но они не мониторятся напрямую. Вместо этого реальный хост связывается с одним или несколькими шаблонами, и все параметры шаблона автоматически наследуются хостом. Так, элемент ping у меня хранится именно в шаблоне, и я просто связываю все хосты с шаблоном template_ping.



Человек — не робот, и следить за тысячами параметров и думать, не выходит ли это значение за допустимые границы, просто нереально. Но и тут Zabbix предоставляет гибкие возможности по настройке условий-триггеров, которые включаются при авариях и неполадках, и система начинает моргать лампочками (на самом деле красными квадратиками) и изо всех сил пытается показать администратору, что что-то случилось. Между прочим, при включении триггера веб-интерфейс даже начинает попискивать на манер будильника, наверное, чтобы разбудить заснувших на клавиатуре наблюдателей. :) Так что колонки здесь, наверное не помешают. А в упомянутом выше моем шаблоне template_ping есть и триггер, который реагирует на отсутствие пинга больше, чем на две минуты.



А если администратора нет на месте? Ничего, Zabbix достаточно самостоятелен и сможет отправить уведомление на почту, в jabber или sms с помощью gsm-модема, или даже попытаться самостоятельно поднять упавший сервис, выполнив заранее определенные действия, которые запускаются при срабатывании определенных триггеров.



Скучно сидеть и вглядываться в квадратики и бесконечно бегающие цифры? По данным любого параметра система сможет построить график изменения, причем не за предопределенные и жестко заданные временные интервалы (вспомните mrtg/rrdtool: daily, weekly, monthly, yearly), а за любой промежуток времени с максимальным разрешением. Хотите посмотреть в деталях, как изменялась нагрузка на сервер во время хабраэффекта месяц назад? Пожалуйста, график с разрешением в 30 секунд(именно таков интервал опроса по умолчанию) к вашим услугам. Хотите общую картину? Выберите интервал в месяц и посмотрите на среднюю величину, и разброс колебаний до максимума и минимума. Сравнить? Можно создавать сложные графики, отображающие на одном поле несколько параметров, и вы сразу увидите, что пиковые значения Load Average соответствуют пикам трафика.



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



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



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

Скриншоты — с официального сайта Zabbix, и остальные можете посмотреть именно там (а их там много) — http://www.zabbix.com/screenshots.php

В ближайшем будущем — о том, как использовать Zabbix вместо Nagios и MRTG и рекомендации по миграции на Zabbix с этих двух систем и сравнение преимуществ и недостатков; о написании собственных скриптов оповещения и сбора данных, о моём личном опыте использования Zabbix в продакшне, и о чем-нибудь еще, что я узнаю в процессе дальнейшего изучения этой замечательной системы.
Tags:
Hubs:
+33
Comments 74
Comments Comments 74

Articles