Zabbix Api Примеры
Содержание До сих пор мы изучали как работает большая часть компонентов сервера и как воздействовать на Zabbix для извлечения данных из различных внешних источников. Принимая это во внимание, настройте свою систему мониторинга в большой, гетерогенной и сложной инфраструктуре. Скорее всего вы обнаружите различные индивидуальные устройства, серверные приборы, а также проприетарное аппаратные средства.
Обычно всё это оборудование имеет интерфейс для обработки запросов, однако, зачастую оказывается что большая часть этих измерений не выставляется через SNMP ( Simple Network Management Protocol) или любой другой стандартный метод опроса. Давайте рассмотрим пример из практики. В наши дни ИБП владеют температурными датчиками и, если вы находитесь в сложной инфраструктуре, вероятно, эти ИБП имеют индивидуальное исполнение и не придерживаются стандартов и, скорее всего, эти датчики могут опрашиваться исключительно инструментальными средствами, предоставляемыми производителем этих ИБП. Итак, значение температуры ИБП является критически важным параметром, в особенности если ИБП является большим, выполненным на заказ. Действительно важно осуществлять наблюдение за этими параметрами. Представим себе, что ваша система охлаждения не работает должным образом; получение предупреждения непосредственно когда температура достигает опасного уровня является фундаментально важным.
Пример Azure: Azure zabbix template samples. Интернет и мобильные устройства. Интернет и мобильные.
Zabbix Api Примеры
- Home; Blog; Portfolio; About; Contact; Blog. - Инструкция По Шкуросьемной Машине; - Доту Для.
- Установка и настройка мониторинга Zabbix 2.2.
С другой стороны, предсказание отказа сохранит значительные денежные средства. К тому же, даже если физическое разрушение в действительности не столь затратно, время простоя может стоить значительных средств и иметь ужасное воздействие на ваш бизнес. Хорошим примером является торговая компания. При таком сценарии всё должно работать исключительным образом. В данной среде существует жуткая конкуренция для достижения лучшей чем у конкурентов производительности - покупка рыночных акций на несколько миллисекунд раньше остальных даёт большое преимущество. В данном случае легко понять, что если серверы не работают хорошо, это уже проблема; если они падают, это полная катастрофа для данной компаниию Данный пример объясняет насколько критично предсказывать отказы. Более того, важно понимать насколько критично извлекать параметры функционирования вашей инфраструктуры.
Именно здесь Zabbix приходит на выручку, предоставляя интересные методы получения данных, которые взаимодействуют с операционной системой, с течением времени делая вам возможным использование инструментов командной строки. Zabbix откликается на данный вид требований следующим образом. Ирина денисова всего то навсего ноты.
Внешние проверки (серверная сторона). UserParameter (сторона агента). Zabbixsender: Этот исполняемый файл может применяться как на стороне агента, так и на стороне сервера. Простой, эффективный и лёгкий в реализации протокол взаимодействия Данная глава целиком раскроет данные альтернативы для взаимодействия с операционной системой и получения данных от внешних источников. В этой главе вы освоите что не существует общего, оптимального решения всех проблем, однако каждое из них имеет свои за и против.
Данная глава осведомит вас обо всех вещах, которые должны приниматься во внимание когда вы реализуете выполняемые на заказ проверки. Предлагаемый в этой главе анализ позволит вам выбирать лучшее решение ваших проблем. В данной главе мы охватим следующие моменты. Внешние проверки Zabbix предоставляет функции для обслуживания всех тех элементов, которые нельзя достичь при помощи стандартного агента. В реальной жизни может случиться так, что вы не будете иметь возможности установить стандартный агент на некоторый прибор, для которого вы хотите осуществлять мониторинг.
Примером из практики может служить конкретный ИБП, все ваши сервера которые, по ряду причин, могут оказаться скомпрометированными после установки на них внешнего программного обеспечения, или другие устройства, которые не могут иметь устанавливаемого индивидуального программного обеспечения. Итак, когда по всем этим причинам вы не можете иметь агента на своём устройстве, однако вам необходимо осуществлять мониторинг жизненно важных параметров этого устройства, единственным выполнимым решением для которого будет применение внешней проверки. Углубляясь во внешние проверки Теперь самое время для практического примера. Это простой пример для понимания того, как работает внешний сценарий.
В следующем примере мы будем подсчитывать число открытых файлов для определённого пользователя. Первая вещь, которую необходимо выполнить, это создать сценарий и расположить его в ExternalScripts. Этот сценарий будет называться lsof.sh и будет содержать следующий код: #!/bin/bash if grep -q $1 /etc/passwd then lsof -u $1 tail -n +2 wc -l else echo 0 fi Для этой программы требуется имя пользователя в качестве входного параметра; она проверяет существует ли данный пользователь в вашей системе, после чего возвращает общее число открытых файлов для данной учётной записи. Теперь вам необходимо создать новый элемент с типом External check. В поле Key введите lsof.sh'postgres', как это отображено на снимке экрана внизу. Совет До настоящего момента мы рассматривали случай сервера Zabbix который непосредственно осуществляет мониторинг некоторого хоста с использованием внешнего сценария.
Имейте в виду, что если ваш хост осуществляет мониторинг через прокси Zabbix, этот сценарий необходимо размещать на самом прокси в качестве того сценария, который должен выполняться с данного прокси. Теперь, когда вы знаете как работает ExternalScripts, самое время посмотреть как мы можем реализовать что- то более сложное благодаря данной функциональности. В следующем примере мы будем осуществлять мониторинг определённого удалённого экземпляра Oracle. Существуют некоторые предварительные требования чтобы данная настроку оказалась полностью работающей: клиент Oracle устанавливается с рабочими sqlplus, tnsping а также учетной записью, настроенной на вашу целевую базу данных Oracle.
Самая последняя версия для данного программного обеспечения доступна для загрузки по адресу. Тем не менее, интересно посмотреть как она исполняется в версии 1.0.
Версия 1.0 доступна для загрузки напрямую из форума Zabbix по адресу. Этот сценарий является хорошим примером внешней проверки.
В целом, чтобы иметь всё настроенным надлежащим образом, вам необходимо выполнить следующее. Создать учётную запись пользователя во всех ваших базах данных, подлежащих мониторингу. Настроить своего клиента Oracle.
Развернуть данный пакет в местоположении вашего внешнего сценария. Настроить учётную запись вашей базы данных в /checkora/credentials. Создать хост с тем же именем что и ваш экземпляр базы данных. Последний пункт особенно важен и является определённым режимом применения Zabbix. Данный метод может повторно использоваться всякий раз, когда вам необходимо агрегировать метрики, которые не связываются с реальными хостами, а только с некоторой службой.
Для выполнения примера из практики, допустим у вас имеется СУБД, которая может быть отказоустойчивой при поддержке другого сервера, вы просто можете создать обманный хост Zabbix который называется тем же именем, которое имеет ваша базаданных. Теперь, если данная служба выполняет действия по осуществлению отказоусточивости, у вас не будет прерывания в вашем сборе данных, так как процесс осуществления отказоустойчивости является прозрачным для сервера, который поддерживает эту службу.
Данный метод применяется в нашем случае, поскольку клиент Oracle будет обрабатывать отказоустойчивость автоматически, в случае, когда он настроен надлежащим образом Теперь вы можете продвинуться вперёд и создать хост с тем же самым именем что и ваш SID, например, у вас имеется подлежащий мониторингу экземпляр Oracle, который определён как ORCL в tnsnamesora; таким образом, ваш хост Zabbix будет именоваться ORCL. Совет Вы можете создать хосты, связанные с именами соответствующей службы; это позволит вам абстрагировать данную службу от того хоста, который предоставляет такую службу. Подробности настройки лиента Oracle выходят за рамки данной книги. Когда вы выполните эту настройку, вы сможете протестировать данный сценарий просто выполнив следующую команду: checkora.sh-i -q В предыдущей командной строке представляет имя вашего экземпляра, а является вашим файлом запроса, который вы хотите выполнить. Существует великое множество файлов предварительно построенных запросов в вашем каталоге checkora; вы можете проверить их все для своей базы данных. Совет Начиная с Zabbix 2.4, поток стандартного вывода связан вместе с стандартным потоком ошибок внутри вашего сценария.
Помните что, если запрашиваемый сценарий не найден или не имеет достаточных полномочий для исполнения на сервере Zabbix, данный элемент становится неподдерживаемым. Кроме того, в случае таймаута в обоих предыдущих случаях будет отображено сообщение об ошибке и ответвлённый процесс для этого сценария будет уничтожен. Обсуждение внешних проверок В данном разделе вы увидели как может быть выполнена внешняя проверка и как ею обрабатывается сложная задача навроде мониторинга базы данных. Если у вас имеется для реализации несколько внешних проверок, это может стать возможным решением для получения замеров. Такой вид подхода с внешними проверками, к сожалению, не является решением для всех ваших проблем. С другой стороны, вам необходимо учитывать, что они действительно интенсивно используют ресурсы и некогда широко применялись.
Так как внешние проверки располагаются на стороне сервера, будет лучше не перегружать ваш сервер Zabbix. Параметр пользователя Простая вещь, которую можно сделать чтобы избежать чрезмерного использования ресурсов вашим сценарием состоит в помещении этого сценария на сторону агента. Zabbix предоставляет альтернативный метод и ваш сценарий, вместо того чтобы быть на стороне сервера и загружать ваш сервер Zabbix может разгружаться на сторону агента посредством UserParameter. UserParameter определяется в файле настройки вашего агента. Когда он настроен, он трактуется тем жа самым способом, как и все остальные элементы агента Zabbix простым применением своего ключа описываемого в ваших параметрах опций.
Для определения параметра пользователя вам необходимо в файл настройки агента нечто аналогично приводимому ниже: UserParameter=, Здесь key должен быть уникальным, а команда shell представлять вашу команду для выполнения. Команда может быть определена здесь внутри строки и нет необходимости создавать сценарий, как это показано в следующем примере: UserParameter=process.number, ps -e wc -l В этом примере ключ process.number будет извлекать общее число процессов в вашем сервере.
Аналогичным образом вы можете проверять общее число пользователей, которые в настоящее время подключены, применив следующий код: UserParameter=process.number, who wc -l. Гибкий параметр пользователя Как легко понять, применяя данный метод вы собираетесь определить большое число элементов внутри файла настроек своего агента. Это не правильный подход, так как лучше поддерживать свой файл настроек простым. Zabbix предоставляет интересную функциональность UserParameter во избежание быстрого увеличения таких элементов на стороне агента - гибкий параметр пользователя. Эта функция включается при помощи элемента следующего вида: UserParameter=key., В данном случае key всё ещё должен быть уникальным, а выражение. определяет, что данный ключ принимает определёные параметры.
Содержимое между квадратными скобками разбиратеся и подставляется при помощи $1.$9; отметьте, пожалуйста, что $0 ссылается на саму команду. В качестве примера UserParameter можно представить: UserParameter=oraping.,tnsping $1 tail -n1 Данная команда выполнит tnsping к вашему SID, передавая его в качестве $1.
Вы можете применить тот же самый метод в своём процессе подсчёта определённых пользователей следующим образом: UserParameter=process.number., ps -e grep ^$1 wc -l Затем, если мы хотим переместиться на сторону агента для своего первого сценария, который возвращал общее число открытых файлов для определённого пользователя, настройка будет такой: UserParameter=lsof.sh.,/usr/local/bin/lsof.sh $1 Когда это добавлено, вам остаётся только перезапустить своего агента. На стороне сервера вам необходимо переключить Type своего элемента на Zabbix agent и сохранить это.
Следующий снимок экрана рисует это обсуждение. Совет Вы можете проверить UserParameter воспользовавшись командной строкой, как это описывалось ранее, или применив утилиту zabbixget. Воспользовавшись zabbixget, вам не понадобится дожидаться того чтобы увидеть данные между самыми последними, к тому же это самый простой способ отладки, который осуществляется на вашей стороне агента.
Существуют способы проверки того хорошо ли работает ваш UserParameter и способен ли ваш агент распознавать его. Первый состоит в zabbixget; например, в случае losf.sh со стороны сервера Zabbix мы можем применить следующее: # zabbixget -s 127.0.0.1 -p 10050 -k lsof.sh'postgres' 2116 Ответ является результатом данной операции. В качестве альтернативы мы можем зарегистрироваться на подвергающемся мониторингу хосте и выполнить следующую команду: #/usr/sbin/zabbixagentd -t lsof.sh'postgres' lsof.shpostgres/usr/local/bin/lsof.sh postgres t 2201 Опять же, это высветит ваш вывод и сам сценарий который вызывается. Обсуждение параметров пользователя При помощи UserParameter вы перемещаете свой сценарий со своего сервера на сторону своего агента. Производимая данным сценарием рабочая нагрузка теперь находится на стороне агента и вы избегаете уворовывания ресурса на стороне своего сервера. Другим подлежащим рассмотрению моментом является то, что такой подход разделяет нагрузку между множеством серверов. Очевидно, каждый агент будет осуществлять мониторинг своей базы данных, присутствующей на его хостах.
Параметры UserParameter действительно являются гибкими. Чтобы включить их на стороне агента, вам необходимо изменить его файл настройки и перезапустить этот агент. Кроме того, в этом случае вам необходимо быть уверенным, что возвращаемое значение установлено надлежащим образом; если это не так, оно будет отвергаться. Теперь, помимо всех против, вам необходимо учесть эффект своего наблюдателя (обсуждавшийся в ) вносимый таким видом мониторинга.
Вам необходимо оставлять вещи лёгкими по возможности, в особенности из- за того, что ваш агент выполняется на том же сервере, который предоставляет эту службу. Применение UserParameter подразумевает что вам необходимо распространять ваши сценарии и относительные обновления по всем вашим серверам. В данном примере, когда вы хотите осуществлять мониторинг Oracle, вам необходимо рассматривать сколько различных версий операционных систем и программного обеспечения вам необходимо обрабатывать. Может оказаться, что вам потребуется обрабатывать мириады различных версий ваших сценариев и программного обеспечения. Такое несметное число сценариев, версий и тому подобного хранится в централизованном репозитории.
Кроме того, вам необходимо учитывать добавляемую вашими сценариями рабочую нагрузку и, если они не обрабатывают все возможные исключительные ситуации должным образом, это может быть действительно сложным для управления сеансом. UserParameter действительно являются хорошими, гибкими и порой не допускающими исключений для решения некоторых требований мониторинга, однако не разработанными для массивного мониторинга одного и того же хоста. По всем этим причинам наступает время изучить другой способ массового мониторинга ваших элементов которые Zabbix не поддерживает естественным образом. Ниже приведены определённые очень важные моменты о внешних сценариях и UserParameter. Все детали ввода передаются в качестве параметров в ваши сценарии и должны быть надлежащим образом очищаться в пределах сценария для предотвращения внедрения команд.
Все значения возвращаются через STDOUT и должны быть в формате ожидаемом для возвращаемого типа. Если не возвращается ничего, это вызывает то, что сервер Zabbix помечает данный элемент как неподдерживаемый. Убедитесь, что все сценарии завершаются в короткий промежуток времени. Во избежание условий конкуренции или некорректного взаимодействия со стороны испытывающих многократное исполнение сценариев, проверьте что они не используют совместно или блокируют какие- либо ресурсы, или имеют какой- либо побочный эффект. Отправка данных посредством zabbixsender До сих пор вы видели как реализовывать внешние проверки как на стороне своего сервера, так и на стороне вашего агента, что приводит к перемещению рабочей нагрузки с осуществляющего мониторинг хоста на подверженный мониторингу хост. Вы можете понять почему оба метода в случае большой загрузки и интенсивного мониторинга не являются лучшим подходом когда мы думаем о помещении Zabbix в большую среду. Скорее всего, лучше иметь выделенный для всех наших проверок сервер и применять обе эти функциональности для всех наших проверок, которые не работают повсеместно.
Zabbix предоставляет утилиты разработанные для отправки данных на свой сервер. Такой утилитой является zabbixsender, и при её помощи мы можем отсылать данные элемента на ваш сервер используя элементы Zabbix типа ловушек (trapper).
Чтобы проверить утилиту zabbixsender, просто добавьте элемент ловушки Zabbix в существующий хост и выполните команду: zabbixsender -z -s -k -o Вы получите отклик, похожий на следующее: Info from server: 'Processed 1 Failed 0 Total 1 Seconds spent 0.0433214' sent: 1; skipped: 0; total: 1 Только что вы увидели как просто использовать утилиту zabbixsender. Это говорит о том, что теперь мы можем выделить сервер для всех наших сценариев, интенсивно использующих ресурсы. За и против выделенного сервера сценариев При данном подходе у нас имеется выделенный сервер для извлечения данных. Это означает, что вы не перегружаете свой сервер, который предоставляет вам службу или свой сервер Zabbix, и это действительно хороший момент. К сожалению, данный подход страдает гибкостью, и в данном определённом случае все ваши элементы обновляются каждые 5 минут. С другой стороны, при ваших внешних проверках или с использованием UserParameter частота обновлений может меняться и быть персонально настраиваемой для элемента.
В данном определённом случае, при котором вовлечён сервер базы данных, присутствует эффект наблюдателя, вносимый нашим сценарием. Наш запрос может быть настолько легковесен, насколько мы пожелаем, однако для извлечения элемента sqlplus будет запрашивать Oracle для соединения. Такое соединение будет использоваться всего несколько секунд (время, необходимое для извлечения нашего элемента), после чего данное соединение будет закрыто. Все эти рабочие нагрузки обычно нуждаются в объединённом в пул подключении. Применяя пул подключений вы можете ощутимо сократить эффект наблюдателя в своей базе данных.
Замечание Уменьшение общих накладных расходов при помощи пула соединений является общей концепцией, причём она не увязывается с особенностями производителя базы данных. В общем случае, базы данных будут страдать если они убиваются частыми запросами на новые соединения и закрытие соединения. Сбор соединений в пул всегда хорошая вещь, которой следует придерживаться в общем случае. Чтобы лучше понять преимущества такой методологии, вы можете рассмотреть сложную сетевую среду с путём, который пересекает различные межсетевые экраны и правила, прежде чем достигнет получателя; наличие постоянного соединения является явным преимуществом. Наличие пула постоянных соединений, поддерживаемых действующими пакетаами keep-alive уменьшает значение латентности для извлечения необходимого элемента из вашей базы данных и, в общем случае, нагрузку на сетевую среду в целом.
Создание нового соединения включает процесс подтверждения всех пересекаемых межсетевых экранов. Кроме того, вам необходимо иметь в виду, что если вы используете Oracle, первый запрос на соединение выполняется к приёмнику (listener), который потребует обратной связи при приёме и тому подобного. К сожалению, пулы соединений не могут быть реализованы при помощи компонентов оболочки. Существуют различные реализации пулов соединений, однако, прежде чем мы окунёмся глубже в суть стороны программирования, самое время посмотреть на то, как работают протоколы Zabbix. Протокол get Zabbix Протокол Zabbix get действительно очень простой и лёгкий в реализации. Практически вам необходимо всего лишь отослать данные на свой сервер Zabbix на порт 10050. Это текстовый протокол и он применется для извлечения данных из агента напрямую.
Этот протокол настолько прост, что вы можете его реализовать даже в оболочке: root@zabbixserver# telnet 127.0.0.1 10050 Trying 127.0.0.1. Connected to 127.0.0.1. Escape character is '^'. Agent.version ZBXD2.0.6Connection closed by foreign host. Этот пример показывает как извлекать версию агента просто воспользовавшись telnet.
Отметьте, пожалуйста, что ваши данные возвращаются с заголовком, которым является ZBXD, вслед за которым непосредственно следуют данные, представляющие реальный отклик 2.0.6. Данный простой протокол полезен для извлечения данных из конкретного агента установленного на нашем сервере и ис пользуемого в сценарии оболочки. Этот протокол полезен для идентификации версии агента без регистрации на вашем сервере и для проверки всех экземпляров UserParameter, определённых для некоторого агента.
Протокол sender Zabbix Протокол Zabbix sender является протоколом JSON. Сообщение составляется следующим образом: Раздел составляет 5 байт и представляется в виде ZBXD x01.
Zabbix Api Python Примеры
В действительности только первые 4 байта являются заголовком, следующий байт используется для определения версии протокола. В настоящее время поддерживается только версия 1 ( 0x 01 HEX). Раздел является 8 байтами в длину в шестнадцатеричном представлении. Таким образом, например, 1 выражается как 01/00/00/00/00/00/00/00, 8-байтовым (64- битным) числом в шестнадцатеричном формате.
За ним следует. Этот раздел представляется в формате JSON. Замечание Часы определяются как переменная int64 без знака.
Это действительно важное свойство, так как если вы пишите свой собственный zabbixsender, вы можете определять временной штамп того, когда данный элемент был извлечён. Существенным моментом является то, что при тестировании данного раздела Zabbix сохраняет значение времени часов, показывающих когда был извлечён данный элемент из вашей базы данных. Применение свойств часов в элементах JSON Знание этого совйтсва может быть применено для оптимизации вашего sender. Zabbix поддерживает 128МБ для отдельного соединения. Конечно, лучше избегать этого предела, так как если мы достигнем его, это будет означать, что наша реализация не будет выполнена надлежащим образом. Свойство часов может применяться в двух сценариях.
Если необходима буферизация отправляемых элементов и если они отправляются внутри отдельных пакетов соединения. Если ваш сервер не доступен, вы можете выполнить кеширование и отправить этот элемент позже Первый вариант применения этого свойства является очевидной оптимизацией для сохранения всего вашего взаимодействия настолько легковесным, насколько это возможно, а уменьшение общего числа соединений с нашим сервером Zabbix может предотвращать проблемы. Второй вариант делает возможным реализацию надёжного sender, который может обрабатывать время простоя сервера Zabbix и предохранять элементы в кеше в состоянии готовности к отправке до того момента, когда сервер вернётся в строй и заработает. Будьте любезны не наводнять свой сервер если он не доступен в течение длительного периода времени. Управляйте своим соединением путём отправки разумного числа элементов вместо длинного хвоста элементов. Совет В данном случае мы рассматриваем тот вариант, что вы хотите осуществлять мониторинг всех своих служб, доступных на некотором сервере и последующий запускающий механизм отправки вам сигнала тревоги в случае, если порт становится недоступным. Важно рассмотреть и другой случай, при котором вы находитесь в зоне DMZ и вы хотите иметь запускающий механизм если, по какой- либо причине, служба является доступной.
Zabbix Api Php Примеры
Одним из типичных примеров является порт прослушивания (listener) вашей базы данных, который должен быть доступен только в пределах вашей DMZ, а не с внешней стороны её. Это просто один пример автоматизации, причём достаточно простой, однако мы можем продвинуть автоматизацию дальше.
Мы можем рассмотреть сетевую среду, в которой у вас имеется чётко определённый домен служб, и вы знаете используется ли демон или где, по крайней мере, не изменён титул демона для сокрытия идентичности данной службы. В данном случае полезная персонализация обнаружения отыщет все те порты и, если за ними идентифицированы определённые службы, применит соответствующий шаблон к подлежащему мониторингу серверу.
Например, мы можем полагать, что если порт 80 открыт, то за ним находится служба Apache, и затем применить шаблон Apache выполненный индивидуально для данного хоста. Это, безусловно, автоматизирует и снизит стоимость и время начального запуска. Взаимодействие с Zabbix Теперь вы знаете как работает протокол Zabbix, поэтому настало время рассмотреть некий код, который реализует данный протокол. Чтобы оставить вещи простыми, мы должны объяснить пример протокола zabbixsender - самого простого способа отправки данных Zabbix. Zabbix применяет JSON для описания объекта содержащего данные.
Существует множество эффективных библиотек JSON которые можно применять, однако, чтобы сделать здесь вещи более простыми, такие библиотеки не будут использоваться.