Агент

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

Существуют пассивные и активные проверки (п.Пассивные и активные проверки Агентов). При настройке элемента данных, можно выбрать требуемый тип:

Агент – для пассивных проверок;
Агент (активный) – для активных проверок.

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

Параметры без угловых скобок обязательны. Параметры, обозначенные угловыми скобками "<>", опциональны.

Следует обратить внимание, что при тестировании или использовании ключей элементов данных в zabbix_agentd или zabbix_get с командной строкой также нужно учитывать синтаксис командной оболочки.

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

zabbix_agentd -t "vfs.dir.count[/var/log,,,"file,dir",,0]"
zabbix_agentd -t vfs.dir.count[/var/log,,,\"file,dir\",,0]

Примечания:

(Специфичное для Linux) Агент должен иметь права "только на чтение" на файловую систему /proc. Патчи к ядру от www.grsecurity.org ограничивают права доступа непривилегированных пользователей.
vfs.dev.read[], vfs.dev.write[]: Агент будет прерывать потерянные подключения к устройствам, если значения элементов данных не опрашиваются более 3 часов. Это может произойти, если система имеет устройства с динамически меняющимися путями или если устройство было удалено вручную. Следует обратить также внимание, что эти элементы данных при использовании интервала обновления от 3 часов и более всегда будут возвращать значение "0".
vfs.dev.read[], vfs.dev.write[]: если первым параметром используется параметр по умолчанию all, то ключ вернет суммарную статистику, включая все блочные устройства, такие как sda, sdb и их разделы (sda1, sda2, sdb3…) и несколько устройств (MD raid) на основе этих блочных устройств/разделов и логические разделы (LVM) на основе этих блочных устройств/разделов. В этих случаях возвращаемые значения следует рассматривать как относительные значения (изменяемые во времени), но не как абсолютные значения.
SSL (HTTPS) поддерживается, только если Агент скомпилирован с поддержкой cURL. Иначе элемент данных станет неподдерживаемым.

Чтобы убедиться, что полученные данные не повреждены, можно указать корректную кодировку для обработки проверки (например, в "vfs.file.contents") в параметре кодировка. Список поддерживаемых кодировок (идентификаторов кодовых страниц) можно найти в документации к libiconv (GNU Project) или в документации к Microsoft Windows SDK по "Идентификаторам кодовых страниц".

Если кодировка не задана в параметре кодировка, то применяются следующие стратегии преобразования:

если кодировка не задана (или указана пустая строка), то предполагается наличие UTF-8-кодировки и данные обрабатываются "как есть";
анализ BOM – применяется к элементам данных "vfs.file.contents", "vfs.file.regexp", "vfs.file.regmatch". Предпринимается попытка определить корректную кодировку при помощи использования маркера последовательности байтов (BOM) в начале файла. Если BOM отсутствует, применяется стандартное преобразование.

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

Специфичные ключи элементов данных для Агента-2

Агент-2 поддерживает все ключи элементов данных, которые поддерживаются Агентом в UNIX и Windows. В таблицах 59-69 представлена подробная информация о дополнительных ключах элементов данных, которые можно использовать только с Агентом-2; эти ключи сгруппированы по плагинам, которым они принадлежат.

Параметры без угловых скобок обязательны. Параметры, обозначенные угловыми скобками, "< >" опциональны.

Специфичные ключи элементов данных для Windows

В таблице 70 приводится подробная информация о ключах элементов данных, которые можно использовать только с Windows-Агентом.

Мониторинг служб Windows

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

Шаг 1. Узнать имя службы.

Можно получить имя, перейдя в оснастку MMC-службы и открыв свойства службы. На вкладке Общие в значении поля, называемого "Имя службы", будет имя, которое используется при настройке элемента данных для наблюдения.

Например, если требуется наблюдать службу workstation, то служба, вероятно, будет называться lanmanworkstation.

Шаг 2. Настроить элемент данных для наблюдения за службой.

Элемент данных service.infoслужба,<парам> возвращает информацию о конкретной службе. В зависимости от требуемой информации, нужно указать опцию парам, которая принимает следующие значения: displayname, state, path, user, Startup или description. Значением по умолчанию является state, если парам не указан (service.infoслужба).

Тип возвращаемого значения зависит от выбранного парам: целое число при state и Startup; строка символов при displayname, path и user; текст при description.

Пример:

Ключ service.infolanmanworkstation;
Тип информации Числовой (целое положительное).

Элемент данных service.infolanmanworkstation будет извлекать информацию о состоянии службы как числовое значение. Чтобы преобразовать числовое значение в текстовое представление в веб-интерфейсе ("0" как "Running", "1" как "Paused" и т.д.), можно настроить преобразование значений на узле сети, на котором сконфигурирован элемент данных. Чтобы это сделать, нужно либо присоединить шаблон "Windows services by Zabbix agent" или "Windows services by Zabbix agent active" к узлу сети, либо настроить на узле сети новое преобразование значений, основанное на преобразованиях значений "Windows service state", уже настроенных в упомянутых шаблонах.

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

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