Мониторинг серверов через zabbix

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

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

Текущая статья писалась для версии 2.4, все скриншоты приведены из нее. В настоящее время уже вышли более новые версии, но вся нижеизложенная инструкция не потеряла актуальности. Все будет работать и в новой версии.

Подготовка к мониторингу в Zabbix

Описанным мной способом можно мониторить температуру не только windows серверов, но и любых рабочих станций, если будет такая необходимость. Схема мониторинга следующая:

Существует бесплатная утилита Open Hardware Monitor, которая может показывать температуру некоторых датчиков сервера. Вообще говоря, она много чего может показывать (напряжение, скорость вентиляторов, загрузку процессора), но в данном случае нас интересует только температура. У этой утилиты есть версия, работающая в командной строке. Из командной строки показания датчиков можно записывать в файл. Этот файл можно анализировать и забирать из него необходимую для мониторинга информацию. Дальше эта информация передается в сервер Zabbix с помощью опции UserParameter. Все достаточно просто и в то же время эффективно.

Приступим к реализации. Скачиваем GUI версию утилиты по ссылке, приведенной ранее и консольную версию OpenHardwareMonitorReport. Запускаем GUI на сервере и смотрим, какие датчики нам доступны для мониторинга.

Программа увидела несколько датчиков. С процессором все понятно, а вот три других датчика не ясно, чью температуру показывают. Я хотел мониторить температуру процессора и материнской платы. Узнать, какая температура относится к материнской плате можно несколькими способами. Конкретно в данной ситуации я просто запустил портированную версию AIDA64 и посмотрел, какие показания у датчика материнской платы:

Оказалось — 45 градусов. Я запомнил, что датчик Temperature #3 отображает температуру материнской платы.

Можно было пойти другим путем, зайти в IPMI панель, если она есть, и посмотреть там. Я работал с серверами SuperMicro, там она есть. Я на всякий случай зашел и проверил:

Почему-то в этой панели не оказалось информации с датчика температуры процессора. Но нам это не важно. Самое главное, что мы узнали параметры, за которыми будем следить — это CPU Packege и Temperature #3. Теперь запускаем консольную версию и смотрим вывод информации. Я для удобства положил OpenHardwareMonitorReport.exe в папку с основной программой и все это хозяйство скопировал в корень диска C:

Открываем файл 1.txt. Ищем там строки

Нас интересует выделенный текст. По нему мы будем вычленять температуру для мониторинга и передавать ее на Zabbix сервер. Создаем в этой же папке 2 bat файла следующего содержания:

CPUTemperature.bat

MotherTemperature.bat

Запускаем эти батники в командной строке и проверяем вывод. Там должны быть только цифры температуры:

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

Настройка Zabbix agent в Windows

Предполагается, что у вас уже настроен сервер мониторинга Zabbix и подключены клиенты, которые ему передают информацию. В данном материале я не буду касаться непосредственно установки и настройки сервера Zabbix, это будет отдельный материал. Сейчас же мы берем готовый файл конфигурации агента zabbix_agentd.win.conf и добавляем в самый конец файла следующие строки:

Перезапускаем службу агента Zabbix, чтобы изменения вступили в силу.

Настройка мониторинга на Zabbix сервере

Теперь идем на сервер. У меня Zabbix установлен на сервере CentOS, хотя это не принципиально. Добавляем новый Item. Пойти можно двумя путями:

  • Создать template, в него добавить все items, создать триггеры, графики и назначить этот шаблон нужным серверам.
  • К каждому серверу отдельно добавлять только необходимые итемы и вручную добавлять триггеры и графики.

Очевидно, что первым путем идти удобнее и разумнее. Я так и поступил, но в процессе реализации столкнулся с проблемой. Не все сервера имеют одинаковый набор датчиков. Где-то я не смог снять температуру с материнской платы, где-то вместо одного процессора, стояло два и хотелось снимать температуру с обоих камней. Как будет в вашем случае — не знаю. Если все серверы однотипные, то создавайте template, если все разные, то вручную добавляйте каждый итем на сервер. Я в итоге сделал и шаблон для одинотипных серверов, и вручную добавлял итемы туда, где имелись отличия от шаблона.

Итак, сначала создадим шаблон. Идем в ConfigurationsTemplatesCreate Template. Шаблон я назвал Temperature Windows. Добавил в него ApplicationTemperature, затем Item CPU Temperatue. Заполняем поля итема как у меня на картинке:

Параметр Temperature.CPU тот же самый, что и в файле конфигурации агента.

По аналогии создаем итем Mother Temperatue:

Сохраняем шаблон. По желанию создаем для него триггеры и графики. Можно и без них. Добавляем шаблон к серверу, который хотим мониторить. Ждем некоторое время и идем проверять входящие данные. Открываем MonitoringLatest data:

Читайте также:  Мтс акция бесплатный интернет

Нажимаем graph и смотрим график:

Теперь добавим в Zabbix еще один сервер для мониторинга, который будет отличаться по конфигурации от предыдущего. На его примере я покажу, как менять настройки клиента и сервера. С этого сервера я не могу снять данные с датчика температуры материнской платы, по какой причине — не знаю, но не AIDA64 ни OpenHardwareMonitor мне температуру не показывают. Ее можно взять по SNTP с этого сервера, но это отдельная тема. В этом сервере 2 процессора и я хочу мониторить температуру обоих.

Запускаем GUI интерфейс и смотрим, какие датчики мы сможем мониторить:

Нас будет интересовать температура обоих ядер процессора. Теперь запускаем OpenHardwareMonitorReport.exe с выводом информации в текстовый файл. Смотрим, как выглядят строки с интересующей нас информацией:

Создаем два bat файла следующего содержания:

CPU1Temperature.bat

CPU2Temperature.bat

Редактируем конфигурационный файл zabbix_agentd.win.conf агента Zabbix на клиенте. Добавляем в конец две строки:

Перезапускаем службу агента, чтобы изменения вступили в силу.

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

item became not supported

Во время отладки работ я столкнулся с проблемами. Периодически Item отваливались и получали статус: Not Supported. При этом в логах сервера были следующие записи:

То есть данные то собирались, то переставали собираться. Иногда, чтобы данные снова пошли, приходилось удалять итем и создавать его заново. Некоторое время я повозился, пока не понял, в чем дело.

Я обратил внимание, что при запуске батника из командной строки, вывод данных происходит с приличной задержкой в 3-5 секунд. В Zabbix по-умолчанию стоит параметр, по которому агент ожидает ответа от скрипта 3 секунды и на сервере есть подобный параметр, по которому сервер ждет ответа от агента 3 секунды. Если за это время данные не поступают, то итем переходит в статус Not Supported и данные с него не собираются.

Чтобы избавиться от этой ошибки, необходимо увеличить таймаут до 15-ти секунд. Меняем параметр в конфиге на клиентах и на сервере. Он и там и там один и тот же:

Потом перезапускаем сервер и агентов и ждем результатов. Больше ошибок быть не должно.

На этом, собственно настройка мониторинга температуры окончена. Можно дальше все оформить как полагается: настроить тригеры, оповещения, графики красивые нарисовать. Кому что нужно. Я себе вывел вот такую картинку для наглядности:

Введение

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

В качестве средства мониторинга у нас используется Zabbix 3.0. Вопрос аппаратного мониторинга до этого не поднимался.

В ходе поисков способа решения данной задачи я остановился на мониторинге через IPMI. Дальнейшие поиски решения навели меня на замечательную статью Vengant Мониторинг серверов HP через iLO в Zabbix. К сожалению его решение подошло мне не полностью, поскольку ориентировано только на HP и не всегда корректно получает информацию с сенсоров. Но сам ход мыслей понравился и я решил действовать в этом же направлении.

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

  • Использует функцию Auto Discovery. Ручная работа сведена к минимуму. Достаточно добавить новый узел сети, прописать ему ip адрес IPMI и параметры аутентификации
  • Работает для всех вендоров и моделей серверов с IPMI 2.0
  • Корректно находит все сенсоры, считывает по ним информацию и рапортует если случилась беда

Как это было реализовано

В решении Vengant для поиска сенсоров используется пакет FreeIPMI. К сожалению на серверах HP Gen10 FreeIPMI отдаёт неверные имена сенсоров и zabbix не может корректно по ним получить информацию.

Было принято решение писать свои скрипты. Логически конструкция делится на 2 части

  • Скрипт для обнаружения IPMI сенсоров
  • Скрипт для генерации JSON для Auto Discovery

В качестве языка выбран bash. В качестве источника данных zabbix-server.log в debug режиме.

Скрипт для обнаружения IPMI сенсоров

Zabbix сервер переведён в режим debug для ведения лога. В этом режиме он пишет подробную информацию по всем найденным IPMI сенсорам в строки вида:

20764:20180322:095415.913 Added sensor: host:’192.168.17.50:623′ id_type:0 id_sz:15 id:’21-VR P2 Mem 2′ reading_type:0x1 (‘threshold’) type:0x1 (‘temperature’) full_name:’0(20.24).21-VR P2 Mem 2′

В этой строке нас интересуют 4 значения:

  • host — ip адрес хоста, которому принадлежит сенсор
  • id — имя сенсора
  • reading_type — тип считывателя сенсора
  • type — тип сенсора

Была создана отдельная таблица в БД zabbix. Все найденные сенсоры аккуратно туда заносятся. На выходе получается такой результат

Скрипт запускает cron каждые 3 минуты.

Скрипт для генерации JSON для Auto Discovery

В правилах Auto Discovery этому скрипту отдаются 3 переменные. ip адрес хоста, тип считывания и тип сенсора. Скрипт ищет совпадения в mysql таблице. Если такие совпадения находятся, он генерирует JSON с именами всех найденных сенсоров и срабатывает правило Auto Discovery.

Zabbix шаблон

В шаблон добавлены правила Auto Discovery для основных сенсоров, прототипы элементов данных и прототипы триггеров к ним.

Применение на практике

Для использования этого решения у себя, нужно сделать следующие шаги:

  1. Скачиваем архив c шаблоном и скриптами
  2. Импортируем шаблон в заббикс
  3. Включаем debug в конфиге zabbix
  4. Переносим оба скрипта в externalscripts и делаем их исполняемыми
  5. Добавляем в cron ipmisensorsmysql.sh
  6. Создаём новый узел сети
  7. Добавляем ему IPMI интерфейс и вносим параметры аутентификации
  8. Применяем к нему шаблон
  9. Ждём, когда отработают правила Auto Discovery
Читайте также:  Мобильные телефоны с мощной батареей

На выходе получается следующее:

Послесловие

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

Продолжаю свой цикл статей по настройке системы мониторинга на базе популярного бесплатного продукта. В этот раз мы подробно рассмотрим вопрос настройки мониторинга web сайта в подготовленном ранее zabbix сервере. В качестве примера возьмем какой-нибудь сторонний ресурс и проверим на нем предложенный стандартный функционал.

Введение

Для мониторинга веб сайта мы будем использовать стандартный функционал zabbix. Вот параметры, за которыми будем наблюдать:

  • доступность сайта
  • время ответа сайта в миллисекундах
  • скорость доступа к сайту
  • работа авторизации на сайте

Для этого мы выполним следующую последовательность действий:

  1. Создадим шаблон для мониторинга за сайтами.
  2. Настроим сценарии проверки.
  3. Создадим графики с данными.
  4. Добавим триггеры на проверку доступности и скорости загрузки сайта.

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

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

Добавление web сайта к мониторингу

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

Открывается стандартная форма создания шаблона. Вводим название шаблона, где будут настройки мониторинга сайтов, и добавляем его в какую-нибудь группу.

Открываем этот шаблон. Переходим на вкладку Web Scenarios и добавляем новый сценарий для мониторинга сайта.

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

После этого перехожу на вкладку Steps и добавляю шаг проверки.

Дальше указываю параметры шага.

Поясню каждый параметр:

  • Name — имя шага. В данном случае проверяться будет главная страница сайта, поэтому называю шаг index. Это не принципиально, но названия рекомендую давать осмысленные, чтобы потом было удобно оперировать названиями, к примеру, в триггерах.
  • URL — адрес проверяемой страницы.
  • Required string — строка на странице, которую будет искать zabbix. Я взял строку из футера сайта. Если заббикс ее найдет на странице, будет считать, что с сайтом все в порядке. Если нет — выдаст ошибку.
  • Required status codes — требуемый код ответа. Указываю 200. Если заббикс получит какой-то другой код в ответ от web сервера, будет считать, что проверка закончилась неудачей.

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

Простейшая проверка доступности сайта сделана. Дальше нам надо прикрепить этот шаблон к какому-нибудь хосту, чтобы начались реальные проверки. Я прикреплю шаблон к самому zabbix серверу. Для этого идем в Configuration -> Hosts, выбираем Zabbix Server и прикрепляем к нему созданный ранее шаблон.

Ждем несколько минут и идем в раздел Monitoring -> Web смотреть результаты мониторинга сайта github.com.

Код ответа 200, искомая строка найдена, что подтверждает Status OK . Тут же графики скорости загрузки сайта и время отклика. Более подробную информацию о мониторинге указанного сайта можно посмотреть в Latest Data.

Значение параметра Failed step of scenario «github.com» равное 0 означает, что все шаги проверки сайта выполнены без ошибок. Если у вас несколько шагов и какой-то из них завешается ошибкой, тут будет номер этого шага. То есть в общем случае, все, что не 0, это какие-то проблемы. Позже мы это будем использовать в триггере. А пока добавим пару графиков к шаблону, которые потом можно будет использовать в дашбордах.

Настройка графиков мониторинга веб сайта

Возвращаемся в наш шаблон и переходим в раздел Graphs. Создаем новый график.

Добавим график скорости загрузки главной страницы сайта.

По аналогии можете добавить график времени отклика сайта. Я разу добавил оба эти графика в Screen. Получилось вот так.

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

Мониторинг сайта с авторизацией

Немного усложним задачу. Давайте попробует выполнить авторизацию на сайте и провести мониторинг как самой авторизации, так и закрытой страницы за ней. Я для примера возьму форум centos.org/forums/, авторизуюсь на нем и после авторизации проверю страницу с персональной информацией конкретного пользователя.

Для того, чтобы настроить в zabbix мониторинг сайта с авторизацией, надо правильно сформировать post запрос для этой самой авторизации. Я это делаю следующим образом. Иду на страницу с авторизацией. В данном случае это https://www.centos.org/forums/ucp.php?mode=login, открываю DevTools в Сhrome, вкладку Network. Заполняю поля формы авторизации заведомо неправильными данными, чтобы авторизация завершилась ошибкой. После этой ошибки смотрю заголовки самого первого запроса.

Читайте также:  Мазда 3 оцинкованный кузов или нет

Я нажимаю на view source в разделе Form Data и копирую получившуюся строку. В моем случае она была такая:

Отсюда точно можно убрать параметр redirect. В итоге сохраняю вот такую строку:

Теперь иду в шаблон для мониторинга сайтов и добавляю новый сайт — centos.org. Создаю первый шаг с авторизацией, называю его auth. В нем же указываю post запрос для авторизации.

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

Следующим шагом делаем проверку строки Private messages на главной странице форума.

Шаги выполняются последовательно. На первом шаге мы только авторизовываемся, на втором проверяем страницу, доступную уже после авторизации. Идем в Latest Data и смотрим результат.

Оба шага успешно завершены, ошибок нет. Посмотрим раздел Monitoring -> Web.

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

Оповещение о недоступности сайта

Давайте настроим уведомления о проблемах на сайте. Я предлагаю 2 типа оповещения:

  1. О низкой скорости доступа к сайту.
  2. О недоступности сайта вообще.

Идем, как обычно в исходный шаблон, на вкладку Triggers и добавляем новый.

Я предлагаю вот такое условие срабатывания для определения недоступности сайта. Если среднее значение 3-х последних проверок больше, либо равно единице, то срабатывает оповещение о недоступности сайта.

Когда идет 0 во всех проверках, все в порядке. Триггер сработает только если все 3 последних проверки не равны нулю. В моем примере Failed step может принимать значение либо 0, либо 1, где 1 это номер сбойного шага. Если у вас шагов несколько, то сбойным может оказаться второй шаг или третий шаг. То есть значение может быть больше 1. Но в любом случае, если последние 3 значения подряд строго не 0, то идет срабатывание триггера. Операция восстановления очень простая. Если последняя проверка без ошибки, то есть код равен 0, то считаем, что сайт уже работает.

Чтобы проверить работу триггера, достаточно на zabbix server в файл /etc/hosts добавить строку:

и подождать 3 минуты, чтобы получились 3 неудачных проверки. После этого вам должно было отправиться уведомление о недоступности сайта. Я получил вот такое:

Дальше делаем проверку времени ответа сервера. Тут каждый волен настраивать так, как ему кажется более правильным и удобным. Я использую такую схему. Беру среднее время отклика сайта и умножаю его на 3. Далее смотрю последние 7 проверок. Если в 5 проверках среди этих семи были значения выше, чем утроенное среднее время отклика, то считаю, что сайт тормозит и надо слать уведомление. Немного замороченно, но на практике такая схема у меня себя хорошо зарекомендовала без ложных срабатываний. При этом, если возникают реальные проблемы, я их вижу. Рисуем триггер.

Условие восстановления — в последних трех запросах два и более были быстрее, чем утроенное среднее время доступа. Текст выражений для копирования:

В выражении 1.5 это время отклика в секундах. Именно в таком виде оно попадает в zabbix сервер. Проверить можно в Latest Data.

В завершении оставляю свой шаблон, который создал для написания статьи. Можете копированием и редактированием приспособить его для своих сайтов. Это быстрее, чем составлять с нуля. Шаблон экспортирован с версии zabbix 4.0 — sites_monitoring.xml

Вот и все, мониторинг веб сайта работает, авторизация проверяется, оповещение о недоступности сайта настроено. Для полноты картины можно создать Screen или Dashboard с выводом всех необходимых параметров на один экран. Его настройки уже будут зависеть от конкретной ситуации и тех данных, которыми вы располагаете. К примеру, если у вас настроен мониторинг веб сервера, то можно разместить рядом графики его загрузки и параметры доступа к сайту. Туда же можно добавить загрузку самого сервера по процессору и памяти и вывести график использования сетевого интерфейса.

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

Заключение

Добавлю несколько слов, как можно использовать данный мониторинг web сайта. У меня было два хостинга и хотелось выбрать один более быстрый. Загрузка самого сервера по железу была настолько низка, что ее можно было вообще не брать в расчет. Более важным параметром было именно время отклика сервера и скорость доступа к нему. Я запустил сайт на обоих серверах и настроил мониторинг. По его параметрам выбрал более быстрый сервер.

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

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

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock detector