Мониторинг сайтов в Zabbix 7.0: от проверки доступности до действий пользователя

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

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

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

Какие проверки можно использовать

Мониторинг сайта удобно разделить на три уровня.

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

1. Сетевая доступность: доступен ли сервер

Самая простая проверка — ICMP Ping. Она помогает определить, отвечает ли узел из точки мониторинга.

Дополнительно можно проверять подключение к TCP-порту, например 443, который обычно используется для HTTPS.

Но успешный результат ещё не подтверждает работу сайта. Сервер может отвечать на ping и принимать соединения, а приложение — возвращать ошибку 500 или страницу-заглушку.

Есть и обратная ситуация: ICMP запрещён настройками сети, хотя сайт продолжает работать. Поэтому результат ping нужно оценивать с учётом устройства инфраструктуры.

Для проверки самого веб-приложения перейдём на следующий уровень — HTTP/HTTPS-запросы.

2. Web Scenario: проверяем ответы приложения

Для контролируемого ресурса в Zabbix создаётся веб-сценарий — Web Scenario. Он с заданной периодичностью выполняет HTTP/HTTPS-запросы и может состоять из одного или нескольких последовательных шагов.

Сценарий позволяет контролировать:

• Доступность веб-приложения — удаётся ли получить ответ.
• Успешность выполнения шагов — на каком этапе возникла проблема.
• HTTP-код ответа — соответствует ли он ожидаемому.
• Содержимое страницы — присутствует ли заданный текст или совпадение с регулярным выражением.
• Время ответа — сколько занимает выполнение запроса на каждом шаге.

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

Пример проверки страницы

Допустим, нужно контролировать страницу контактов:

https://example.net/contacts/

В настройках узла сети создадим веб-сценарий и добавим шаг со следующими условиями:

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

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

Почему одного HTTP-кода недостаточно

Ответ 200 OK означает успешную обработку HTTP-запроса, но не гарантирует, что сервер вернул полезное содержимое.

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

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

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

Где заканчиваются возможности веб-сценария

Веб-сценарий работает с HTTP-запросами и ответами. Он не выполняет JavaScript страницы как полноценный браузер.

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

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

3. Browser: проверяем действия посетителя

В Zabbix 7.0 появился тип элемента данных Browser. Он позволяет выполнять сценарий в настоящем браузере: открывать страницы, находить элементы, нажимать кнопки и заполнять поля.

Для управления браузером используется WebDriver — например, Selenium с Chrome. Сценарий описывается на JavaScript, а результаты возвращаются в Zabbix. Примеры приведены в статье Zabbix о браузерном мониторинге.

Так можно проверить последовательность действий:

1. Открыть главную страницу.
2. Перейти в раздел контактов.
3. Найти форму.
4. Заполнить обязательные поля.
5. Отправить тестовое обращение.
6. Дождаться ожидаемого подтверждения.

Каждый этап должен иметь понятный критерий успеха. Сам факт открытия страницы не подтверждает выполнение всей последовательности.

Что понадобится для подключения

Потребуются Zabbix server или proxy версии 7.0, доступный Selenium WebDriver с браузером и сетевой доступ к проверяемому сайту.

На компоненте Zabbix, выполняющем проверку, указывают адрес WebDriver. Например, если Selenium доступен на той же машине через локальный порт:

WebDriverURL=http://127.0.0.1:4444
StartBrowserPollers=1

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

После изменения конфигурации соответствующий сервис Zabbix перезапускают. Затем подключают готовый шаблон браузерного мониторинга либо создают собственный элемент данных типа Browser.

Подготовка окружения и пример настройки описаны в руководстве initMAX.

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

Как проверить форму обратной связи

Глубину проверки формы нужно определить заранее.

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

Проверка отправки заполняет форму тестовыми данными, отправляет её и проверяет ожидаемый результат.

При этом сообщение «Спасибо» само по себе ещё не доказывает, что обращение сохранено и доставлено получателю. Если требуется контролировать весь путь заявки, сценарий нужно дополнить подтверждением со стороны приложения или системы, куда она поступает.

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

Как сделать уведомления полезными

Сообщение должно объяснять, какая проверка завершилась неуспешно.

Например:

Страница контактов example.net вернула HTTP 500.

Или:

Не удалось пройти браузерную проверку формы: после отправки не появилось ожидаемое подтверждение.

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

Отдельно стоит учитывать состояние самого мониторинга. Недоступность Selenium не означает, что посетители не могут пользоваться сайтом. В сообщении должно быть понятно, произошёл сбой приложения или не удалось выполнить проверку.

Что учитывать после настройки

Проверки нужно поддерживать вместе с сайтом.

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

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

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

С чего начать на небольшом сайте

Для первого этапа можно выбрать небольшой набор проверок:

• HTTP/HTTPS-проверка важных страниц через Web Scenario.
• Контроль срока действия сертификата.
• Один браузерный сценарий для ключевого действия посетителя.
• Проверка уведомления о проблеме и восстановлении.

Для сайта услуг ключевым действием может быть обращение через форму. Для личного кабинета — вход и открытие основного раздела.

Нужна помощь с настройкой?

Сайты и веб-сервисы — состав работ и подход к задаче.