zabbix ключ что это

Русские Блоги

Подробное объяснение встроенных параметров мониторинга (Ключ) в системе мониторинга Zabbix

В Zabbix встроено множество параметров мониторинга (Key), которые можно получить в отслеживаемом объекте, указав ключ в файле конфигурации клиента, о системе, процессоре, сети, памяти, файловой системе и другой информации. Значение этих параметров мониторинга подробно описано ниже.

1. Примеры

Если мои потребности:Отслеживайте количество одновременных подключений через порт 80 веб-сервера и устанавливайте графику。

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

2. Протестировать метод получения содержания параметров мониторинга

Использовать на Zabbix сервере zabbix_get Команда может получить конкретное содержание параметров мониторинга от объекта мониторинга.

3. Фактическое значение параметров мониторинга

3.1 Информация об операционной системе (ОС)

3.2 Информация о сетевом интерфейсе (Сетевые интерфейсы)

3.3 Информация о процессе (процессы)

3.4 Информация о процессоре (CPU)

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

Результаты теста следующие:

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

Если соотношение времени ожидания ввода-вывода слишком велико, это означает, что производительность ввода-вывода жесткого диска низкая. Если чтение и запись файлов происходят чаще, требования к эффективности чтения и записи относительно высоки. Можно рассмотреть вопрос о замене жесткого диска или использовании нескольких дисков в качестве решения Raid.

3.5 Информация о памяти (Память)

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

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

3.6 Информация о файловой системе (Файловые системы)

Индекс файловой системы указывает максимальное количество файлов, которые могут быть созданы. В системах, где нужно создавать много файлов, вам нужно обратить пристальное внимание на это значение. Если емкость файловой системы не исчерпана, но количество inode исчерпано, файлы больше не могут быть созданы.

3.7 Информация о веб-приложении (WebApp)

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

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

3.8 Информация о безопасности (Безопасность)

3.9 Информация об агенте (Пинг агента)

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

Интеллектуальная рекомендация

Замена персонажа

Базовые знания Python3: List

Просто поймите: 1. Типы элементов в списке могут быть разными, он поддерживает числа, строки и даже списки (так называемая вложенность). 2. Список представляет собой список элементов, заключенн.

NOIP 2017 Улучшенное сокровище группы ___ государственное давление dp + dfs

HYSBZ-2002: Bounce Bouncing Sheep (алгоритм блокировки)

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

Источник

Мониторинг RabbitMQ в Zabbix и скрытые возможности Zabbix key

Вступление

&nbsp&nbsp&nbsp&nbspСтолкнувшись с задачей замониторить большое кол-во метрик в RabbitMQ кластере, появилось желание создать универсальный парсер для JSON данных. Задача усложнялась тем, что появляются и пропадают метрики динамически во время работы кластера, плюс к этому разработчики постоянно хотят собрать/посчитать что-то новое. К сожалению, в Zabbix нет возможности собирать данные в таком виде из коробки. Но есть такая удобная фича как zabbix_trapper, позволяющая делать гибкую кастомизацию. В статье пойдет речь о не сосвем стандартном способе использовании айтемов zabbix_trapper. Мне не хотелось каждый раз, когда разработчики попросят добавить новых метрик, изменять скрипт, который собирает данные и засылает в заббикс. Отсюда появилась идея использовать собственно сам zabbix key как инструкцию по сбору новой метрики. Суть в следующем, мы используем zabbix key как команду, с заранее заданным синтакисом. То есть zabbix key в этом случае будет служить инструкцией, подобной ключам типа zabbix_agent.

&nbsp&nbsp&nbsp&nbspСогласно официальной документации Zabbix, item key имеет некоторые ограничения на допустимые символы. Немного поиграв с созданием ключей типа zabbix trapper нашел, что к примеру ключ вида:

создаются в заббиксе без ошибок. То есть ограничения работают только на то, что вне [ ] скобок, также обязательно должен быть хотя бы один символ [a-z][A-Z] перед скобками. Имея возможность создавать такие ключи мы можем придумать свой синтаксис ключей и запрограммировать в нем довольно гибкую логику. Далее остается только написать обработчик придуманного синтаксиса который будет делать всю основную работу. И наконец, написав доку по этому обработчику и выложив код в паблик, у всего Zabbix community появится возможность обмениваться такими «как бы» плагинами.

&nbsp&nbsp&nbsp&nbspВ целом статья получилась немного сложная для понимания, поэтому чтобы лучше понять концепцию, я бы советовал сначала ознакомиться с RabbitMQ API, хотя бы просто посмотреть как выглядят данные и что предоставляет API (см. офф сайт).

&nbsp&nbsp&nbsp&nbspСсылки на код приведены в конце статьи.

Как это работает

&nbsp&nbsp&nbsp&nbspСначала создаем в Zabbix фронт-енде айтемы типа zabbix_trapper согласно разработанному синтаксису(синтксис будет описан ниже). Далее запускаем обработчик (rmq_data_collect.pl — далее коллектор) в кроне с частотой сбора информации, скажем 1 минута. Теперь коллектор взаимодействует с Zabbix сервером и с сервером RabbitMQ как указано на схеме:

Т.е. скрипт делает 3 основных шага:

1) Запрашивает список айтемов с Zabbix сервера, которые должны быть собраны.
2) Забирает все необходимые данные с RabbitMQ согласно списку айтемов выше.
3) Отправляет все собранные данные на Zabbix сервер/прокси на соотв-ие айтемы.

&nbsp&nbsp&nbsp&nbspПри первом обащении обработчик может взаимодействовать как через Zabbix API так и напрямую с базой. В моей реалзации взаимодействие происходит с базой Zabbix прокси. Этот подход удобней при использовании распределенного мониторинга с некоторым кол-вом Zabbix прокси серверов. В этом случае скрипт должен быть установлен на zabbix прокси сервере, а в конфигурации скрипта должны быть прописаны данные для коннекта к базе этой же прокси.

&nbsp&nbsp&nbsp&nbspКроме обработчика будет также рассмотрен еще дискаверер, который используется для low level discovery. Далее пойдет речь о текущей реализации мониторинга для RabbitMQ, теория и примеры настройки.

Что реализовано

&nbsp&nbsp&nbsp&nbspВ документации по RabbitMQ API описано 9 API url’ов + есть еще federation-links, который ставится отдельным плагином на реббит. Возможно есть и еще что-то. В текущей реализации моих скриптов возможен мониторинг следующих API path:

-nodes
-connections
-queues
-bindings
-federation-links

Для моих задач этого хватило, в случае если нужны еще какие-то API path то нужно дописать их в ф-ю map_rmq_elements (см. комментарии к коду).

Установка и настройка скриптов

&nbsp&nbsp&nbsp&nbspДля мониторинга RabbitMQ понадобится установить и настроить 2 скрипта (Collector и Discoverer) + ZabbixProxyDB.pm. Скрипты могут быть установлены как на Zabbix сервере так и на прокси, зависит от вашей конфигурации Zabbix.

Collector

rmq_data_collect.pl — Используется для обработки заббикс ключей и сбора данных с rabbitmq.

Имеет один входной параметр

Discoverer

rmq_data_discover.pl — Используется для низкоуровневого обнаружения в Zabbix (low level discovery или LLD).

Использование
Имеет 3 обязательных входных параметра:

$1 — полное имя RabbitMQ хоста в Zabbix, если RabbitMQ не запущен как кластер. Для кластера принцип тот же что у коллектора. После первого успешного ответа прохождение по списку остановится и начнется компиляция сообщения для низкоуровневого обнаружения (low level discovery).

$2 — regexp по которому произойдет отбор метрик в момент работы скрипта. Не путать с regexp фильтром на стороне Заббикс в настройках LLD. Такое разделение удобно в некоторых случаях.

$3 — RabbitMQ API path, любой из списка поддерживаемых (см. п. Что реализовано).

&nbsp&nbsp&nbsp&nbspСкрипт должен быть установлен в папку externalscripts, прописанную в конфигурации Zabbix прокси/сервера. Примеры настройки правил LLD приведены в конце статьи.

Пример конфигурации хостов в Zabbix

&nbsp&nbsp&nbsp&nbspЕсть кластер rabbitmq состоящий из трех хостов. Сами хосты по отдельности мониторятся заббикс агентами, темплейт Template_Linux, где собраны стандартные метрики по CPU, memory и т.д. Для метрик кластера создан отдельный хост ”rmq-host». Имя хоста для всего кластера — общая часть имен хостов в кластере. Это обязательное условие в текущей реализации, иначе выборка из базы будет работать не корректно.

Синтаксис ключей

Теперь поговорим о разработанном мной синтаксисе для реббита. Как уже было сказано выше, в Zabbix айтемы должны иметь тип zabbix trapper.

Для мониторинга реббита Есть два типа item’ов, simple и aggregated, их синтаксис незначительно отличается. Simple айтемы используются для выборки значений отдельных параметров. Aggregated айтемы используются для выборки массива значений по заданному условию и их аггрегации. В обоих случаях условия может быть не указано(опционально).

Значения Simple

— Путь к значению внутри каждого элемента массива.

$type — может быть название VHOST или “general”, в случае VHOST поиск значений будет вестись по указанному VHOST, «general” — является ключевым словом, необходимым для значений, которые не относятся к конкретным VHOST’ам.

$api_path — RabbitMQ API path, любой из поддерживаемых (см. п. Что реализовано).

Значения Aggregated

aggregated — является ключевым словом, после которого коллектор(rmq_data_collect.pl) понимает что синтаксис ключа должен быть разобран как для значения типа aggregated.

$api_path — путь к API, любой из поддерживаемых (см. п. Что реализовано).

$func — реализованы 2 функции, sum и count.

$conditions — опциональный параметр, если задан, то при аггрегации будут учитываться только те элементы в массиве данных, которые подходят под условие. Синтаксис условий следующий: [condition1=“cond1”,condition2=“cond2”,condition3=“cond3”,etc]. Кавычки обязательны. Само условие является Perl регекспом.

Функция sum
Синтаксис:

Функция sum суммирует значения находящиеся по указанному пути

— Путь к значению внутри каждого элемента массива полученного по RabbitMQ API path.

rmq — является обязательным словом, но никак не используется(тут может быть абсолютно любой набор букв). Это связано с ограничениями Zabbix на ключ айтема типа “zabbix_trapper” — айтем не может начинаться с квадратной скобки.

Примеры

Агрегированые значения

1) Считает сумму элементов running в массиве nodes. Прим: В случае если rabbitmq нода работает, running возвращает 1, соот-но на выходе получаем кол-во работающих нод.

3) Считает общее кол-во элементов в массиве nodes. Т.е. кол-во настроенных нод в класетере.

4) Считает общее кол-во элементов в массиве connections. Т.е. кол-во соединений к кластеру в данный момент.

5) Считает кол-во элементов в массиве connections, у которых type=“^direct$” и protocol=»^Direct\s0-9-1$”.

Примеры для значений simple есть дальше в LLD. Т.к. задавать их статически не удобно, большинство очередей постоянно появляются и исчезают.

Low level discovery

В слуачае большой конфигурации rabbitmq кластера разумно будет использовать низкоуровневое обнаружение Zabbix. Использование rmq_data_discover.pl описано выше. Здесь я приведу примеры и значения возвращаемые скриптом.

Значение, возвращаемые скриптом и которые можно использовать в LLD:

Замечание: все элементы с пустым source игнорируются.

Примеры LLD

Примеры запуска правил для каждого API path:

Примеры айтем прототипов

В API path queues мы можем собирать статистику по обработанным сообщениям, не заботясь о кол-ве очередей.

1) Значение поля idle_since. Единственное поле которое имеет обработку внутри rmq_data_collector.pl. Как результат получаем timestamp, с момента которого очередь неактивна.

2) Значение ack внутри элемента message_stats.

3) Оставшиеся значения работают с message_stats также как п.2

Пример для connections

Айтем подсчитывает кол-во элементов в массиве connections с заданными type,protocol для каждого <#VHOST>.

Пример для nodes

1) Считает кол-во соединений к каждой ноде.
2) Возвращает значение поля running для каждого элемента массива nodes. На выходе получаем health статус каждой ноды.

Подведем итог

&nbsp&nbsp&nbsp&nbspНадеюсь получилось не слишком запутанно. Если что то не понятно, отвечу на все вопросы в комментариях.

&nbsp&nbsp&nbsp&nbspПреимущество описанного подхода в создании кастомных ключей, специализированных для какого то конкретного софта, очевидно. Нет необходимости в изменении кода самого Zabbix. Уже сейчас мы можем создавать такие плагины, писать по ним документацию и обмениваться готовыми решениями в интернете. Если развивать идею создания кастомизированных ключей в Zabbix дальше, то в идеале хотелось бы видеть это, возможно, в виде новой фичи. Имея подобный плагин теперь, когда нужно добавить какуюто новую метрику по RabbitMQ, нужно просто создать соотв-ий айтем, как это делается для zabbix_agent.

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

1 Формат ключа элемента данных

Имя ключа

Имя ключа имеет ограниченный диапазон разрешенных символов, которые просто следуют друг за другом. Разрешенные символы:

Параметры ключа

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

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

Если параметр ключа это строка, заключенная в кавычки, тогда разрешен любой символ в Юникоде.

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

Если строка ключевого параметра содержит кавычки, этот параметр должен быть заключен в кавычки, а каждая кавычка, являющаяся частью строки параметра, должна экранироваться символом обратной косой черты (\).

Если параметр ключа это строка без кавычек, тогда разрешен любой символ в Юникоде, за исключением запятой и правой квадратной скобки (]). Параметр, который не заключен в кавычки, не может начинаться с левой квадратной скобки ([).

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

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

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

Ключи элементов данных

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

Обратите внимание, агент не может отправлять события из «Пересланные события» журнала.

Параметр режим поддерживается начиная с версии 2.0.0.
“Windows Eventing 6.0” поддерживается начиная с Zabbix 2.2.0.

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

Смотрите дополнительную информацию о мониторинге файлов журналов.net.if.listСписок сетевых интерфейсов (включая тип, состояние, IPv4 адрес, описание интерфейса).ТекстПоддерживается Zabbix агентом начиная с версии 1.8.1. Начиная с версии 1.8.6 Zabbix агента поддерживаются мультибайтные имена интерфейса. Отключенные интерфейсы не входят в список.

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

Обратите внимание, что для корректной работы этого элемента данных на 64-битной системе потребуется 64-битный Zabbix агент.

Элементы данных service.info[служба,state] and service.info[служба] вернут одинаковую информацию.

Обратите внимание, что только парам равный state у этого элемента данных возвращает значение по несуществующим службам (255).

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

Этот ключ поддерживается начиная с Zabbix 3.0.7 и 3.2.3.

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

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

Шаг 1

Узнайте имя службы.

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

Например, если вы хотите наблюдать службу “workstation”, то ваша служба скорее всего будет: lanmanworkstation.

Шаг 2

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

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

Имеется два преобразования значений Windows service state и Windows service startup type, которые сопоставляют числовое значение в веб-интерфейсе его текстовому представлению.

Обнаружение служб Windows

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

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

1 Создание элемента данных

Обзор

Для создания элемента данных в веб-интерфейсе Zabbix, выполните следующее:

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

Настройка

Вкладка Элемент данных содержит следующие атрибуты элементов данных.

Все обязательные поля ввода отмечены красной звёздочкой.

Предобработка значений элемента данных

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

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

Тестирование

Можно протестировать элемент и, если он настроен правильно, в результате получить реальное значение. Тестирование может проводиться даже до сохранения элемента.

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

Тестирование предметов доступно для следующих типов пассивных элементов данных:

Источник