• Добро пожаловать в Пиратскую Бухту! Чтобы получить полный доступ к форуму пройдите регистрацию!
  • Гость, стой!

    В бухте очень не любят флуд и сообщения без смысловой нагрузки!
    Чтобы не получить бан, изучи правила форума!

    Если хотите поблагодарить автора темы, или оценить реплику пользователя, для этого есть кнопки: "Like" и "Дать на чай".

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

XXL

Гардемарин
Premium
Регистрация
23.05.21
Сообщения
106
Онлайн
4д 23ч 35м
Сделки
0
Нарушения
0 / 0
Linux_Deep_26.07_Site.png


В наш век всепоглощающих web-интерфейсов очень часто перед системными администраторами встаёт, на первый взгляд, непонятная с точки зрения объёмов задача: как проверять работоспособность сайта?
Практически все вспомнят про мониторинг 80/TCP (HTTP-версия) и 443/TCP (HTTPS-версия) портов web-сервера.
Из них процентов 80% наверняка вспомнят, что с той стороны должен при этом трудиться Apache/NGINX обеспечивающий первоначальную работоспособность этого комплекса и т.д.
Службы (они же демоны) обеспечивающие работоспособность frontend и backend частей сайта обкладывать мониторингом безусловно надо. Но как быть, если в тех. поддержку поступает звонок с воплями «Ваш магазин отображает какую-то фигню, а я всего лишь хочу сделать заказ!
Мне надо срочно!!! Почините немедленно!», а web-разработчики разводят руками и говорят «У нас всё нормально, это админы что-то с нашим прекрасным магазином сделали!».


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

Думаем на будущее
Прежде чем взять web-сервис на мониторинг, требуйте описание метрик его работоспособности, но при этом думайте шире повторяя как заклинание
«Они наверняка что-то недоговаривают. Где-то возможны подводные камни».
Паранойя не должна быть абсолютной, но в умеренном количестве жизненно необходима.
Рассмотрим пример с общедоступным всем в РФ сайтом поиска от Яндекс (yandex.ru).
Чтобы быть уверенным, что он открывается правильно, нужно знать, какие кусочки web-страницы не меняются ни при каких условиях и при этом отображаются только если он работает.
Так как лёгких путей мы не ищем, воспользуемся curl-ом с ключом «-v», потому что иначе мы не увидим важную для настройки мониторинга информацию:

Код:
$ curl -v yandex.ru
<em> Rebuilt URL to: yandex.ru/
</em> Trying 5.255.255.80...
<em> TCP_NODELAY set
</em> 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, свидетельствует 80-й порт в выводе) срабатывает переадресация по коду 302 на HTTPS-версию сайта.

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

Что-то еще или уже хватит?
Нет, не хватит. Мы же хотим быть уверенными, что переадресация ведет куда надо - раз. И два - при открытии Яндекс напрямую (вдруг кто-то добавил страницу в избранное) сайт тоже должен нормально открываться.

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

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

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

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

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

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

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

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