Zabbix 3.4: массовый сбор данных на примерах счетчика меркурий и smartmontools

Введение

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

• High CPU utilization
• Load average is too high
• Too many processes on hostname

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

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

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

1. Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper.
2. Разрешаю на zabbix agent запуск внешних команд.
3. Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender.

Приступаем к реализации задуманного. Я буду настраивать описанную схему на Zabbix Server версии 5.2. Если у вас его нет, читайте мою статью по установке и настройке zabbix. В качестве подопытной системы будет выступать Centos. Так же предлагаю мои статьи по ее установке и предварительной настройке.

Сразу же сделаю важное замечание. Все, что написано далее, полностью придумано и реализовано мной

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

Краткая история

29 выпуск SDCast в августе 2015 немного пролил свет на то, как всё происходило. Zabbix был создан в 1998 для нужд банка Алексеем Владышевым. В те времена он был написан на языке Perl. Позднее проект был сильно переработан, в частности — переписан на C и PHP, изменилась его архитектура. В 2001 году Zabbix открыл исходные коды под свободной лицензией GPL, а стабильная версия 1.0 была выпущена спустя три года, в 2004. В 2005 была создана компания Zabbix SIA, занимающаяся оказанием платных технических услуг, связанных с ПО. Почти каждый год выходят новые версии системы. Основные крупные релизы: 2.0 (в 2012), 3.0 (в 2016) и 4.0 (в 2018).

А в чем была собственно проблема?

• медленные запуски утилит каждый раз, на каждый нужный элемент данных
• обращение к ресурсу (диск, порт, счетчик, API приложения) на каждый элемент данных
• парсинг результата нужно было делать внешними скриптами/утилитами
• а если потом нужно было поправить парсинг – приходилось опять обновлять UserParameters или скрипты
• кроме всего прочего, одновременные запросы от нескольких Zabbix pollers приводили к ошибке при обращении, например, к последовательному порту.

зависимых элементов данных

• В Zabbix 3.4 источником данных может выступать другой элемент данных, который называется родительским или мастер-элементом. Такой элемент может, например, содержать массив данных в формате JSON, XML или произвольном текстовом формате.
• В момент поступления новых данных в родительский элемент, остальные элементы данных, которые называются зависимыми, обращаются к родительскому элементу и при помощи таких как JSON path, XPath или Regex выделяют из текста нужную метрику.

шаблон для сервера

Настройка Zabbix

Предупреждение: Zabbix настраивал в первый раз, как и Linux Mint (так как Zabbix под Windows нет) autoconfautomakelibtoolpkg-configlibzbxmodbusХабреGitHub

libzbxmodbusetc/zabbix/zabbix_server.conf/dev/ttyUSB0lsusb

Шаг 1. Создаем узел сети и группу, в которые наши узлы будут входить (например, узел — «Контроль состояния окружающей среды» и группу — «Инженерная инфраструктура»):
Настройка > Узлы сети > Создать узел сети > Вводим наши названия > Добавить
Шаг 2. Создадим элементы данных. В статье рекомендуется создавать шаблоны, но так как у нас система не содержит повторяющихся элементов, поэтому пропущу этот шаг. Например, если бы у нас было несколько кондиционеров, подключаемых по Modbus, то можно было бы воспользоваться функционалом системы.
Настройка > Узлы сети > В строке содержащей название нашего узла «Контроль состояния окружающей среды» нажимаем на «Элементы данных» > в появившемся окне нажимаем «Создать элемент данных».
Начинаем «забивать» наши датчики:
Небольшие нюансы:

• в статье используется синтаксис функции «modbus_read_registers», а по описанию GitHub «modbus_read» — второй вариант короче и работает;
• можно вместо макросов {$MODBUS_PORT} и {$MODBUS_SLAVE} указывать порт в виде /dev/ttyUSB0 и «11», но это будет неудобно, если потом потребуется изменить порт USB или адрес С2000-ПП;
• в документации указано, что для запроса состояния зоны (столбец «№ зоны Modbus») на С2000-ПП необходимо обратиться на: «адрес регистра 40000+М, где М = (№ зоны –1)» — вот так ход: «№ зоны минус 1»;
• не делайте очень частый опрос по времени: С2000-ПП начнет возвращать ошибку «exception error 15» — прибор не успевает подготавливать данные (выражается это в постоянном свечении индикатора на приборе) ;
• для температуры и влажности забираются данные с регистрами 3000-…
• в окне «Элементы данных» также есть нужная закладка «Предобработка». Тут можно отредактировать, что будет показываться «в итоге». Температура и влажность, получается из считываемых значений, которые необходимо разделить на 256: «Пользовательский множитель»- 0,0039 (т.е. 1/256);
• Для дискретных герконов, датчиков протечки и т.п. нужно еще использовать «Отображение значений», связано это со способом предоставления информации.

914835188

Сканируем!

Запуск основного скрипта обработки данных () происходит автоматически, один раз в сутки, через «Service Item…» на хосте «Vulners — Statistics» в указанное скриптом время.

Вы можете поменять время запуска плагина на любое удобное вам, изменив «Scheduling interval» в этом элементе данных. При этом необходимо откорректировать и время сбора статистики в трех элементах данных шаблона «Vulners OS-Report» – метрики в шаблоне должны срабатывать минут на 10…15 раньше, чем основная метрика «Service Item…» на хосте «Vulners — Statistics».

Время за которое будут обработаны все данные об уязвимостях зависит от количества серверов в инфраструктуре и количества установленных на них пакетов. Ориентировочно на обработку 1 тысячи серверов тратится около 30 минут.

Планы

Это лишь первая версия плагина Zabbix Threat Control. И мы продолжаем его разработку.

• Добавить на дашборд информацию по найденным в инфраструктуре CVE.
• Отказаться установки каких либо скриптов на агенты и собирать всю необходимую информацию об ОС и пакетах с помошью встроенных в Zabbix-агент ключей элементов данных.

В другой руке Vulners

• Агрегатор данных об уязвимостях из более чем 115 источников
• Удобное API для различных способов сканирования
• Выдает данные в нормализованном, машино-читаемом виде
• Работает очень быстро
• Позволяет коррелировать данные из различных источников

Мы попробовали их друг с другом интегрировать и вот что из этого получилось.

Zabbix Threat Control

Это плагин к Zabbix, с открытым исходным кодом, написан на Python, который:

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

CVSS это открытый промышленный стандарт оценки критичности уязвимости. По сути — 10 бальная шкала.

Zabbix Moscow Meetupвидео

JavaScript для Zabbix

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

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

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

Задача 1

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

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

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

Проблемы:

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

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

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

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

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

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

  

  

  

  

  

  

  

  

  

  

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

В триггере можно указать выражение ‘last<‘ и набор цифр, который соответствует количеству секунд в периоде, на которое необходимо отреагировать, например, в неделях. Таким образом, триггер будет оповещать о том, что срок действия сертификата заканчивается через неделю.

ПРИМЕЧАНИЕ

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

Настройка Zabbix

Импорт шаблона

Откройте веб-интерфейс Zabbix. По умолчанию он находится по адресу http://IP-адрес сервера/zabbix.

Зайдите в систему. 

• Логин —Admin
• Пароль —zabbix

Перейдите в раздел Configuration > Templatesи нажмите в правом углу кнопкуImport. В списке шаблонов появитсяTemplate App R-Keeper 7. 

Выберите загруженный файл и снова нажмите кнопку Import.Рекомендуем удалить ненужные шаблоны. Для этого отметьте их галочками и нажмите кнопкуDeleteвнизу.

Создание хостов

Чтобы создать хост, необходимо сначала создать группу. Для создания перейдите в Configuration > Host Groups и нажмите кнопкуCreate host groupв правом углу .Укажите название новой группы и нажмитеAdd

Теперь создайте сами хосты. Перейдите в Configuration > Host и нажмитеCreate host 

Заполните поля:

• Host name— имя хоста. Разрешена только латиница без пробелов. Обязательно должно совпадать с именем, указанным в INI-файле сервера.
• Visible name— отображаемое имя. Может содержать пробелы и русский язык
• Groups— группа хостов
• Agent interfaces— адрес Zabbix-агента. Укажите здесь IP и порт с r_keeper_7, который вы хотите мониторить
• Остальные поля заполнять не нужно. 

Перейдите на вкладку Templates, нажмитеAddи выберите в списке шаблон Template App R-Keeper 7, установленный ранее. Это действие можно сделать позже в массовом порядке.

НажмитеSelect. Шаблон добавится к хосту. Нажмите кнопкуAdd, чтобы сохранить настройки хоста.

Хост появится в списке. Повторите действия для всех нужных хостов.Убедитесь, что для каждого хоста выбран правильный шаблон, иначе данные отображаться не будут.

На этом настройка завершена, можно переходить к наблюдению. 

Настройка мониторинга за процессами

На Zabbix сервере идем в стандартный шаблон Linux и добавляем туда 2 новых айтема:

1. Process List — список процессов, ограниченный десятью с самой высокой нагрузкой на cpu. Сюда будем записывать информацию о процессах на сервере при срабатывании триггеров на повышенную нагрузку CPU.
2. Full Process List — полный список всех процессов. Сюда запишем полный список всех процессов, когда сработает триггер на превышение максимально допустимого количества запущенных процессов на сервере.

Так выглядит первый айтем. Второй сделайте по аналогии.

Теперь идем на сервер с агентом и пробуем отправку данных в данный айтем. Для этого нам нужен будет zabbix_sender. Если у вас его нет, то установите.

# yum install zabbix-sender

Отправку данных проверяем следующим образом:

/usr/bin/zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k process.list -o "`ps aux --sort=-pcpu,+pmem | awk 'NR<=10'`"

Я не буду подробно останавливаться на формате запросов с помощью zabbix_sender. Все это хорошо описано в документации. Теперь идем в веб интерфейс сервера и в разделе Последние данные смотрим на список процессов, который нам пришел с целевого сервера.

Ровно то, что нам было нужно. То же самое можно проверить с айтемом Full Process List, убрав в команде | awk ‘NR<=10’ в конце.

Далее нам нужно создать действие, которое будет запускать данную команду на сервере при срабатывании триггеров. Для этого идем в раздел Настройка -> Действия и добавляем новое.

Сохраняйте действие и можно проверять.

Обзор

Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.

Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.

На данный момент доступна система Zabbix 4.4. Скачать ее можно на официальном сайте. Там же можно найти официальные курсы и вебинары для начинающих пользователей системы.

Далее рассмотрим, из чего состоит и как работает технология Zabbix в доступном формате «для чайников».

Smartctl и smartmontools

писалиподход

• избыточные запуски утилиты smartctl, а она в свою очередь каждый раз обращалась к контроллеру жесткого диска
• пришлось делать отдельный парсинг для Linux и Windows. Особенно больно с этим сейчас работать в Win: (for /F… так… экранируем двойные кавычки еще кавычками…. Аааа!!!!)

• smartctl нам JSON не возвращает
• дисков в сервере может быть различное количество, поэтому нам нужно использовать низкоуровневое обнаружение(LLD).

• uHDD.i
• uHDD.health

Тестируем, смотрим что получилось

• мы убрали весь парсинг из UserParameters
• нет внешних скриптов (кроме LLD), нет внешних зависимостей, весь парсинг происходит на Zabbix-сервере, там его легко посмотреть и подправить, если нужно
• когда утилита или API не возвращает XML/JSON – не беда, всегда можно попробовать использовать регулярные выражения
• жесткие диски больше не мучаем – сначала достаем весь список параметров S.M.A.R.T., а затем уже на Zabbix-сервере раскладываем его по метрикам.

здесь

Магия JavaScript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка оборудования Болид

Orion-progUprogYouTube

• указываем типы датчиков: для температурного — 10, для измерения влажности — 15, для все остальных — 6 (технологический);
• для технологических входов задаем «Время восстановления, с» — это время, через которое шлейф возвратится в состояние «Норма» после получения состояния «Нарушение». Нужно указать цифру не менее интервала опроса в Zabbix (я принял 10 секунд);
• отключим «Управление индикацией АУ» (0), «Контроль на обрыв и КЗ» и «Контроль состояния резервной батареи», чтобы упростить настройку.

• первый столбец я указал «3» — это адрес прибора С2000-КДЛ в системе «Орион»;
• номер ШС («шлейф сигнализации») — это адреса датчиков (фактически ШС=адрес, можем пропустить несколько адресов, если не хотим забирать с них информацию);
• № раздела Modbus — можно сгруппировать наши датчики в группы. В целях упрощения — я этого не стал делать и всем приписал 1 раздел;
• тип зоны — очень важный параметр. Выбираем его, согласно типу датчика.

Modpoll Modbus Master Simulatorздесь

Интерфейс

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

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

Управление шаблонами в Zabbix

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

Управление группами хостов в Zabbix

Графики в Zabbix

Диаграммы в Zabbix

Управление системой так же осуществляется через веб интерфейс: именно там создаются и настраиваются группы, серверы, сбор параметров, триггеры и прочее. Возможно создание множества аккаунтов с разными уровнями доступа.

Управление пользователями в системе

Настройка прав доступа

Контроллер

• С2000-КДЛ — базовая модель (обозначение расшифровывается как «Система 2000 — Контроллер Двухпроводной Линии связи»);
• С2000-КДЛ-2И — добавлены гальванические развязки для RS-485 и ДПЛС;
• С2000-КДЛ-Modbus — в конструкцию С2000-КДЛ-2И добавлен преобразователь протокола Modbus С2000-ПП.

ДПЛС

• относятся к конфигурируемому типу, а не программируемому (т.е. нужно только настроить параметры, а не разрабатывать программу);
• поддержка в ДПЛС до 127 адресных устройств (С2000-ВТ имеет два адреса), причем многие пуско-наладчики не рекомендуют использовать больше 100-110;
• двойной ввод по питанию DC 12-24В;
• не слишком удобная конструкцию корпуса (все подключаемые провода невозможно спрятать в корпусе прибора и приходится их убирать сзади прибора).

• кольцевой шлейф — обрыв шлейфа в одном месте не влияет на наличие сигналов от адресных датчиков;
• использование ответвительно-изолирующих блоков (БРИЗ) — позволяет делать радиальные ответвления, а также изолировать сегмент шлейфа, в котором произошло замыкание «ДПЛС+» и «ДПЛС-».

JavaScript и Duktape

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

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

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

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

Особенности Duktape:

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

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

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

Низкоуровневые обнаружения в теории

LLD появился в Zabbix где-то с версии 2.0. Эта техника применяется не только для автообнаружения на хостах, LLD еще очень хорошо разгружает работу сервера Zabbix. В случае активной проверки сервер Zabbix сам отправляет запрос на хост, чтобы получить метрику. Обычно запрос ставится в очередь наряду со всеми остальными запросами и обрабатывается в порядке очереди, но, если метрик много, сервер будет серьезно загружен. В случае с LLD в режиме проверки хост zabbix-trapper сам отправляет серверу список метрик, а спустя небольшое время — и сами метрики со значениями. То есть нагрузка выходит минимальная. Сервер сам решает, что принимать, а что нет, исходя из настроек.

Реализация технологии LLD на хосте следующая: используется связка «приложение — скрипт — сендер Zabbix — сервер Zabbix». Давайте пройдемся по всем этапам, чтобы было понятнее.

1. Инициализация скрипта.
2. Запрос от скрипта к приложению на получение метрик.
3. Обработка запроса от скрипта приложением.
4. Ответ скрипту от приложения с передачей данных.
5. Формирование скриптом JSON LLD для передачи имен метрик на сервер Zabbix.
6. Выдача JSON при вызове скрипта.
7. Обработка полученных от приложения данных путем формирования метрик и их значений (к примеру, с записью в файл).
8. Вызов сендера Zabbix скриптом и инициализация отправки метрик на сервер.
9. Сендер передает запрос на сервер Zabbix. Режим проверки на сервере zabbix-trapper.
10. Сервер Zabbix считывает метрики и отправляет ответ для сендера.
11. Сендер получает ответ от сервера и логирует его на экран или в файл.

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

Схема взаимодействия компонентов Zabbix LLD

В остальных вопросах вы можете смело обращаться к документации Zabbix. Русскоязычная документация лежит в открытом доступе.

Устраняйте найденные уязвимости

Но мало знать какие у нас уязвимости и определить как и какие из них можно устранить. Необходимо ещё и сделать это!

Для централизованного управления конфигурациями и обновления ПО широко используются такие системы как Puppet или Ansible. Вы можете использовать fix-команду, устраняющую уязвимость, и централизованно её выполнить с помощью таких систем.

Если же в вашей инфраструктуре не используются такие системы — Zabbix Threat Control позволяет устранять уязвимости прямо из веб-интерфейса Zabbix.

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

1. Как только проблема будет подтверждена через веб-интерфейс авторизованным на это пользователем;
2. Запустится удаленная команда, которая выполнит на целевом сервере, или списке серверов, fix-команду исправляющую уязвимость.