Мониторинг web сайта в Zabbix
Содержание
- Введение
- Добавление web сайта к мониторингу
- Настройка графиков мониторинга веб сайта
- Мониторинг сайта с авторизацией
- Оповещение о недоступности сайта
- Заключение
Продолжаю свой цикл статей по настройке системы мониторинга на базе популярного бесплатного продукта. В этот раз мы подробно рассмотрим вопрос настройки мониторинга web сайта в подготовленном ранее zabbix сервере. В качестве примера возьмем какой-нибудь сторонний ресурс и проверим на нем предложенный стандартный функционал.
Введение
Для мониторинга веб сайта мы будем использовать стандартный функционал zabbix. Вот параметры, за которыми будем наблюдать:
- доступность сайта
- время ответа сайта в миллисекундах
- скорость доступа к сайту
- работа авторизации на сайте
Для этого мы выполним следующую последовательность действий:
- Создадим шаблон для мониторинга за сайтами.
- Настроим сценарии проверки.
- Создадим графики с данными.
- Добавим триггеры на проверку доступности и скорости загрузки сайта.
Приступаем к настройке мониторинга. Использовать будем только стандартный функционал, доступный после установки. Никаких дополнительных пользовательских параметров или работы скриптов не будет.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему 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. Заполняю поля формы авторизации заведомо неправильными данными, чтобы авторизация завершилась ошибкой. После этой ошибки смотрю заголовки самого первого запроса.
Я нажимаю на view source в разделе Form Data и копирую получившуюся строку. В моем случае она была такая:
Отсюда точно можно убрать параметр redirect. В итоге сохраняю вот такую строку:
Теперь иду в шаблон для мониторинга сайтов и добавляю новый сайт — centos.org. Создаю первый шаг с авторизацией, называю его auth. В нем же указываю post запрос для авторизации.
Не забудьте поменять пароль на правильный. После успешной авторизации вы увидите главную страницу форума, где будет ссылка на приватные сообщения форума. Эта ссылка доступна только после авторизации.
Следующим шагом делаем проверку строки Private messages на главной странице форума.
Шаги выполняются последовательно. На первом шаге мы только авторизовываемся, на втором проверяем страницу, доступную уже после авторизации. Идем в Latest Data и смотрим результат.
Оба шага успешно завершены, ошибок нет. Посмотрим раздел Monitoring — Web.
Здесь тоже все в порядке. Наглядно видно, что процесс авторизации гораздо дольше и медленнее, чем загрузка главной страницы.
Оповещение о недоступности сайта
Давайте настроим уведомления о проблемах на сайте. Я предлагаю 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 секунд. Это сильно влияет на среднее время доступа. Возникают эти провалы из-за временных сетевых проблем не обязательно на самом сайте. Это тоже нужно учитывать при анализе полученных данных.
В любом случае нужно с головой подходить к анализу данных мониторинга сайта. В большинстве случаев важны не сами значения, а общие тенденции их изменения в сравнении и с другими хостами. Учитывайте это. На этом у меня все.
Источник: