zabbix запуск скрипта python
Русские Блоги
Выполнять скрипты Python с помощью пользовательских элементов мониторинга zabbix_agent, установленных docker
Zabbix_agent, установленный docker, не имеет среды Python, поэтому он не может выполнять сценарии Python.
1. Вы можете установить zabbix_agent напрямую через apt, не используя docker
2. То есть докер устанавливает zabbix_agent
(1) Мне нужно настроить эксклюзивный zabbix_agent через dockerfile, здесь я сам пытаюсь написать много dockerfile, и я не могу его попробовать. Наконец, я все еще смотрю на документ докера: zabbix_agent description и нашел следующий рисунок:
Это означает, что вы можете использовать zabbix_agent в качестве базового изображения для добавления своего нового изображения
В конце концов, я обнаружил, что не установил vim, поэтому я, наконец, изменил файл конфигурации zabbix_agent через том контейнера.
(2) Напишите док-файл, который нужно упаковать в изображение
(3) Запустите образ сборки
Скатать контейнер с файлом конфигурации zabbix_agent в локальный каталог
Этот контейнерный том предназначен для переноса пользовательского тома контейнера Python-скрипта в контейнер.
(4) Измените файл конфигурации zabbix_agent, чтобы иметь возможность добавлять пользовательские элементы мониторинга для выполнения сценариев.
Путь к файлу конфигурации в пути контейнера: /etc/zabbix/zabbix_agentd.conf
(5) Используйте zabbix_get на сервере, чтобы проверить, могут ли данные быть успешно получены
(6) Установите на странице мониторинга zabbix
Zabbix. Список установленных программ.
Будем использовать Zabbix для слежения за списком установленных программ.
Замечание 1.
Способ установки Python 2.7 описан тут: https://www.mihanik.net/tihaja-ustanovka-python-2-7/
Замечание 2.
1. Собираем данные по установленным программам при помощи скрипта.
Скрипт написан на Python 2.7, он собирает данные по установленным программам и формирует 2 файла:
Скрипт сохранён под именем C:\Zabbix\scripts\soft_list\programmlist.py.
2. Устанавливаем скрипт в системе.
Скрипт лучше запускать каждый час, – не слишком часто, но и не слишком редко.
Запланировать выполнение скрипта можно при помощи планировщика Windows. Задание планировщика можно создать вручную, а можно и при помощи bat-файла.
3. Формируем шаблон в Zabbix.
В Zabbix при этом добавляем несложный шаблон.
Сначала приведу описание шаблона в картинках.
Имя шаблона: Active Computer – Python – ProgramList…
Добавляем группу элементов данных…
Теперь добавляем 3 элемента данных…
И, наконец, несложный триггер, который будет срабатывать при изменении списка программ…
А вот и готовый для импорта заархивированный файл с описанным выше шаблоном: zbx_export_template_programlist.xml
Описанные ранее скрипты можно найти в этом архиве: soft_list
4. Сбор данных.
Осталось назначить созданный шаблон соответствующему узлу сети и ждать начала поступления данных. 🙂
Аренда серверов.
Надёжные сервера с Pro-бегом
У ВАС В ОФИСЕ!
1С:Предприятие “в облаке”.
Безопасный доступ к своей 1С из офиса, командировки и т.п.!
IP-телефония в офис.
Использование Zabbix API. Когда не хватает стандартной статистики
Возникла задача получить некоторую статистику из Zabbix, делюсь опытом получения данных из базы Zabbix через API средствами Python.
Куски кода будут для Python 2.7
Для работы с zabbix-api есть готовая библиотека py-zabbix, документация по ней доступна тут, но примеров там не много. Официальное руководство по Zabbix API.
Итак, после стандартной установки:
Пробуем подключиться к серверу Zabbix:
Формат ответа от сервера — JSON:
Скрипт печатает содержимое поля result:
Теперь можно приниматься за решение интересующей задачи. Задача — получить среднее значение Disk Idle Time со всех виртуальных машин за неделю (Пн-Пт) в рабочее время (с 10:00 до 19:00) за определенную неделю. Я не хочу заострять внимание на актуальности этих параметров, а просто поделиться опытом работы с Zabbix API на примере этой конкретной задачи.
Итак, виртуальные машины в Zabbix лежат в отдельной группе, для начала получим список доступных групп с помощью метода hostgroup.get:
Параметром output можно определить, какие поля вернет API:
Затем можно получить список хостов в конкретной группе с помощью метода host.get:
Параметр groupids определяет идентификатор группы:
Для получения списка items по определенному хосту используется метод item.get:
Как видно из ответа, выбранный хост имеет 2 диска, нужно вывести минимальное значение из нескольких. Для доступа к данным по items используется метод history.get. Следующий код не претендует на оптимальность, я только начал осваивать Python, но в целом с поставленной задачей скрипт справился.
Для метода history.get нужно определить следующие параметры:
В результате получаем разделенные запятой имя хоста, кол-во винтов и min idle time:
Zabbix Documentation 3.0
Sidebar
Table of Contents
11 Внешние проверки
11.1 Обзор
Внешняя проверка исполняется Zabbix сервером выполнением shell скрипта или бинарного файла. Однако, когда узлы сети наблюдаются через Zabbix прокси, внешние проверки выполняются через этот прокси.
Внешние проверки не требуют на наблюдаемом узле сети какого-либо агента.
Синтаксис ключа элемента данных:
АРГУМЕНТ | ОПРЕДЕЛЕНИЕ |
---|---|
скрипт | Имя shell скрипта или бинарного файла. |
параметр(ы) | Опциональные параметры командной строки. |
Если вы не хотите передавать какие-нибудь параметры скрипту, вы можете использовать:
Zabbix сервер заглянет в папку указанную как размещение внешних скриптов (параметр ‘ExternalScripts’ в файле конфигурации Zabbix сервера) и выполнит заданную команду. Команда будет выполнена от имени пользователя под которым запущен Zabbix сервер, так что любые права доступа или переменные среды должны быть обработаны в оболочке скрипта, если необходимо, и права доступа на команду должны разрешать этому пользователю выполнение скрипта. Для выполнения доступны только те команды, которые имеются в наличии в указанной папке.
11.2 Пример использования
Выполнение скрипта check_oracle.sh с первым параметром “-h”. Второй параметр будет заменен IP адресом или DNS именем узла сети в зависимости от выбранного в настройках узла сети.
Предположим, что узел сети настроен на использование IP адреса, тогда Zabbix выполнит:
11.3 Результат внешней проверки
Результирующим значением проверки является стандартный вывод вместе со стандартным выводом ошибок (возвращается полный вывод с обрезанными пробелами в конце начиная с Zabbix 2.0).
В случае, если выполняемый скрипт не найден или Zabbix сервер не имеет необходимых прав на его запуск, элемент данный становится неподдерживаемым и будет возвращено соответствующее сообщение об ошибке. В случае превышения времени ожидания, элемент данных также помечается как неподдерживаемый, соответсвующее сообщение об ошибке будет отображено и отдельный процесс этого скрипта будет ликвидирован.
Мониторим всё: расширение агентов Windows и Linux при помощи скриптов
Если нам нужно мониторить состояние серверов и прочих компьютеризированных рабочих мест при помощи Zabbix, то это можно сделать двумя способами.
Первый способ — это при помощи SNMP-запросов, с отправкой которых Zabbix замечательно справляется. Так можно вытащить и загрузку сетевых интерфейсов, и загрузку процессора, памяти. Поверх этого, производители сервера могут выдать нам по SNMP еще много информации о состоянии железа.
Второй заключается в использовании Zabbix агента, который мы будем запускать на наблюдаемой системе. Список наблюдаемых параметров включает в себя как и такие простые вещи, как загрузка процессора, использование памяти, так и более хитрые, такие как чтение текстовых лог-файлов с поддержкой ротации или отслеживание факта изменения любого файла. Можно даже в качестве параметра использовать вывод любой произвольной команды на системе. Возможности Zabbix агента растут от версии к версии.
Что делать, если того, что мы хотим контролировать через Zabbix нет в списке возможностей Zabbix агента? Ждать пока это имплементируют разработчики в следующем релизе? Не обязательно.
Нам оставили несколько стандартных интерфейсов для того, чтобы расширить возможности Заббикса по мониторингу серверов настолько, насколько позволит нам наша фантазия и наличие свободного времени на написание скриптов. Интерфейсы эти UserParameter и zabbix_sender. О первом и пойдет речь, а в качестве примеров будет показано как можно собирать состояние S.M.A.R.T жестких дисков и контролировать, когда кто-то удаляет или устанавливает новые программы на своей Windows-машине.
Немного матчасти
Если вы уже хоть раз настраивали Zabbix агент на сервере, то начать использовать UserParameter не составит труда. Чтобы добавить новый параметр нужно сделать несколько вещей:
— уникальное имя, которое мы придумываем сами. Будем его использовать при настройке элемента данных в Zabbix.
— команда, которую нужно выполнить на наблюдаемом узле сети.
А вот сразу очень простой пример, который лежит в каждом стандартном конфиге для Linux:
и затем выставляем ключ такой же, как указали в конфиг-файле, а тип Zabbix агент:
Мониторинг SMART через UserParameter
Пример выше имеет мало практического применения, учитывая, что уже итак существует стандартный ключ system.users.num, который делает ровно тоже самое.
Так что теперь рассмотрим пример, который уже больше будет походить на реалистичный.
Если нам интересно мониторить момент, когда пора планово менять жесткие диски, то есть два варианта:
и утилита готова к использованию.
Для каждого диска, который есть в системе сначала проверим, что SMART включен:
если вдруг SMART поддерживается диском, но выключен, то активируем его:
Теперь мы можем проверять статус SMART командой:
Именно эту команду мы и запишем в наш zabbix_agentd.conf:
где uHDD.health — ключ.
Мониторинг SMART через Flexible UserParameter
Тут возникает резонный вопрос, как быть если дисков два. Легче всего решить эту проблему поможет способность UserParameter передавать параметры агенту, про которую мы еще не упоминали. Но делается все очень просто, сразу пример:
В веб-интерфейсе Zabbix в ключе мы будем подставлять параметры в квадратные скобки вместо *. Например, для одного элемента данных мы напишем sda, а для другого sdb. В команде этот параметр найдет отражение там, где стоит переменная $1.
Создадим для второго диска элемент данных:
И через некоторое время сможем наблюдать результат в последних данных:
Мониторинг SMART через Flexible UserParameter c Low-level Discovery
Все получилось. Но тут возникает резонный вопрос, как быть если дисков не два, а двадцать два. И тут нам пригодится замечательная возможность низкоуровнего обнаружения (LLD), про которую мы уже говорили.
Низкоуровневое обнаружение позволяет системе мониторинга обнаруживать какое количество однотипных элементов присутствует на узле сети и динамически по шаблону создавать необходимые элементы данных, триггеры и графики для этих элементов. «Из коробки» системе доступна возможность находить файловые системы, сетевые интерфейсы и SNMP OID’ы. Однако, и здесь разработчики оставили возможность дополнить стандартные возможности, нужно просто передать в систему информацию о том, какие элементы обнаружены в формате JSON. Этим и воспользуемся.
Создадим маленький скрипт на perl, smartctl-disks-discovery.pl. Он будет находить все диски в системе и выводить эту информацию в JSON, передавая также информацию, включен ли у диска SMART или нет, а также попытается сам включить SMART, если он выключен:
При запуске скрипт выдает:
Теперь, для того чтобы скрипт автоматически запускался Zabbix’ом, просто добавим еще один UserParameter в zabbix_agentd.conf:
Покончив с настройкой конфига, переходим в веб-интерфейс, где создаем новое правило обнаружения для smartctl:
Обратите внимание на ключ и на фильтр, (<#SMART_ENABLED>=1) благодаря последнему будут добавляться только те обнаруженные диски, которые поддерживают SMART. Теперь мы можем переписать два наших элемента данных для дисков sda и sdb в один прототип элементов данных, просто заменив имя диска на макрос <#DISKNAME>:
Последнее, перед тем, как Zabbix сможет запускать команды, которые мы прописали в zabbix_agentd.conf из-под root и мониторить SMART, нужно добавить разрешения для его пользователя запускать эту команду без ввода пароля, для этого добавим в /etc/sudoers строчку:
Готовый шаблон для мониторинга SMART с остальными элементами данных, триггерами прикладываю, так же как и настроенный под него конфиг.
Контроль за установкой новых программ на Windows
Zabbix агент, установленный на Windows, точно также может быть расширен через UserParameter, только команды будут уже другие. Хотя, например, smartctl — кроссплатформенная утилита, и точно также можно ее использовать для контроля за жесткими дисками в Windows.
Кратко рассмотрим еще другой пример. Задача получать уведомление каждый раз, когда пользователь самостоятельно удаляет или устанавливает программы.
Для этого будем использовать наш vbs-скрипт:
Для его интеграции с Zabbix добавим UserParameter в конфиг-файл:
Добавим элемент данных в шаблон для Windows:
Добавим триггер:
и действие, которое будет отправлять e-mail уведомление:
Весь процесс мониторинга выглядит так: каждый час запускается скрипт Zabbix агентом, который сравнивает два списка программ: текущий и предыдущий. Затем скрипт выписывает все изменения в отдельный файл. Если же изменений нет, то в файл пишется 0x0
Содержимое файла уходит на Zabbix сервер, где поднимается триггер в случае, если значение элемента данных uDiffProgramms отлично от 0x0. Затем отдельное действие отправляет по почте уведомление со списком того, что было установлено или удалено на данном компьютере:
В итоге
UserParameter — отличная и простая возможность расширить функционал системы самостоятельно. Стоит упомянуть и альтернативы: zabbix_sender, который, например, подойдет для тех случаев, когда нужно отправлять данные в Zabbix не по расписанию, (как это делает UserParameter), а по какому-то событию; и system.run[], который похож на UserParameter, но удобнее тем, что не нужно вносить изменения во все конфиги агентов, достаточно просто добавить этот элемент данных в шаблон. Более того, в следующем крупном релизе Zabbix 2.2 нас ожидает еще один новый способ расширить возможности агента- это подключаемые модули. Ждем с нетерпением!
Вот так, считайте, что если вы можете узнать что-то о системе скриптом или командой, значит, вы всегда можете передать это в Zabbix.