Мониторинг web-страничек Zabbix-ом

В наш век всепоглощающих web-интерфейсов очень часто перед системными администраторами встаёт, на первый взгляд, непонятная с точки зрения объёмов задача: как проверять работоспособность сайта?

Практически все вспомнят про мониторинг 80/TCP (HTTP-версия) и 443/TCP (HTTPS-версия) портов web-сервера. Из них процентов 80% наверняка вспомнят, что с той стороны должен при этом трудиться Apache/NGINX обеспечивающий первоначальную работоспособность этого комплекса и т.д.

Службы (они же демоны) обеспечивающие работоспособность frontend и backend частей сайта обкладывать мониторингом безусловно надо. Но как быть, если в тех. поддержку поступает звонок с воплями «Ваш магазин отображает какую-то фигню, а я всего лишь хочу сделать заказ! Мне надо срочно!!! Почините немедленно!», а web-разработчики разводят руками и говорят «У нас всё нормально, это админы что-то с нашим прекрасным магазином сделали!».

Введение

Админ, помни — за тобой могут придти

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

Думаем на будущее

Прежде чем взять web-сервис на мониторинг, требуйте описание метрик его работоспособности, но при этом думайте шире повторяя как заклинание «Они наверняка что-то недоговаривают. Где-то возможны подводные камни». Паранойя не должна быть абсолютной, но в умеренном количестве жизненно необходима.

Рассмотрим пример с общедоступным всем в РФ сайтом поиска от Яндекс (yandex.ru). Чтобы быть уверенным, что он открывается правильно, нужно знать, какие кусочки web-страницы не меняются ни при каких условиях и при этом отображаются только если он работает.

Так как лёгких путей мы не ищем, воспользуемся curl-ом с ключом «-v», потому что иначе мы не увидим важную для настройки мониторинга информацию:

$ curl -v yandex.ru
* Rebuilt URL to: yandex.ru/
*   Trying 5.255.255.80...
* TCP_NODELAY set
* Connected to yandex.ru (5.255.255.80) port 80 (#0)
GET / HTTP/1.1
Host: yandex.ru
User-Agent: curl/7.58.0
Accept: */*
HTTP/1.1 302 Found
Date: Wed, 25 Jul 2018 18:10:54 GMT
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Location: https://yandex.ru/
Expires: Wed, 25 Jul 2018 18:10:55 GMT
Last-Modified: Wed, 25 Jul 2018 18:10:55 GMT
P3P: policyref="/w3c/p3p.xml", CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"
Set-Cookie: yandexuid=7233814731532542254; Expires=Sat, 22-Jul-2028 18:10:54 GMT; Domain=.yandex.ru; Path=/
X-Content-Type-Options: nosniff
Content-Length: 0
* Connection #0 to host yandex.ru left intact

Итак, исходя из вывода curl-а мы можем вывести первый признак работоспособности. При запросе http://yandex.ru (то, что мы обращались к сайту по HTTP, свидетельствует 80-й порт в выводе) срабатывает переадресация по коду 302 на HTTPS-версию сайта.

Зачем это проверять, если оно и так должно работать?

Дело в том, что когда пользователь вбивает в адресной строке URL, ему фиолетово, через какой протокол он будет работать. Однако web-сервис на пару с его разработчиком могут придерживаться другого мнения на этот счёт.

Что-то еще или уже хватит?

Нет, не хватит. Мы же хотим быть уверенными, что переадресация ведет куда надо - раз. И два - при открытии https://yandex.ru напрямую (вдруг кто-то добавил страницу в избранное) сайт тоже должен нормально открываться.

Наконец-то настройка

Долго готовились, а теперь пора настроить то ради чего это все затевалось - мониторинг web-страниц Zabbix-ом. Сразу оговорюсь - в этом руководстве я исхожу из того, что у вас уже есть настроенный узел сети (он же host), в который надо просто добавить web-сценарий проверки.

Дальше будет много скриншотов.

Настраиваем сценарий (задаем имя сценария, частоту проверки и при необходимости иные параметры)

Создаем шаги: Первый шаг - запрещаем переход по редиректам и проверяем код ответа

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

Третий шаг - запрещаем переходы по редиректам и проверяем HTTPS версию (код ответа и наличие строки указывающей на работоспособность сайта)

Теперь создадим триггер, который проверяет, что сценарий отработал успешно. Коротко суть: 1) ITEM.VALUE указатель на первое из двух выражений триггера (если нужно использовать несколько выражений или конкретное по номеру, то нужно использовать порядковые номера. Например - ITEM.VALUE3); 2) Выражения триггера - первое проверяет на что сообщение об ошибке не пустое, а второе что номер проваленного шага не 0 (если 0, значит проверка завершена успешно).

Если вдруг триггер сработает, то выглядеть это будет примерно вот так (для проверки я изменил один из ожидаемых кодов ответа в сценарии на заведомо неверный):

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

Напоследок

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

Есть вопрос? Напишите в комментариях!