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

Введение

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

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

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

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

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

Server = 192.168.100.100 [ip адрес Zabbix-севера]
HostnameItem = ITHELP21RU-PC [имя хоста, на который устанавливаем агент]
LogFile = C:\zabbix_agents_3.4.6.win\ [указываем место для записи логов в файл]

cd c:\zabbix_agents_3.4.6.win\bin\win64

zabbix_agentd.exe -c c:\zabbix_agents_3.4.6.win\conf\zabbix_agentd.conf --install

zabbix_agentd.exe [11948]: service [Zabbix Agent] installed successfully
zabbix_agentd.exe [11948]: event source [Zabbix Agent] installed successfully

cd c:\zabbix_agents_3.4.6.win\bin\win64
zabbix_agentd.exe --start

zabbix_agentd.exe [12128]: service [Zabbix Agent] started successfully.

Тип правила: Для порта;
Протоколы и порты: Протокол TCP; Определенные локальные порты: 10050;
Действие: Разрешить подключение;
Профиль: Галочки Доменный, Частный, Публичный;
Имя: Zabbix Agent;

Ceph by Zabbix agent 2

{$CEPH.API.KEY}

zabbix_pass

{$CEPH.CONNSTRING}

{$CEPH.USER}

zabbix

Ceph

1. Настройте модуль Ceph RESTful в соответствии с документацией.

2. Убедитесь, что точка входа RESTful API доступна для подключений.

Docker

Docker

Чтобы задать путь к точке входа Docker API измените параметр Plugins.Docker.Endpoint в файле конфигурации агента 2 (по умолчанию: Plugins.Docker.Endpoint=unix:///var/run/docker.sock).

Чтобы проверить доступность, выполните:
zabbix_get -s docker-host -k docker.info

Memcached

{$MEMCACHED.CONN.URI}

Memcached

Чтобы проверить доступность, выполните:
zabbix_get -s memcached-host -k memcached.ping

MongoDB cluster by Zabbix agent 2

{$MONGODB.CONNSTRING}

{$MONGODB.USER}

{$MONGODB.PASSWORD}

MongoDB

плагины

zabbix_get -s mongos.node -k 'mongodb.ping["{$MONGODB.CONNSTRING}","{$MONGODB.USER}","{$MONGODB.PASSWORD}"]"

MongoDB node by Zabbix agent 2

{$MONGODB.CONNSTRING}

{$MONGODB.USER}

{$MONGODB.PASSWORD}

MongoDB

плагины

zabbix_get -s mongodb.node -k 'mongodb.ping["{$MONGODB.CONNSTRING}","{$MONGODB.USER}","{$MONGODB.PASSWORD}"]"

MySQL by Zabbix agent 2

{$MYSQL.DSN}

{$MYSQL.USER}

{$MYSQL.PASSWORD}

MySQL

Смотрите документацию MySQL для получения информации о привилегиях пользователей и Unix сокетах.

Oracle by Zabbix agent 2

{$ORACLE.CONNSTRING}

Oracle

PostgreSQL Agent 2

{$PG.URI}

{$PG.USER}

{$PG.PASSWORD}

PostgreSQL

Измените pg_hba.conf, чтобы разрешить подключения с Zabbix агента (для получения более подробных сведений смотрите документацию по PostgreSQL).

Redis

{$REDIS.CONN.URI}

Redis

Чтобы проверить доступность, выполните:
zabbix_get -s redis-master -k redis.ping

SMART by Zabbix agent 2

SMART by Zabbix agent 2 active

Правило LLD обнаружения дисков найдет все HDD, SSD, NVMe диски с включенным S.M.A.R.T.

Правило LLD обнаружения атрибутов найдет все Уникальные Атрибуты Производителя (Vendor Specific Attributes) по каждому диску.

Systemd by Zabbix agent 2

Website certificate by Zabbix agent 2

WebCertificate

zabbix_get -s <адрес_zabbix_агента> -k web.certificate.get[<DNS_веб_сайта>]

Создайте отдельный узел сети для TLS/SSL сертификата с интерфейсом Zabbix агента и присоедините этот шаблон к узлу сети.

Table of Contents

• 5 Простые проверки
  • 5.1 Обзор
  • 5.2 Поддерживаемые простые проверки
  • 5.3 ICMP пинг

5.1 Обзор

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

Обратите внимание, что для простых проверок Zabbix агент не требуется. За обработку (созданием внешних подключений и т.д.) простых проверок отвечает Zabbix сервер/прокси.

Примеры использования простых проверок:

Поля Имя пользователя и пароль в конфигурации простых элементов данных используются для элементов данных мониторинга VMware; иначе игнорируются.

5.2 Поддерживаемые простые проверки

Список поддерживаемых простых проверок:

Обработка времени ожидания

Zabbix не будет обрабатывать простую проверку дольше Timeout (времени ожидания) секунд, заданных в файле конфигурации Zabbix сервера/прокси.

5.3 ICMP пинг

Для обработки ICMP пинг Zabbix использует внешнюю утилиту fping.

Эта утилита не является частью дистрибутива Zabbix и должна быть установлена дополнительно. Если утилиты нет, у нее выставлены неверные разрешения и её размещение не совпадает с размещением заданным в файле конфигурации Zabbix сервера/прокси (параметры ‘FpingLocation’), ICMP пинг (icmpping, icmppingloss, icmppingsec) не будет обрабатываться.

fping должен быть выполняемым под пользователем Zabbix демонов и должен иметь setuid root. Выполните эти команды из под root для выставления корректных разрешений:

 chown root:zabbix /usr/sbin/fping  chmod 4710 /usr/sbin/fping

После выполнения этих двух команд проверьте владельца исполняемого файла fping. В некоторых случаях владелец может быть сброшен после выполнения chmod команды.

Также проверьте, принадлежит ли пользователь zabbix к группе zabbix, запустив команду:

и если нет добавьте следующей командой:

Умолчания, ограничения и описания значений для параметров ICMP проверок:

Предупреждение: Значения по умолчанию для fping могут различаться в зависимости от платформы и версии — если сомневаетесь, проверьте документацию по fping.

Zabbix записывает проверяемые IP адреса во временный файл по всем трем icmpping* ключам, который затем передается утилите fping. Если элементы данных имеют различные параметры ключа, то только элементы данных с идентичными параметрами ключа записываются в один файл.
Все записанные в один файл IP адреса проверяются fping утилитой в параллельном режиме, таким образом процесс Zabbix icmp pinger тратит фиксированное время вне зависимости от количества IP адресов в файле.

• 2 Passive and active agent checks
  • Overview
  • Passive checks
  • Active checks
  • Older XML protocol

Overview

This section provides details on passive and active checks performed by Zabbix agent.

Zabbix uses a JSON based communication protocol for communicating with Zabbix agent.

See also: Zabbix agent 2 protocol details.

Passive checks

A passive check is a simple data request. Zabbix server or proxy asks for some data (for example, CPU load) and Zabbix agent sends back the result to the server.

For definition of header and data length please refer to protocol details.

Above, the part in square brackets is optional and is only sent for not supported items.

For example, for supported items:

1. Server opens a TCP connection
2. Server sends <HEADER><DATALEN>agent.ping
3. Agent reads the request and responds with <HEADER><DATALEN>1
4. Server processes data to get the value, ‘1’ in our case
5. TCP connection is closed

For not supported items:

1. Server opens a TCP connection
2. Server sends <HEADER><DATALEN>vfs.fs.size[/nono]
3. Agent reads the request and responds with <HEADER><DATALEN>ZBX_NOTSUPPORTED\0Cannot obtain filesystem information: [2] No such file or directory
4. Server processes data, changes item state to not supported with the specified error message
5. TCP connection is closed

Active checks

Active checks require more complex processing. The agent must first retrieve from the server(s) a list of items for independent processing.

The servers to get the active checks from are listed in the ‘ServerActive’ parameter of the agent configuration file. The frequency of asking for these checks is set by the ‘RefreshActiveChecks’ parameter in the same configuration file. However, if refreshing active checks fails, it is retried after hardcoded 60 seconds.

In order to decrease network traffic and resources usage Zabbix server or Zabbix proxy will provide configuration only if Zabbix agent still hasn’t received configuration or if something has changed in host configuration, global macros or global regular expressions.

The agent then periodically sends the new values to the server(s).

If an agent is behind the firewall you might consider using only Active checks because in this case you wouldn’t need to modify the firewall to allow initial incoming connections.

Getting the list of items

The active checks request is used to obtain the active checks to be processed by agent. This request is sent by the agent upon start and then with RefreshActiveChecks intervals.

The active checks response is sent by the server back to agent after processing the active checks request.

The server must respond with success.

1. Agent opens a TCP connection
2. Agent asks for the list of checks
3. Server responds with a list of items (item key, delay)
4. Agent parses the response
5. TCP connection is closed
6. Agent starts periodical collection of data

Note that (sensitive) configuration data may become available to parties having access to the Zabbix server trapper port when using an active check. This is possible because anyone may pretend to be an active agent and request item configuration data; authentication does not take place unless you use encryption options.

Sending in collected data

The agent data request contains the gathered item values.

A virtual ID is assigned to each value. Value ID is a simple ascending counter, unique within one data session (identified by the session token). This ID is used to discard duplicate values that might be sent in poor connectivity environments.

The agent data response is sent by the server back to agent after processing the agent data request.

  "processed: 2; failed: 0; total: 2; seconds spent: 0.003534" 

If sending of some values fails on the server (for example, because host or item has been disabled or deleted), agent will not retry sending of those values.

1. Agent opens a TCP connection
2. Agent sends a list of values
3. Server processes the data and sends the status back
4. TCP connection is closed

Error message will be trimmed to 2048 symbols on server side.

Heartbeat message

The heartbeat message is sent by an active agent to Zabbix server/proxy every HeartbeatFrequency seconds (configured in the Zabbix agent configuration file).

It is used to monitor the availability of active checks.

  "active check heartbeat"   

Older XML protocol

Zabbix will take up to 16 MB of XML Base64-encoded data, but a single decoded value should be no longer than 64 KB otherwise it will be truncated to 64 KB while decoding.

Мониторинг web сайта в Zabbix

https://t.me/i_odmin

Введение

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

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

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

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

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

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

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

Читайте также:  Оптимизация обмена сообщениями по электронной почте: как IMAP может улучшить ваш рабочий процесс

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

Открываем этот шаблон. Переходим на вкладку 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.

Значение параметра 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 и копирую получившуюся строку. В моем случае она была такая:

username=VladimirZp&password=pass123&redirect=.%2Fucp.php%3Fmode%3Dlogin&sid=70389f827540ef7a1fb7acb4e3bbad12&redirect=index.php&login=Login

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

username=VladimirZp&password=pass123&sid=70389f827540ef7a1fb7acb4e3bbad12&redirect=index.php&login=Login

Теперь иду в шаблон для мониторинга сайтов и добавляю новый сайт — 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 добавить строку:

127.0.0.1 github.com

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

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

Читайте также:  Освоение дампа MySQL: простое резервное копирование и восстановление для оптимальной безопасности данных

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

{Sites Monitoring:web.test.time[github.com,index,resp].count(#7,1.5,"ge")}>4
{Sites Monitoring:web.test.time[github.com,index,resp].count(#3,1.5,"lt")}>1

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

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

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

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

Более подробно о мониторинге за временем отклика сайта читайте в отдельной статье на этот счет. Там описана теория процесса и практические рекомендации, вместе с готовым триггером.

Заключение

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

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

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

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

Дело в том, что когда пользователь вбивает в адресной строке URL, ему фиолетово, через какой протокол он будет работать. Однако 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 to host yandex.ru left intact

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

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

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

Напоследок

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

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

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

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

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

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

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

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

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

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

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

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