Как в last учитывать длительность zabbix

Триггер и сценарий для опроса сайта. Zabbix

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

>0 and >0 

Отслеживать
kiryushinsa
задан 20 мар 2020 в 7:06
kiryushinsa kiryushinsa
55 7 7 бронзовых знаков

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Дальше. Например для Zabbix server:web.test.fail[http://vsks.ru/] Можно взять функцию min. Будет выглядеть так:

Т.е. для web.test.fail нормальное значение равно 0, а значение больше 0, это шаг проверки на котором произошла ошибка. Тогда min(10m)>>0 сработает тогда, когда минимальное значение будет больше 0 в течении 10 минут. Здесь следует учитывать, что если сайт будет постоянно переходить между состояниями доступен\не доступен, этот триггер не сработает.

Второй вариант. Использовать функцию count

Здесь нужно учитывать переодичность проверки. предположим — 1 раз в минуту. Сработает когда за последних 10 минут будет больше 6 значений, отличных от 0.

Решаем практические задачи в Zabbix с помощью JavaScript

Тихон Усков, инженер команды интеграции Zabbix

Zabbix — кастомизируемая платформа, которая используется для мониторинга любых данных. С самых ранних версий Zabbix у администраторов мониторинга была возможность запускать различные скрипты через Actions для проверок на целевых узлах сети. При этом запуск скриптов приводил к возникновению ряда сложностей, в том числе таких, как необходимость поддержки скриптов, их доставки на узлы связи и прокси, а также поддержки разных версий.

JavaScript для Zabbix

В апреле 2019 года был представлен Zabbix 4.2 с функцией предобработки на JavaScript. Многие загорелись идеей отказаться от написания скриптов, которые где-то забирают данные, переваривают их и предоставляют уже в понятном для Zabbix формате, а выполнять простые проверки, которые будут получать неготовые для хранения и обработки Zabbix данные, а потом обрабатывать этот поток данных с использованием средств Zabbix и JavaScript. В связке с низкоуровневым обнаружением и зависимыми элементами данных, которые появились в Zabbix 3.4, получилось достаточно гибкая концепция для сортировки и управления полученными данными.

В Zabbix 4.4, как логическое продолжение предобработки на JavaScript, появился новый способ оповещения — Webhook, который можно использовать для простой интеграции оповещений Zabbix со сторонними приложениями.

JavaScript и Duktape

Почему были выбраны именно JavaScript и Duktape? Рассматривались различные варианты языков и движков:

• Lua – Lua 5.1
• Lua – LuaJIT
• Javascript – Duktape
• Javascript – JerryScript
• Embedded Python
• Embedded Perl

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

Критерии выбора и performance testing

— Стандарт ECMAScript E5/E5.1
— Модули Zabbix для Duktape:

• Zabbix.log() — позволяет вписать непосредственно в лог Zabbix Server сообщения с различным уровень детализации, что обеспечивает возможность сопоставлять ошибки, например, в Webhook с состоянием сервера.
• CurlHttpRequest() — позволяет делать HTTP-запросы в сеть, на чем основано применение Webhook.
• atob() и btoa() — позволяет кодировать и декодировать строки в формат Base64.

ПРИМЕЧАНИЕ. Duktape соответствует стандартам ACME. В Zabbix используется версия скрипта 2015 года. Последующие изменения незначительны, поэтому их можно игнорировать.

Магия JavaScript

Вся магия JavaScript заключена в динамической типизации и приведении типов: строковых, числовых и логических.

Это означает, что не нужно заранее объявлять какого типа переменная должна возвращать значение.

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

ПРИМЕЧАНИЕ. Методы, отвечающие за такие преобразования, как правило, реализованы в родительских прототипах объектов, valueOf и toString. valueOf вызывается при численном преобразовании и всегда перед методом toString. Метод valueOf обязан возвращать примитивные значения, иначе его результат игнорируется.

Для объекта вызывается метод valueOF. Если он не найден или не возвращает примитивное значение, вызывается метод toString. Если метод toString не найден, производится поиск valueOf в прототипе объекта, и все повторяется до завершения обработки значения и приведения всех значений в выражении к одному типу. Если для объекта реализован метод toString, который возвращает примитивное значение, то именно он используется для строкового преобразования. При этом результатом применения этого метода не обязательно является строка.

Например, если для для объекта ‘obj‘ определяется метод toString,

`var obj = < toString() < return "200" >>` 

метод toString возвращает именно строку, и при сложении строки с числом мы получаем склеенную строку:

`obj + 1 // '2001'` `obj + 'a' // ‘200a'`

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

`var obj = < toString() < return 200 >>` `obj + 1 // '2001'`

При этом, если мы выполняем сложение со строкой, выполняется строковое преобразование, и мы получаем склеенную строку.

`obj + 'a' // ‘200a'`

Именно в этом кроется причина большого количества ошибок начинающих пользователей JavaScript.

В метод toString можно вписать функцию, которая будет увеличивать текущее значения объекта на 1.

Выполнение скрипта при условии, что переменная равна 3, и она же равна 4.

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

Сравнение без приведения типов

ПРИМЕЧАНИЕ. Не используйте сравнение с приведением типов без необходимости.

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

Webhook Media

В конце 2019 года и в начале 2020 года команда интеграции Zabbix занималась активной разработкой Webhooks и интеграций «из коробки», которые поставляются в дистрибутиве Zabbix.

Ссылка на документацию

Preprocessing

• Появление предобработки на JavaScript позволило отказаться от большинства внешних скриптов, и в настоящее время в Zabbix можно получить любое значение и преобразовать его в совершенно другое любое значение.
• Предобработка в Zabbix реализована кодом на JavaScript, который при компиляции в байт-код преобразуется в функцию, принимающую единственное значение в виде параметра value в виде строки (в строке может быть и цифра, и число).
• Поскольку на выходе получается функция, в конце скрипта обязателен return.
• Возможно использование пользовательских макросов в коде.
• Ресурсы можно ограничить не только на уровне операционной системы, но и программно. Для шага предобработки выделяется максимум 10 мегабайт оперативной памяти и лимит времени выполнения в 10 секунд.

ПРИМЕЧАНИЕ. Значения тайм-аута в 10 секунд достаточно много, потому что сбор условных тысяч элементов данных за 1 секунду по достаточно «тяжелому» сценарию предобработки может замедлить работу Zabbix. Поэтому не рекомендуется использовать предобработку для выполнения полноценных скриптов на JavaScript через так называемые теневые элементы данных (dummy items), которые запускаются только для выполнения предобработки.

Проверить свой код можно через тест предобработки или с помощью утилиты zabbix_js:

`zabbix_js -s *script-file -p *input-param* [-l log-level] [-t timeout]` `zabbix_js -s script-file -i input-file [-l log-level] [-t timeout]` `zabbix_js -h` `zabbix_js -V` 

Практические задачи

Задача 1

Заменить вычисляемый элемент данных предобработкой.

Условие: получаем с датчика температуру в градусах по Фаренгейту для хранения в градусах по Цельсию.

Раньше мы создали бы элемент данных, который собирает температуру в градусах по Фаренгейту. После этого — еще один элемент данных (вычисляемый), который по формуле преобразовывал бы градусы по Фаренгейту в градусы по Цельсию.

Проблемы:

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

Одним из решений был отказ от гибких интервалов проверок в пользу фиксированных интервалов, чтобы гарантированно вычислять вычисляемый элемент данных после элемента данных, получающего данные (в нашем случае — температура в градусах по Фаренгейту).

Но если, например, шаблон мы используем для проверки большого количества устройств, и проверка выполняется раз в 30 секунд, 29 секунд Zabbix «халтурит», а в последнюю секунду начинает проверки и вычисления. Это приводит к созданию очереди и влияет на производительность. Поэтому рекомендуется использовать фиксированные интервалы, только если это действительно необходимо.

В данной задаче оптимальное решение — предобработка из одной строки на JavaScript, которая конвертирует градусы по Фаренгейту в градусы по Цельсию:

`return (value - 32) * 5 / 9;`

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

`return (parseInt(value) + parseInt(""));`

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

`return (value + "");`

Для получения результата математического действия, необходимо привести типы полученных значений в числовой формат. Для этого можно использовать функцию parseInt(), которая выдает целое число, функцию parseFloat(), которая выдает десятичную дробь, или функцию number, которая выдает целое число или десятичную дробь.

Задача 2

Получить время в секундах до окончания сертификата.

Условие: некий сервис выдает дату окончания сертификата в формате «Feb 12 12:33:56 2022 GMT».

В ECMAScript5 Date.parse() принимает дату в формате ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ). Необходимо привести к нему строку в формате MMM DD YYYY HH:mm:ss ZZ

Проблема: значение месяца выражено текстом, а не числом. Данные в таком формате не принимаются Duktape.

Пример решения:

• В первую очередь объявляется переменная, которая принимает значение (весь скрипт — объявление переменных, которые перечислены через запятую).
• В первой строке мы получаем дату в параметре value и разделяем ее пробелами методом split. Таким образом, мы получаем массив, где каждому элементу массива, начиная с индекса 0, соответствует один элемент даты до и после пробела. split(0) — месяц, split(1) — число, split(2) — строка с временем и т. д. После этого к каждому элементу даты можно обращаться по индексу в массиве.

`var split = value.split(' '),`

• Каждому месяцу (в хронологическом порядке) соответствует индекс его положения в массиве (с 0 до 11). Чтобы сконвертировать текстовое значение в числовое, к индексу месяца прибавляется единица (потому что нумерация месяцев начинается с 1). При этом выражение с прибавлением единицы взято в скобки, потому что в противном случае будет получена строка, а не число. В конце мы выполняем slice() — срез массива с конца, чтобы оставить только два символа (что важно для месяцев с двузначным номером).

`MONTHS_LIST = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'],` `month_index = ('0' + (MONTHS_LIST.indexOf(split[0]) + 1)).slice(-2),`

• Формируем из полученных значений строку в формате ISO обычным сложением строк в соответствующем порядке.

`ISOdate = split[3] + '-' + month_index + '-' + split[1] + 'T' + split[2],`

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

• После этого мы можем получить в JavaScript текущую дату в формате Unix Timestamp и вычесть ее из полученного значения даты окончания сертификата, чтобы получить количество миллисекунд с текущего момента до момента окончания сертификата.

`now = Date.now();`

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

`return parseInt((Date.parse(ISOdate) - now) / 1000);`

ПРИМЕЧАНИЕ. Обратите внимание на использование parseInt() в функции return, чтобы сконвертировать дробное число, полученное в результате деления миллисекунд, в целое число. Также можно использовать parseFloat() и хранить дробные данные.

• JavaScript
• zabbix
• zabbix мониторинг

1 Поддерживаемые функции триггеров

Здесь перечислены все поддерживаемые функции в выражениях триггеров:

ФУНКЦИЯ
Описания	Параметры	Комментарии
abschange
Абсолютная разница между последним и предыдущим значениями.		Поддерживаемые типы значений: float, int, str, text, log

Например:
(предыдущее значение;последнее значение=abschange)
1;5=4
3;1=2
0;-2.5=2.5

Примеры:
=> avg(#5) → среднее значение за пять последних значений
=> avg(1h) → среднее значение за час
=> avg(1h,1d) → среднее значение за час днем ранее.

Обратите внимание, что #кол-во здесь работает иначе, чем во многих других функциях (смотри last()).

Хотя сравнение выполняется побитовым образом, все значения должны подставляться и возвращаться в десятичном виде. Например, выполнение проверки 3-го бита, сравнением с 4, не со 100.

Примеры:
=> band(,12)=8 or band(,12)=4 → 3-ий и 4-ый биты установлены, но не оба в одно время
=> band(,20)=16 → 3-ий бит не установлен и 5 бит установлен.

Например:
(предыдущее значение;последнее значение=изменение)
1;5=+4
3;1=-2
0;-2.5=-2.5

Смотрите также: abschange для сравнения

оператор (опционально)

Поддерживаемые операторы : eq — равно
ne — не равно
gt — больше
ge — больше или равно
lt — меньше
le — меньше или равно
like — совпадают, если содержат шаблон (регистрозависимое)
band — побитовое И
regexp — совпадение с учетом регистра с регулярным выражением, заданным в шаблон
iregexp — совпадение без учета регистра с регулярным выражением, заданным в шаблон

Обратите внимание:
eq (по умолчанию), ne, gt, ge, lt, le, band, regexp, iregexp поддерживаются целочисленными элементами данных
eq (по умолчанию), ne, gt, ge, lt, le, regexp, iregexp поддерживаются числовыми с плавающей точкой элементами данных
like (по умолчанию), eq, ne, regexp, iregexp поддерживаются строковыми, текстовыми и журнальными элементами данных

При наличии band третьим параметром, второй параметр шаблон можно указывать двумя числами, разделенными с помощью ‘/’: количество_для_сравнения/маска. count() вычисляет «побитовое И», используя значение и маску, и сравнивает результат с количеством_для_сравнения. Если результат «побитового И» равен количеству_для_сравнения, значение засчитывается.
Если количество_для_сравнения и маска равны, то необходимо указать только параметр маска (без ‘/’).

При наличии regexp или iregexp третьим параметром, второй параметр шаблон может быть как обычным, так и глобальным (которое начинается с ‘@’) регулярным выражением. В случае глобального регулярного выражения учет регистра наследуется из настроек глобального регулярного выражения. Для цели соответствия регулярному выражению числа с плавающей точкой всегда будут представлены с 4 десятичными знаками после ‘.’. Также обратите внимание на то, что при разница между большими числами в десятичном (хранится в базе данных) и бинарном (используется Zabbix сервере) представлениях может повлиять на 4 цифру после запятой.

Примеры:
=> count(10m) → количество значений за последние 10 минут
=> count(10m,»error»,eq) → количество значений за последние 10 минут, которые равны ‘error’
=> count(10m,12) → количество значений за последние 10 минут, которые равны ’12’
=> count(10m,12,gt) → количество значений за последние 10 минут, которые больше ’12’
=> count(#10,12,gt) → количество значений из последних 10 значений, которые больше ’12’
=> count(10m,12,gt,1d) → количество значений за 10 минут 24 часами ранее, которые больше ’12’
=> count(10m,6/7,band) → количество значений за последние 10 минут, которые имеют ‘110’ (в бинарном виде) в 3 младших битах.
=> count(10m. 1d) → количество значений за 10 минут 24 часами ранее

Поддерживаемые аппроксимации :
linear — линейная функция
polynomialN — полином степени N (1 exponential — экспоненциальная функция
logarithmic — логарифмическая функция
power — степенная функция

Обратите внимание, что:
linear является умолчанием, polynomial1 эквивалент linear

режим (опционально) — запрашиваемый вывод

Поддерживаемые режимы :
value — значение (по умолчанию)
max — максимальное
min — минимальное
delta — max—min
avg — среднее

Если возвращаемое значение больше чем 999999999999.9999 или меньше чем -999999999999.9999,возвращаемое значение обрезается до 999999999999.9999 или -999999999999.9999 соответственно.

Становится не поддерживаемым только, если в выражении имеется злоупотребление (ошибочный тип элемента данных, некорректные параметры), в противном случае возвращает -1 в случае ошибок.

Примеры:
=> forecast(#10,,1h) → прогноз значения элемента данных через один час на основе последних 10 значений
=> forecast(1h,,30m) → прогноз значения элемента данных через 30 минут на основе данных последнего часа
=> forecast(1h,1d,12h) → прогноз значения элемента данных через 12 часов на основе одного часа днем ранее
=> forecast(1h,,10m,exponential) → прогноз значения элемента данных через 10 минут на основе данных последнего часа и экспоненциальной функции
=> forecast(1h,,2h,polynomial3,max) → прогноз максимального значения элемента данных, которое может достичь элемент данных через два часа, на основе данных последнего часа и кубического (третьей степени) полинома
=> forecast(#2,,-20m) → оценивает значение элемента данных, которое было 20 минут назад на основе двух последних значений (эта функция может быть более точной, чем использование last() или prev(), особенно, если элемент данных обновляется редко, скажем, раз в час)

Возвращает:
1 — если разница между штампом времени значения элемента данных и штампом времени Zabbix сервера меньше или равна T секунд
0 — в противном случае.

Обычно используется с system.localtime для проверки, что локальное время синхронизировано с локальным временем Zabbix сервера. Обратите внимание, что элемент данных ‘system.localtime’ должен быть настроен пассивной проверкой.
Также можно использовать с ключем vfs.file.time[/путь/к/файлу,modify] для проверки, что файл не обновлялся длительное время.

Обратите внимание, что #кол-во здесь работает иначе, чем во многих других функциях.
Например:
last() всегда идентичен last(#1)
last(#3) — третье самое новое значение (не три последних значения)

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

Возвращает:
0 — не совпадает
1 — совпадает

Результат:
1 — если нет полученных данных за указанный период времени
0 — в противном случае

Результат:
1 — найдено
0 — в противном случае

Если обрабатывается более одного значения, ‘1’ возвращается, если имеется по крайней мере одно совпадающее значение.

Результат:
1 — найдено
0 — в противном случае

Если обрабатывается более одного значения, ‘1’ возвращается, если имеется по крайней мере одно совпадающее значение.

Обратите внимание, что #кол-во здесь работает иначе, чем во многих других функциях.

Примеры:
=> strlen()(идентично strlen(#1)) → длина самого значения
=> strlen(#3) → длина третьего самого нового значения
=> strlen(,1d) → длина самого нового значения днем ранее.

Если возвращаемое значение больше чем 999999999999.9999, возвращаемое значение обрезается до 999999999999.9999.

Возвращает 999999999999.9999, если порог нельзя достичь.

Становится не поддерживаемым только, если в выражении имеется злоупотребление (ошибочный тип элемента данных, некорректные параметры), в противном случае возвращает -1 в случае ошибок.

Примеры:
=> timeleft(#10,,0) → время до тех пор, когда значение элемента данных достигнет нуля на основе последних 10 значений
=> timeleft(1h,,100) → время до тех пор, когда значение элемента данных достигнет 100 на основе данных последнего часа
=> timeleft(1h,1d,0) → время до тех пор, когда значение элемента данных достигнет 0 на основе одного часа днем ранее
=> timeleft(1h,,200,polynomial2) → время до тех пор, когда значение элемента данных достигнет 200 на основе данных последнего часа и предположения, что элемент данных ведет себя как квадратичный (вторая степень) полином

Важные заметки:
1) Все функции возвращают только числовые значения. Сравнение строк не поддерживается.
2) Некоторые функции нельзя использовать для нечисловых значений!
3) Строковые аргументы должны быть заключены в двойные кавычки. В противном случае, они могут быть неправильно интерпретированы.
4) У всех функций триггеров параметры сек и сдвиг_времени должны быть целым числом с опциональным суффиксом единицы времени и это требование не имеет абсолютно ничего общего с типом данных элемента данных.

Примечание

1 Функция начинает вычисляться с момента получения первого значения (если не пользуется сдвиг_времени параметр).

Функции и неподдерживаемые элементы данных

Начиная с Zabbix 3.2, функции nodata(), date(), dayofmonth(), dayofweek(), now() и time() вычисляются также и для неподдерживаемых элементов данных. Другие функции требуют чтобы элементы данных на которые они ссылаются были поддерживаемом состоянии.

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

Продолжаю свой цикл статей по настройке системы мониторинга на базе популярного бесплатного продукта. В этот раз мы подробно рассмотрим вопрос настройки мониторинга web сайта в подготовленном ранее zabbix сервере. В качестве примера возьмем какой-нибудь сторонний ресурс и проверим на нем предложенный стандартный функционал.

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

Введение

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

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

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

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

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

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

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

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 проверках среди этих семи были значения выше, чем утроенное среднее время отклика, то считаю, что сайт тормозит и надо слать уведомление. Немного замороченно, но на практике такая схема у меня себя хорошо зарекомендовала без ложных срабатываний. При этом, если возникают реальные проблемы, я их вижу. Рисуем триггер.

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

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

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

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

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

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

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

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