Мониторинг linux сервера с помощью zabbix

Мониторинг серверов с помощью Zabbix

Думаете, создание больших служб мониторинга — утомительное занятие? Как бы не так, если вы выбрали Zabbix. С ним можно быстро и легко поднять мониторинг больших систем.

Zabbix ( www.zabbix.com ) — это проект с открытым исходным кодом, но разработчики также предлагают и коммерческую поддержку. Zabbix поддерживает платформы UNIX, Linux, BSD, Mac OS X и Windows и рассчитан на большие системы. Zabbix создан Алексеем Владышевым и его компанией Zabbix SIA. Эта статья написана, когда Zabbix был версии 1.8.1, выпущенной в январе 2010 года. В момент написания статьи в большинстве дистрибутивов Linux в репозиториях содержалась предыдущая версия (1.6). Версия 1.8 существенно от нее отличается, и в этой статье будут упомянуты все основные функции. Вот их краткий список:

• Распределенный мониторинг.
• Клиенты для платформ Linux, BSD, Windows, Mac OS X и коммерческих UNIX.
• Бэкенд в виде базы данных (MySQL, Oracle, PostgreSQL или SQLite).
• Режим автоматического обнаружения.
• Веб-интерфейс.
• Оповещения по электронной почте, SMS или Jabber.
• Поддержка как методов получения сообщений Zabbix-клиента — как poll, так и trap.
• Поддержка SNMP.
• Безагентный мониторинг (пинги, проверка портов и т.п.).
• Графики.

Хотя рекомендуется устанавливать Zabbix из репозитория вашего дистрибутива Linux, но я соберу Zabbix версии 1.8.1 из исходников на Ubuntu 9.10, для серверной платформы, а бэкендом будет MySQL. Также покажу вам, как настроить Linux-клиента с базовыми функциями мониторинга Zabbix.

Программные требования

Если устанавливаете через графический менеджер пакетов, то имена пакетов — mysql-server, apache2, libapache2-mod-php5, php5-mysql, php5-gd, libmysqlclient15-dev, libsnmp-dev, libiksemel-dev и libcurl4-gnutls-dev.

Установка

Итак, мы собрали два бинарных агентских файла: zabbix_agentd и zabbix_agent. Последний предназначен для запуска агента из суперсервера, такого как inetd, а первый сам работает как демон. Рекомендуется использовать zabbix_agentd.

Настройка сервера и клиента

Zabbix хранит по отдельности настройки сервера и клиента. Примеры конфигурационных файлов лежат в каталоге zabbix-1.8.1/misc/conf. Создайте каталог /etc/zabbix, смените владельца на пользователя zabbix и скопируйте файлы zabbix_server.conf и zabbix_agentd.conf в этот каталог.

Нужно сделать совсем немного изменений в конфигурационные файлы, к тому же они очень хорошо самодокументированы. Главное, что нужно изменить, это два параметра в клиентском конфиге zabbix_agentd.conf, в строках Server= и Hostname= . Первый параметр задает адрес сервера, с которым нужно взаимодействовать, а второй определяет имя хоста клиента.

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

Инициализационные скрипты

В каталоге zabbix-1.8.1/misc/init.d расположено несколько примеров инициализационных скриптов. Скопируйте один из них в /etc/init.d и внесите соответствующие изменения. К примеру, для своей Ubuntu я взял скрипт из каталога debian. Как в серверном, так и в клиентском конфигурационных файлах мне пришлось изменить расположение бинарных файлов, с /home/zabbix/bin на /usr/local/sbin.

Веб-интерфейс Zabbix

Каталог zabbix-1.8.1/frontends/php содержит веб-интерфейс к Zabbix. Скопируйте эту структуру каталогов, например, в DocumentRoot веб-сервера Apache, и откройте соответствующий URL-адрес в своем веб-браузере. Перед вами должно открыться окно Zabbix Introduction (скриншот 1). Этот мастер проверит наличие всех необходимых зависимостей (время выполнения PHP, требования по памяти и т.п.), покажет лицензионное соглашение и проведет вас через все остальные шаги настройки сервера Zabbix.

По завершении конфигурации системы отобразится окно логина. По умолчанию имя пользователя — Admin с паролем zabbix. Конечно, сразу после входа вам нужно поменять этот пароль. Панель веб-интерфейса состоит из двух рядов (см. скриншот 2).

Выберите Administration, затем Users. Теперь справа в выпадающем списке выберите Users вместо User Groups. Щелкните по пользователю admin. Отобразится страница настройки пользователя Admin (см. скриншот 3). Сначала поменяйте пароль. Также нужно прописать правильный адрес e-mail (нажмите кнопку Add рядом с надписью Media), потому что в дальнейшем мы настроим оповещения на этот адрес.

Скриншот 3. Страница настроек пользователя Admin

Для удобства можно также поменять язык — выберите в правом верхнем углу Profile, и затем нужный язык.

Добавляем клиента

На клиентскую машину нужно скопировать три файла: клиентский исполняемый файл zabbix_agentd в /usr/sbin, конфигурационный файл zabbix_agentd.conf в /etc/zabbix и скрипт инициализации. Отредактируйте как того требуется zabbix_agentd.conf, в частности присвойте параметру Server= адрес вашего Zabbix-сервера, а параметру Hostname= — имя этой машины. После этого можно запустить Zabbix-агента через скрипт.

Вернитесь на веб-страницу Zabbix-сервера и выберите на панели Настройка (Configuration) → Узлы сети (Hosts). Теперь справа вверху нажмите кнопку Создать узел сети (Create Host). Появится экран Конфигурация узлов сети (Hosts configuration screen, см. скриншот 4). Можно задать вашему хосту любое имя, но я рекомендую оставить короткое имя хоста (то, которое выдается командой hostname -s ), а не полное доменное имя. Добавьте хост в группу Linux servers, а в поле DNS имя (DNS name) запишите полное доменное имя. Можно, конечно, выбрать мониторинг по IP-адресу, но я верю, что мой DNS всегда будет работать правильно. Последнее, что нужно сделать на этом экране — это нажать кнопку Добавить (Add) в секции Соединенные шаблоны (Linked templates). Отметьте галочкой Template_Linux и нажмите Выбрать (Select) в нижней части этого выпадающего окна. Вернувшись на экран Конфигурация узла сети, нажмите Сохранить (Save). На вашем клиенте будут мониториться все элементы данных и триггеры, которые присутствуют в шаблоне Template_Linux.

Скриншот 4. Конфигурация узлов сети

Структура мониторинга Zabbix начинается с Элементов данных (Items), они проверяют либо собирают данные. Затем идут триггеры (они отслеживают данные, храняющиеся в Элементах данных), а завершается цепочка Действиями (Actions) — e-mail, SMS или выполнение внешних скриптов.

Элементы данных (Items)

Элементы данных можно назвать «собирателями данных». Некоторые элементы данных уже встроены в бинарный файл агента, другие представляются пользовательскими скриптами. Сразу после установки Zabbix, вы сможете использовать большой набор всевозможных шаблонов, содержащих в себе элементы данных для проверки систем Linux, Solaris, MAC OS X и Windows.

Давайте взглянем на шаблон, который мы использовали с нашим первым клиентом. Введите «Template_Linux» в поле Поиск в правом верхнем углу веб-интерфейса. В результатах поиска вы увидите страницу со ссылками на Группы элементов данных, Элементы данных, Триггеры и Графики (Item Groups, Items, Triggers и Graphs) этого шаблона (см. скриншот 5). Нажмите на ссылку Элементы данных. Все эти элементы данных мониторятся на любом хосте, к которому применен шаблон Template_Linux.

Скриншот 5. Шаблон Template_Linux

Щелкните по элементу данных под названием Free disk space on /. Вы увидите подробности этого элемента данных (см. скриншот 6). Значение большинства полей интуитивно понятно. Самые важные среди них:

• Описание (Description): это поле описывает суть проверки, в свободной форме. Обратите внимание, что в этом поле присутствует переменная $1. Zabbix подставляет вместо этой переменной значение первого поля в ключе (будет описано далее).
• Тип (Type): тип Zabbix agent означает, что проверка будет выполнена самим агентом, работающим на клиенте, через определенные промежутки времени. Эта проверка встроена в исполняемый файл агента, примером таких проверок являются определение свободного пространства на диске, количество свободных/задействованных inode, либо внешний пользовательский скрипт. Другой тип элемента данных — Zabbix Trapper. Zabbix Trapper ведет себя как ловушка SNMP. Его значение обновляется только в том случае, когда клиент отправляет новые данные посредством утилиты zabbix_sender . К примеру, у вас есть задание cron, которое занимает 30 минут. По обычному сценарию, Zabbix-сервер бы ожидал ответа от клиента, выполняющего данный скрипт, и до этих пор не рвал бы соединение. Однако лучшим решением является добавление cron-задания так, чтобы программа zabbix_sender сама бы по получению нового значения отправляла бы его на Zabbix-сервер.

Также можно указать Zabbix’у, каков тип возвращаемых данных: текстовый, символьный или числовой, а также множитель для возвращаемого значения. Также вы можете указать, как долго будут сохраняться исторические данные и динамику изменений. В секции Группы элементов данных можно сгруппировывать схожие по смыслу проверки. К примеру, добавив элемент данных для проверки свободного места в другой точке монтирования, вы логично сможете добавить его в группу элементов данных Filesystem.

Triggers (Триггеры)

Щелкните по ссылке Триггеры (Triggers) в глобальных результатах поиска (скриншот 5). Триггер Zabbix отслеживает значения Элементов данных. Если значение превышает предопределенный порог, тогда ему назначается один из шести уровней важности. На скриншоте 7 отображены триггеры шаблона Template_Linux. Здесь отображены: уровень важности, статус, имя и выражение, которые, собственно, и составляет суть триггера.

Скриншот 7. Триггеры шаблона Template_Linux

Щелкните на триггере Low free disk space on Template_Linux volume /, и вы увидите окно Настройка триггеров (Configuration of Triggers) (см. скриншот 8).

Скриншот 8. Окно Настройка триггеров

Первое поле Имя (Name) должно описывать суть проблемы. К примеру, предложение «IMAP порт не отвечает на сервере123» вносит гораздо больше ясности, чем «Почта упала». Это тот текст, который вы захотите увидеть в электронном письме, на странице Zabbix или в SMS-сообщении, поэтому позаботьтесь о его ясности и информативности.

Поле Выражение (Expression) содержит имя наблюдаемого Элемента данных и граничное значение. К примеру, в данном случае выражение , что означает отслеживать машину с именем Template_Linux и его ключ vfs.fs.size[/,pfree] . Если последнее значение окажется меньше 10, тогда назначить триггеру важность Высокая (High). Нажмите Выбрать (Select). Здесь вы можете сменить выражение, по которому срабатывает триггер. Можно работать со средними, абсолютными значениями или максимальным значением за определенный период времени. Сейчас, однако, я оставлю триггер как есть, изменю лишь значение, по которому он срабатывает. Поэтому закрываем всплывающее окно Условие (Condition) и меняем граничное значение на 5% — изменяем в конце строки число 10 на 5. Сохраним изменения, нажав кнопку Сохранить (Save).

Действия (Actions)

Действия происходят при срабатывании триггера. Действием может быть сообщение электронной почты, SMS- или Jabber-сообщение, либо запуск внешнего скрипта. Давайте настроим отправку e-mail администратору (т.е. нам) в случае срабатывания любого триггера с важностью Чрезвычайная (Disaster). Выберите Настройка → Действия (Configuration → Actions), потом нажмите кнопку Создать действие (Create Action) в правой верхней части экрана. Появится окно Настройка действий (Configuration of Actions, см. скриншот 9). Введите в поле Имя (Name) что-нибудь информативное и нажмите кнопку Новый (New) в секции Условия действия (Action conditions). Выберите Важность триггера (Trigger severity) из появившейся секции Новое условие (New Condition) и поменяйте его значение с Информация (Information) на Чрезвычайная (Disaster). Нажмите кнопку Добавить (Add). Потом нажмите кнопку Новая (New) в другой секции — Операции действия (Action operations). Настройте отправку сообщений одному администратору Admin (см. скриншот 10). Нажмите Добавить (Add). Наконец, нажмите кнопку Сохранить (Save). Теперь при срабатывании любого триггера, важность которого установлена как Чрезвычайная, пользователю Admin будет отправлено электронное письмо. Можно создавать действия для отдельных триггеров и для отдельных хостов, а действие, которое мы только что создали, действует глобально. Не забывайте, что это всего лишь пример.

Скриншот 9. Окно Настройка действий
Скриншот 10. Настраиваем операции

Ежедневный мониторинг

Есть множество способов наблюдать за настроенными клиентами. По моему мнению, наиболее информативным окном является Мониторинг → Триггеры (убедитесь в том, что в выпадающих меню справа Группа (Group) и Узел сети (Host) выбрано все (all). В этом окне Zabbix показывает все активные триггеры, их уровень важности, дата последнего изменения (Возраст) и другие поля. Это окно можно рассматривать как список незавершенных дел системного администратора.

Источник

Мониторим всё: расширение агентов Windows и Linux при помощи скриптов

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

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

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

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

Нам оставили несколько стандартных интерфейсов для того, чтобы расширить возможности Заббикса по мониторингу серверов настолько, насколько позволит нам наша фантазия и наличие свободного времени на написание скриптов. Интерфейсы эти UserParameter и zabbix_sender. О первом и пойдет речь, а в качестве примеров будет показано как можно собирать состояние S.M.A.R.T жестких дисков и контролировать, когда кто-то удаляет или устанавливает новые программы на своей Windows-машине.

Немного матчасти

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

• Добавить в конце конфигурационного файла zabbix_agentd.conf строчку вида

где:

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

А вот сразу очень простой пример, который лежит в каждом стандартном конфиге для Linux:

Итак, ключ здесь system.test, а выполняем команду who | wc -l, которая возвращает нам количество открытых сессий в системе. Добавляем (или раскомментируем данную строчку если уже есть), идем дальше.

• В Веб-консоли Zabbix создать новый элемент данных с ключом, который мы использовали, если брать пример выше, то это system.test.

Для этого нажимаем «Создать элемент данных»

и затем выставляем ключ такой же, как указали в конфиг-файле, а тип Zabbix агент:

• Перезагрузить Zabbix агента, чтобы изменения в конфиг-файле вступили в силу

Наблюдаем результат в последних данных:

Мониторинг SMART через UserParameter

Пример выше имеет мало практического применения, учитывая, что уже итак существует стандартный ключ system.users.num, который делает ровно тоже самое.

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

Если нам интересно мониторить момент, когда пора планово менять жесткие диски, то есть два варианта:

1. Если диски за аппаратным RAID-контроллером, то, как правило, сами диски операционная система «не видит». Поэтому ищем способы как вытащить информацию о состоянии жестких дисков через утилиты или SNMP-сабагента, которые нам любезно предоставил(или не предоставил) производитель RAID-контроллера. Для каждой отдельной серии контроллеров свой путь до этой информации.
2. Если речь идет о просто рабочих станциях, серверах с софтовом RAID и т.д., то тогда к дискам есть доступ из операционной системы, и мы вольны использовать различные утилиты для чтения их статуса. В случае Zabbix нам подходит утилита smartctl, из пакета SMARTMONTOOLS.

В Debian установка SMARTMONTOOLS сводится к:

и утилита готова к использованию.

Для каждого диска, который есть в системе сначала проверим, что SMART включен:

если вдруг SMART поддерживается диском, но выключен, то активируем его:

Теперь мы можем проверять статус SMART командой:

Именно эту команду мы и запишем в наш zabbix_agentd.conf:

где uHDD.health — ключ.

Мониторинг SMART через Flexible UserParameter

Тут возникает резонный вопрос, как быть если дисков два. Легче всего решить эту проблему поможет способность UserParameter передавать параметры агенту, про которую мы еще не упоминали. Но делается все очень просто, сразу пример:

В веб-интерфейсе Zabbix в ключе мы будем подставлять параметры в квадратные скобки вместо *. Например, для одного элемента данных мы напишем sda, а для другого sdb. В команде этот параметр найдет отражение там, где стоит переменная $1.

Создадим для второго диска элемент данных:

И через некоторое время сможем наблюдать результат в последних данных:

Мониторинг SMART через Flexible UserParameter c Low-level Discovery

Все получилось. Но тут возникает резонный вопрос, как быть если дисков не два, а двадцать два. И тут нам пригодится замечательная возможность низкоуровнего обнаружения (LLD), про которую мы уже говорили.

Низкоуровневое обнаружение позволяет системе мониторинга обнаруживать какое количество однотипных элементов присутствует на узле сети и динамически по шаблону создавать необходимые элементы данных, триггеры и графики для этих элементов. «Из коробки» системе доступна возможность находить файловые системы, сетевые интерфейсы и SNMP OID’ы. Однако, и здесь разработчики оставили возможность дополнить стандартные возможности, нужно просто передать в систему информацию о том, какие элементы обнаружены в формате JSON. Этим и воспользуемся.

Создадим маленький скрипт на perl, smartctl-disks-discovery.pl. Он будет находить все диски в системе и выводить эту информацию в JSON, передавая также информацию, включен ли у диска SMART или нет, а также попытается сам включить SMART, если он выключен:

При запуске скрипт выдает:

Теперь, для того чтобы скрипт автоматически запускался Zabbix’ом, просто добавим еще один UserParameter в zabbix_agentd.conf:

Покончив с настройкой конфига, переходим в веб-интерфейс, где создаем новое правило обнаружения для smartctl:

Обратите внимание на ключ и на фильтр, (<#SMART_ENABLED>=1) благодаря последнему будут добавляться только те обнаруженные диски, которые поддерживают SMART. Теперь мы можем переписать два наших элемента данных для дисков sda и sdb в один прототип элементов данных, просто заменив имя диска на макрос <#DISKNAME>:

Последнее, перед тем, как Zabbix сможет запускать команды, которые мы прописали в zabbix_agentd.conf из-под root и мониторить SMART, нужно добавить разрешения для его пользователя запускать эту команду без ввода пароля, для этого добавим в /etc/sudoers строчку:

Готовый шаблон для мониторинга SMART с остальными элементами данных, триггерами прикладываю, так же как и настроенный под него конфиг.

Контроль за установкой новых программ на Windows

Zabbix агент, установленный на Windows, точно также может быть расширен через UserParameter, только команды будут уже другие. Хотя, например, smartctl — кроссплатформенная утилита, и точно также можно ее использовать для контроля за жесткими дисками в Windows.

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

Для его интеграции с Zabbix добавим UserParameter в конфиг-файл:

Добавим элемент данных в шаблон для Windows:

Добавим триггер:

и действие, которое будет отправлять e-mail уведомление:

Весь процесс мониторинга выглядит так: каждый час запускается скрипт Zabbix агентом, который сравнивает два списка программ: текущий и предыдущий. Затем скрипт выписывает все изменения в отдельный файл. Если же изменений нет, то в файл пишется 0x0

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

В итоге

UserParameter — отличная и простая возможность расширить функционал системы самостоятельно. Стоит упомянуть и альтернативы: zabbix_sender, который, например, подойдет для тех случаев, когда нужно отправлять данные в Zabbix не по расписанию, (как это делает UserParameter), а по какому-то событию; и system.run[], который похож на UserParameter, но удобнее тем, что не нужно вносить изменения во все конфиги агентов, достаточно просто добавить этот элемент данных в шаблон. Более того, в следующем крупном релизе Zabbix 2.2 нас ожидает еще один новый способ расширить возможности агента- это подключаемые модули. Ждем с нетерпением!

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

Источник