как посмотреть значения zabbix agent
какой командой на zabbix сервере можно посмотреть их значения?
malex1
21.09.13 13:52:31 MSK
Думаю эта часть руководства по zabbix будет полезна. Создаем узел, добавляем элемент типа snmp и наблюдаем.
digitaldark ★
( 21.09.13 14:04:56 MSK )

как посмотреть значения zabbix agent
есть мибы для сервака Из HP Mib LogDrvStatus1 .1.3.6.1.4.1.232.3.2.3.1.1.4.0.1
snmp запрашивается не через zabbix агента.
Если ты хочешь посмотреть значения zabbix агента, используй
Если ты хочешь смотреть snmp oid’ы, используй тот же самый snmpwalk. Весия snmp, имя пользователя и пароли выбираются исходя из настроек сервера.
Какого поколения proliant? snmp agents из состава support pack ставил?
router ★★★★★
( 21.09.13 14:09:50 MSK )
Последнее исправление: router 21.09.13 14:10:02 MSK (всего исправлений: 1)
Ответ на: комментарий от router 21.09.13 14:09:50 MSK
спасибо за ответ. буду использовать zabbix agent так как вроде есть готовый шаблон вопрос где взять значения . zabbix_get -s -k
malex1
( 17.10.13 08:53:44 MSK ) автор топика
Ответ на: комментарий от malex1 17.10.13 08:53:44 MSK

Из официальной документации:
Но это не то, что следует использовать для snmp. Так какого поколения сервер? g1, g2, . g8 ?
dmidecode | grep ProLiant -i
router ★★★★★
( 17.10.13 09:25:02 MSK )
Ответ на: комментарий от router 17.10.13 09:25:02 MSK
есть сервера g3, g5, g6, g7, g8 я поставил zabbix agent подключил стандартный шаблон для winows мониторинг диска, загрузка проц, памяти есть . а вот RAID там нет, вот мне нужно мониторить их также
malex1
( 17.10.13 11:52:38 MSK ) автор топика
Ответ на: комментарий от malex1 17.10.13 11:52:38 MSK

эту информацию можно получить через snmp
Для этого на серверах g1 .. g7 тебе нужно установить на ОСь hp-snmp-agents из состава support pack, и snmp запросы отправлять на адрес сервера
А на g8 эту информацию по snmp тебе отдаёт сам ilo. Для этого тебе нужно обновить прошивку ilo ( точную версию не помню, ilo 4 2.20 уже подойдёт ) и настроить на нём snmp. И snmp v3 запросы отправлять на адрес ilo
router ★★★★★
( 17.10.13 12:26:48 MSK )
Ответ на: комментарий от router 17.10.13 12:26:48 MSK
если делать через агента, без snmp например вот элемент из шаблона вычисление свободного места на диске, и ключ
тип — zabbix agent vfs.fs.size[d:,free] показывает свободное место на диске
как выполнить запрос на самом zabbix-сервере чтобы посмотреть это значение? и где найти ключи, например для raid контроллера
malex1
( 17.10.13 13:12:15 MSK ) автор топика
Ответ на: комментарий от malex1 17.10.13 13:12:15 MSK

как выполнить запрос на самом zabbix-сервере
через запуск zabbix_get на самом zabbix сервере
и где найти ключи, например для raid контроллера
Ещё раз тебе говорю, нужно делать через snmp, а не zabbix агента. Либо пиши свои скрипты и добавляй их как сказано в https://www.zabbix.com/documentation/ru/2.0/manual/config/items/userparameters
Если захочешь писать свои костыли для zabbix agent, тебе придётся, например, анализировать вывод
hpacucli ctrl all show config
Использование Zabbix API. Когда не хватает стандартной статистики
Возникла задача получить некоторую статистику из Zabbix, делюсь опытом получения данных из базы Zabbix через API средствами Python.

Куски кода будут для Python 2.7
Для работы с zabbix-api есть готовая библиотека py-zabbix, документация по ней доступна тут, но примеров там не много. Официальное руководство по Zabbix API.
Итак, после стандартной установки:
pip install py-zabbix
Пробуем подключиться к серверу Zabbix:
from pyzabbix import ZabbixAPI z = ZabbixAPI('https://172.16.1.10', user='user1', password='pass1') answer = z.do_request('apiinfo.version') print "Version:",answer['result']
Формат ответа от сервера — JSON:
Скрипт печатает содержимое поля result:
Version: 3.0.2
Теперь можно приниматься за решение интересующей задачи. Задача — получить среднее значение Disk Idle Time со всех виртуальных машин за неделю (Пн-Пт) в рабочее время (с 10:00 до 19:00) за определенную неделю. Я не хочу заострять внимание на актуальности этих параметров, а просто поделиться опытом работы с Zabbix API на примере этой конкретной задачи.
Итак, виртуальные машины в Zabbix лежат в отдельной группе, для начала получим список доступных групп с помощью метода hostgroup.get:
#Get List of available groups groups = z.hostgroup.get(output=['itemid','name']) for group in groups: print group['groupid'],group['name']
Параметром output можно определить, какие поля вернет API:
38 _Local Domains 53 _Local NAS 23 _Local Servers Linux 27 _Local Servers Virtual Linux 25 _Local Servers Virtual Windows 24 _Local Servers Windows 35 _Local Switches
Затем можно получить список хостов в конкретной группе с помощью метода host.get:
#Get List of hosts in the group hosts = z.host.get(groupids=25, output=['hostid','name']) for host in hosts: print host['hostid'],host['name']
Параметр groupids определяет идентификатор группы:
10197 DC1_--172.16.1.4-- 10204 DC2_--172.16.1.5-- 10637 LocalDB_--172.16.1.12-- 10686 WSUS_--172.16.1.16-- 10708 Jira_--172.16.1.24--
Для получения списка items по определенному хосту используется метод item.get:
#Get List of items on the host items = z.item.get(hostids=10637, output=['itemid','name']) for item in items: print item['itemid'],item['name']
525617 ICMP ping 525618 ICMP loss 525619 ICMP response time 940205 Input Microsoft Hyper-V Network Adapter #2 940206 Output Microsoft Hyper-V Network Adapter #2 990808 Disk Idle time on C: 990809 Disk Idle time on D:
Как видно из ответа, выбранный хост имеет 2 диска, нужно вывести минимальное значение из нескольких. Для доступа к данным по items используется метод history.get. Следующий код не претендует на оптимальность, я только начал осваивать Python, но в целом с поставленной задачей скрипт справился.
Для метода history.get нужно определить следующие параметры:
- history — тип возвращаемого значения
- itemids — id интересующего item
- time_from — начало временного интервала
- time_till — конец временного интервала
from pyzabbix import ZabbixAPI import time import sys z = ZabbixAPI('https://172.16.1.10', user='user1', password='pass1') groupid = 25 #Local Servers Virtual Windows hosts = z.host.get(groupids=groupid , output=['hostid','name']) #Список имен хостов host_names = [host['name'] for host in hosts] #Список идентификаторов host_ids = [host['hostid'] for host in hosts] nameindex = 0 #Константа, кол-во секунд в сутках increment = 60*60*24 for host_id in host_ids: #параметр search позволяет найти все items, в имени которых есть заданная строка items = z.do_request('item.get',>) #массив найденных дисков disk_ids = [item['itemid'] for item in items['result']] #длина массива соответствует кол-ву дисков num_disks = len(disk_ids) avg_list=[] #цикл подсчета среднего для каждого диска for disk in disk_ids: #для определения временных рамок используется функция из time #первый день, за который нужна статистика - 27 марта 2017 года, с 9:00 до 18:00 time_from = time.mktime((2017,3,27,9,0,0,0,0,0)) time_till = time.mktime((2017,3,27,18,0,0,0,0,0)) history_sum=0 history_len=0 #цикл для 5 дней с 27 по 31 марта for day in range(0,5): data = z.history.get(history = 0, itemids=disk, time_from=time_from, time_till=time_till) #массив содержит список значений из истории graph = [float(item['value']) for item in data] #если список не пустой, добавляем его в массив для вычисления среднего if(len(graph)!=0): history_sum+=sum(graph) history_len+=len(graph) #увеличиваем интервалы на сутки time_from += increment time_till += increment #если очередь не пустая, добавляем среднее значение по диску в список if(history_len!=0): avg_list.append(history_sum/history_len) else: avg_list.append(0) #если список не пустой, берем минимальное значение if(len(avg_list)>0): sys.stdout.write(host_names[nameindex]) print ',',num_disks,',',min(avg_list) nameindex+=1
В результате получаем разделенные запятой имя хоста, кол-во винтов и min idle time:
DC1_--172.16.1.4--, 1 , 99.0758766296 DC2_--172.16.1.5--, 1 , 97.0989181683 LocalDB_--172.16.1.12--, 2 , 98.9930628704
Начало работы с Zabbix API
Как правило у вас есть только один путь для манипуляций, настройки и создания объектов в Zabbix — через PHP веб интерфейс. Это очень удобно, однако только до того момента пока вы не решите создать что то особенное: создать пакетный скрипт добавления/обновления, или пользовательский инструмент мониторинга, или что то еще, что не Zabbix GUI интерфейс не предоставляет по умолчанию.
Вот тогда Zabbix API и приходит на помощь. Он позволяет создавать, обновлять и получать объекты Zabbix(например, узлы сети, элементы данных, графики и др.) через протокол JSON RPC и делать все, что вам нравится (если у вас есть аккаунт, уполномоченный на эти действия, конечно).
Zabbix API был введен в версии 1.8 и активно разрабатывается до сих пор. В некоторых местах, функциональность все еще ограничена, но он обещает стать гораздо шире после выпуска Zabbix 2.0.
Пример сессии
Для быстрого обзора, взгляните на пример сессии Zabbix API или читайте ниже для более подробного объяснения.
Использование JSON RPC
Если вы не знакомы с JSON RPC, не бойтесь, все сложности отмечены ниже. Весь рабочий процесс заключается в нескольких шагах:
- Подготовка объекта JSON, который описывает то что вы хотите сделать (создать узел сети, получить график, обновить элемент данных и т.д.);
- Отправка этого объекта используя метод POST на http://example.com/zabbix/api_jsonrpc.php, где http://example.com/zabbix/ это адрес вашего веб-интерфейса Zabbix;
- Получитьответ с желаемыми данными в формате JSON.
В большинстве случаев вы будете делать это из скриптов, с помощью инструментов скриптового язык, но, конечно, вы можете отправлять запросы «вручную», используя любой из желаемых инструментов JSON-RPC.
В самом деле, правильно! Все, что вам нужно знать сейчас, это способ аутентификации для этого, и то, какой формат JSON является ожидаемым для Zabbix.
Базовый формат запроса
Упрощенный запрос JSON в Zabbix API выглядит следующим образом:
"jsonrpc": "2.0", "method": "method.name", "params": "param_1_name": "param_1_value", "param_2_name": "param_2_value" >, "id": 1, "auth": "159121b60d19a9b4b55d49e30cf12b81" >
Давайте взглянем на каждую строку:
- «jsonrpc»: «2.0» — это стандартный параметр JSON PRC идентификации версии протокола. Он не будет меняться для всех ваших запросов;
- «method»: «method.name» — этот параметр определяет фактически выполняемую операцию. Общие примеры: «host.create», «item.update» и так далее;
- «params» — здесь вы передаете объект JSON с параметрами требуемыми для указанного метода. Если вы хотите создать элемент данных, например, параметры «name» и «key_» будут обязательными. Возможные параметры для каждого метода (и сами методы) описываются в документации Zabbix API;
- «id»: 1 — это поле может быть использовано, чтобы связать каждый запрос JSON с ответом. Ответ будет иметь такой же «id» как и указанный в запросе. Не обязательно должен быть уникальным или последовательным;
- «auth»: «159121b60d19a9b4b55d49e30cf12b81» — Это ключ аутентификации для идентификации пользователя для доступа к API. Смотрите раздел Аутентификация для получения более подробной информации.
Аутентификация
И так, теперь мы знаем как использовать API. Давайте взглянем на метод host.create и создадим новый узел сети. Давайте отправим запрос:
"jsonrpc": "2.0", "method": "host.create", "params": "host": "My first host name", "ip": "192.168.3.1", "port": 10050, "useip": 1, "groups": [ "groupid": 50 > ] >, "id": 1 >
"jsonrpc": "2.0", "error": "code": -32602, "message": "Invalid params.", "data": "Not authorized" >, "id": 1 >
Что произошло? Конечно, не случайный человек может отправить запрос Zabbix на получение информации или для изменения чего-нибудь. Вот зачем вам нужно проходить аутентификацию для того, чтобы что-нибудь сделать.
Хорошее время отметить несколько моментов:
В случае любой ошибки, в результате вы получите параметр «error»:
- Параметр «code» будет всегда равен -32602 (это код ошибки JSON для ошибочных параметров);
- «message» отражает ту же информацию что и вернул нам «code» и не будет сильно отличаться;
- «data» будет описывать, что действительно пошло не так.
В случае успеха, вы получите параметрo «result» вместо «error» (как вы увидите далее).
И так, как получить аутентификацию? Вам потребуется отправить запрос, вызвав метод «user.login» и указав параметрами «user» и «password».
"jsonrpc": "2.0", "method": "user.login", "params": "user": "Admin", "password": "zabbix" >, "id": 1 >
«Admin/zabbix» является учетной записью в Zabbix по умолчанию, но вы уже вероятно изменили пароль Админа. Не так ли?
Таким образом, мы получим ответ:
"jsonrpc": "2.0", "error": "code": -32602, "message": "Invalid params.", "data": "No API access" >, "id": 1 >
Опять, отказ. Что случилось на этот раз? Дело в том, что в Zabbix 1.8 пользователи, которые не находятся в группе с «Доступом к API» не имеют доступа к Zabbix API по умолчанию. Для того чтобы использовать API для нужного пользователя, вам нужно установить «Доступ к API» в «Активирован» для группы пользователей этого пользователя или поместить пользователя в группу с предустановленным «API доступом».

Теперь, когда ваш пользователь является членом группы пользователей с включенным «Доступ к API», попробуем отправить такой же запрос снова:
"jsonrpc": "2.0", "method": "user.login", "params": "user": "Admin", "password": "zabbix" >, "id":1 >
"jsonrpc": "2.0", "result": "7cd4e1f5ebb27236e820db4faebc1769", "id": 1 >
Ура! Аутентификация успешна! Что теперь? Теперь мы можем использовать хэш возвращенный в параметре «result», как доказательство наших прав, путем включения в каждый создаваемый запрос API, параметром «auth».
Примеры использования и общие параметры
Теперь, когда вы авторизовались можно пойти дальше и сделать что-нибудь. Прежде всего, давайте попробуем получить какую-нибудь информацию.
Получение списка групп узлов сети
Вот простой запрос на получение всех доступных групп узлов сети с сортировкой по имени
"jsonrpc": "2.0", "method": "hostgroup.get", "params": "output": "extend", "sortfield": "name" >, "id": 1, "auth": "7cd4e1f5ebb27236e820db4faebc1769" >
Обратите внимание, что «method» содержит «hostgroup.get», фактическую процедуру которую мы выполняем, и «params» содержащий дополнительные опции.
«sortfield», как вы можете догадаться, позволяет сортировать результат, который вы получаете по выбранному полю.
«output»:»extend» означает, что вы хотите получить всю доступную информацию о каждой группе. Это, в некотором роде похоже на «SELECT *» в SQL. Возможными вариантами «output» могут быть:
- «extend» — получить всю информацию;
- «shorten» — получить только id объектов;
- «refer» — получить id объекта и так же id связанных объектов;
- список полей, таких как [«groupid», «name»] — получить поля только из списка.
Список полей доступен только для get методов Alert, DCheck, Host, DService, Screenitem, Template и Trigger.
И не забывайте о хэше «auth», который вы получили используя «user.login».
Ответ на данный запрос может выглядеть следующим образом::
"jsonrpc": "2.0", "result": [ "groupid": "5", "name": "Discovered hosts", "internal": "1" >, "groupid": "2", "name": "Linux servers", "internal": "0" >, "groupid": "1", "name": "Templates", "internal": "0" >, "groupid": "3", "name": "Windows servers", "internal": "0" >, "groupid": "4", "name": "Zabbix servers", "internal": "0" > ], "id": 1 >
Это стандартные группы, созданные при первичной настройке Zabbix. Обратите внимание на поле «groupid», поля «XXXXid» уникальные идентификаторы системы, которые будут использоваться для адресации на объект в других запросах. Смотрите следующий раздел для объяснений.
Создание узла сети
Мы получили группы узлов сети, теперь попробуем что-нибудь создать. Попробуем создать узел сети, который будет находиться в группе узлов сети «Linux servers» и «Zabbix servers». Запрос будет выглядеть следующим образом:
"jsonrpc": "2.0", "method": "host.create", "params": "host": "My new fancy host that I have created using API", "ip": "192.168.3.1", "port": 10050, "useip": 1, "groups": [ "groupid": 2 >, "groupid": 4 > ] >, "id": 1, "auth": "7cd4e1f5ebb27236e820db4faebc1769" >
Обратите внимание, мы используем поля «groupid» полученные ранее, для связки с группами в которые мы хотим, чтобы входил наш узел сети. Мы, говорим, что хотим чтобы узел сети был в группах с id 2 (Linux servers) и 4 (Zabbix servers). Таким способом, вы будете работать со всеми сопутствующими объектами.
Если все пойдет верно, вы получите ответ:
"jsonrpc": "2.0", "result": "hostids": [ "10051" ] >, "id": 1 >
Список «hostids» содержит элементы id, которые мы только что создали. В нашем случае, мы создавали только один узел сети и получили ID — 10051. Вы можете его использовать в будущих запросах.
Обновление элемента данных
Конечно, если вы можете создавать что-либо, вы должны иметь возможность обновлять или удалять. И для вас, чтобы попробовать и обновить элемент данных, я создал элемент данных с описанием «agent.ping» в созданном ранее «Моем новом придуманном узле сети, который я создал с помощью API», так что можно поиграть с ним. Во-первых, давайте посмотрим на это:
"jsonrpc": "2.0", "method": "item.get", "params": "output": "extend", "filter": "description": "agent.ping" >, "hostids": [ "10051" ] >, "id": 1, "auth": "7cd4e1f5ebb27236e820db4faebc1769" >
Обратите внимание, мы использовали параметр «filter», для указания описания элемента данных и «hostids», чтобы сказать что мы заинтересованы в элементе данных у узла сети, который мы создали (это было и его ID был 10051, помните?)
"jsonrpc": "2.0", "result": [ "hosts": [ "hostid": "10051" > ], "itemid": "22162", "type": "0", "snmp_community": "", "snmp_oid": "", "snmp_port": "161", "hostid": "10051", "description": "agent.ping", "key_": "agent.ping", "delay": "30", "history": "90", "trends": "365", "lastvalue": null, "lastclock": null, "prevvalue": null, "status": "0", "value_type": "3", "trapper_hosts": "", "units": "", "multiplier": "0", "delta": "0", "prevorgvalue": null, "snmpv3_securityname": "", "snmpv3_securitylevel": "0", "snmpv3_authpassphrase": "", "snmpv3_privpassphrase": "", "formula": "0", "error": "", "lastlogsize": "0", "logtimefmt": "", "templateid": "0", "valuemapid": "0", "delay_flex": "", "params": "", "ipmi_sensor": "", "data_type": "0", "authtype": "0", "username": "", "password": "", "publickey": "", "privatekey": "", "mtime": "0" > ], "id": 1 >
Ничего себе, много ж информации здесь. Теперь попробуем и обновить элемент данных, изменим «snmp_port» на 162 и «item type» на SNMPV1. Метод item.update будет верным инструментом для этого.
"jsonrpc":"2.0", "method":"item.update", "params": "itemid":"22162", "snmp_port":"162", "type":1 >, "id":1, "auth":"7cd4e1f5ebb27236e820db4faebc1769" >
Обратите внимание, мы указали три параметра: «itemid», таким образом Zabbix будет знать какой элемент данных обновлять (не забывайте это!) и два параметра, которые мы хотим изменить. Кстати, откуда я знаю, что «type»:1 означает SNMPV1? Это все есть в общем разделе элемента данных.
"jsonrpc": "2.0", "result": "itemids": [ "22162" ] >, "id": 1 >
Обычно, Zabbix возвращает ID претерпевшего изменение элемента.
Диагностика работы Zabbix
Диагностика работы сервера и агента Zabbix. Самые простые способы найти причины неработоспособности.
Проблемы, проблемы, проблемы…
В предыдущей статье мы рассматривали процесс установки Zabbix. Сегодня мы коснемся основных способов диагностики работы сервера и агента Zabbix, а также решение некоторых возникающих проблем.
Ничего сверхестественного. Только базовая информация, которая дает представление о том куда нужно двигаться при наличии проблем в работе мониторинга на базе Zabbix.
Как себя чувствует сервер
Бывает, что на сервере возникают какие-либо проблемы, связанные как с самой службой Zabbix-сервера, так и с его взаимодействием с агентами или связанными компонентами. Первый источник информации, который может помочь в поиске причин проблем — это логи Zabbix-сервера. Еще одним важным источником данных может быть сама система мониторинга, которая мониторит сама себя.
Логи наше все
Логи по традиции мира *.nix хранятся в текстовых файлах и располагаются в каталоге ‘/var/log/zabbix’.
[ypermitin@zabbix zabbix]$ ls zabbix_agentd.log zabbix_agentd.log-20201011 zabbix_server.log-20201004.gz zabbix_agentd.log-20201004.gz zabbix_server.log zabbix_server.log-20201011
В этом же каталоге можно увидеть файлы логов Zabbix-агента. Чаще всего на сервере Zabbix для отслеживания работы сервера установлен агент. Да, Zabbix-сервер следит сам за собой.
Прочитать содержимое можно стандартными для Linux способами:
- Смотрим файл логов с возможностью прокрутки.
less /var/log/zabbix/zabbix_server.log
- Просмотр файла логов в реальном времени.
tail -f /var/log/zabbix/zabbix_server.log
- Смотрим первые записи
head /var/log/zabbix/zabbix_server.log
- Смотрим последние события
tail -n 30 /var/log/zabbix/zabbix_server.log
- Получаем только записи с ошибками
grep -i error /var/log/zabbix/zabbix_server.log
В общем, это самые простые способы прочитать содержимое файла логов. Если Вы знаете что нужно искать, то grep Вам в помощью. В противном случае в бой вступает tail, но можно выполнять анализ и более сложными способами.
Вот, например, вывод последних 10 событий из файла логов.
[ypermitin@zabbix zabbix]$ tail -n 10 /var/log/zabbix/zabbix_server.log 1370:20201016:230008.844 housekeeper [deleted 4601 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.047217 sec, idle for 1 hour(s)] 1370:20201017:000346.901 executing housekeeper 1370:20201017:000346.958 housekeeper [deleted 4857 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.053027 sec, idle for 1 hour(s)] 1386:20201017:002028.428 Zabbix agent item "system.swap.size[,free]" on host "YY-COMP" failed: first network error, wait for 15 seconds 1394:20201017:002043.521 Zabbix agent item "system.uptime" on host "YY-COMP" failed: another network error, wait for 15 seconds 1394:20201017:002058.554 Zabbix agent item "agent.ping" on host "YY-COMP" failed: another network error, wait for 15 seconds 1394:20201017:002113.579 temporarily disabling Zabbix agent checks on host "YY-COMP": host unavailable 1394:20201017:003815.366 enabling Zabbix agent checks on host "YY-COMP": host became available 1370:20201017:010352.434 executing housekeeper 1370:20201017:010352.503 housekeeper [deleted 4599 hist/trends, 0 items/triggers, 0 events, 0 problems, 0 sessions, 0 alarms, 0 audit items in 0.063396 sec, idle for 1 hour(s)]
Здесь мы видим события процесса housekeeper, который отвечает за удаление устаревшей информации из базы данных мониторинга. Далее идут более интересные события об ошибке связи с хостом “YY-COMP”, а также события последующего восстановления соединения с агентом этого хоста.
1386:20201017:002028.428 Zabbix agent item "system.swap.size[,free]" on host "YY-COMP" failed: first network error, wait for 15 seconds 1394:20201017:002043.521 Zabbix agent item "system.uptime" on host "YY-COMP" failed: another network error, wait for 15 seconds 1394:20201017:002058.554 Zabbix agent item "agent.ping" on host "YY-COMP" failed: another network error, wait for 15 seconds 1394:20201017:002113.579 temporarily disabling Zabbix agent checks on host "YY-COMP": host unavailable 1394:20201017:003815.366 enabling Zabbix agent checks on host "YY-COMP": host became available
В любом случае, основным источником данных о том, что и как делает процесс Zabbix-сервера, есть ли у него проблемы и другую связанную с ним информацию можно найти в его логах. Метод “тыка” тоже работает, но эффективнее просто посмотреть в файл лога событий.
Мониторинг системы мониторинга
Благодаря тому, что Zabbix позволяет собирает метрики о состоянии самого себя, мы можем отслеживать некоторые проблемы с его помощью. После установки сервера, по умолчанию в списке хостов содержится сам сервер с шаблоном “Template App Zabbix Server”.

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

Например, если Вы увидите уведомления о проблеме “Zabbix poller processes more than 75% busy” от одного из триггеров этого шаблона, то идем в официальную документацию и читаем что это. Можно увидеть, что проблему можно решить изменив параметр “StartPollers” в файле конфигурации Zabbix-сервера.
Вообще, оптимизация настроек этой системы мониторинга отдельная тема, но должно быть понятно, что следить за сервером Zabbix является неотъемлемой частью мониторинга. Иначе как Вы узнаете, что пора актуализировать настройки сервера или проапгрейдить железо?
Все в очередь
Кроме логов и мониторинга Zabbix-сервера есть еще один важный показатель, демонстрирующий общую картину производительности процессов системы мониторинга. Причем помогает диагностировать проблемы не только в работе сервера, но и агентов Zabbix.
Речь идет про очередь обработки элементов данных, которая отлично описана в официальной документации. На следующем скриншоте показана идеальная картина, когда никаких очередей нет и все элементы обрабатываются за минимальное время.

Самыми распространёнными причинами увеличения очереди являются:
- Агент сбора данных стал недоступен и не присылает данные / не может ответить на запрос.
- У сервера не хватает ресурсов для выполнения обработки присланных элементов данных или опроса хостов (зависит от типа агента — активный или пассивный).
В случаях, когда Вы будете наблюдать большие значения очередей с периодом обработки более 1 минуты, то стоит насторожиться и начать диагностику сервера и агентов.
Вы всегда можете посмотреть элементы очереди детально, чтобы понять, где именно появилась проблема. Плюс ко всему, очередь обработки сообщений можно добавить в метрики сбора данных мониторинга и привязать на них триггеры. Таким образом, очереди позволяют отслеживать общее состояние как сервера Zabbix, так и состояние всего мониторинга с учетом агентов.
База данных требует внимания
Zabbix хранит данные метрик в одной из поддерживаемых СУБД: MySQL или PostgreSQL. Для оптимальной производительности обязательно нужно выполнить их настройку. Я предпочитаю использовать PostgreSQL, но тут все полностью зависит от задач.
Касательно PostgreSQL нужно обязательно адаптировать ее настройки под ресурсы сервера, т.к. по умолчанию там установлены максимальные ограничения на используемую память и другие ресурсы. Рекомендую зайти на сайт PGTune, который поможет подобрать параметры СУБД под Ваш сервер. Просто берете и переносите их в свой файл конфигурации “postgresql.conf”.
Конечно, со временем может понадобиться адаптировать эти параметры под свою нагрузку и задачи. Подробнее о настройках Вы можете прочитать здесь.

То же самое относится и к MySQL. Вы можете обратиться к официальной документации, чтобы узнать больше.
Главное помнить, что настройки сервера баз данных являются ключевым фактором для достижения высокой производительности всей системы мониторинга.
Агент еще жив
Основные способы диагностики сервера Zabbix мы рассмотрели. А что на счет агентов на хостах, которые входят в мониторинг?
Выше уже было упомянуто, что у агента есть свои логи. Именно они и являются основным источником данных для диагностики его работы. Если мы говорим о *.nix системах, то обычно файл лога находится в “/var/log/zabbix/zabbix_agent.log”. Вот, например, его содержимое при старте процесса агента.
[ypermitin@zabbix zabbix]$ tail -n 30 /var/log/zabbix/zabbix_agentd.log 88139:20201017:164146.511 Starting Zabbix Agent [Zabbix server]. Zabbix 4.0.25 (revision 32662425e6). 88139:20201017:164146.511 **** Enabled features **** 88139:20201017:164146.511 IPv6 support: YES 88139:20201017:164146.511 TLS support: YES 88139:20201017:164146.511 ************************** 88139:20201017:164146.511 using configuration file: /etc/zabbix/zabbix_agentd.conf 88139:20201017:164146.511 agent #0 started [main process] 88140:20201017:164146.511 agent #1 started [collector] 88141:20201017:164146.512 agent #2 started [listener #1] 88144:20201017:164146.513 agent #5 started [active checks #1] 88143:20201017:164146.515 agent #4 started [listener #3] 88142:20201017:164146.516 agent #3 started [listener #2]
Это идеальный вариант, когда агент был запущен и никаких проблем с его работой не наблюдается. Но там могут быть и ошибки или информация о проблемах связи. Например, вот это событие говорит о том, что что-то блокирует доступ агента к серверу Zabbix.
3900:20201017:002349.716 active check configuration update from [192.168.11.149:10051] started to fail (cannot connect to [[192.168.11.149]:10051]: (null))
Может не открыт порт на сервере? Или сервер недоступен? Или ошибка в конфигурационном файле агента?
Аналогичный файл лога есть для агентов всех поддерживаемых операционных систем, в том числе и Windows. Его расположение можно уточнить в самом конфигурационном файле агента в параметре “LogFile”. Для Windows это может быть каталог самого агента, например:
### Option: LogFile # Log file name for LogType 'file' parameter. # # Mandatory: no # Default: # LogFile= LogFile=C:\Program Files\ZabbixAgent\zabbix_agentd.log
В любом случае, если у Вас проблемы в работе агента, то первым делом идем в его логи и смотрим что вообще происходит.
Решение некоторых проблем
Рассмотрим решение некоторых проблем в работе сервера и агента. Это ни в коем случае не полноценный мануал, а скорее пара заметок. Небольшая порция “траблшутинга”. Более развернутую информацию Вы можете найти в официальной Wiki.
Немного опечатались
Иногда бывает так, что порты и все доступы настроены, агент установлен, ошибок в логах нет, но метрики не приходят или приходят не полностью. В самом Zabbix хост “горит зеленым” и непонятно, что вообще происходит.

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

Как только мы исправим в файле конфигурации параметр “Hostname” на нужный (в нашем случае это “SRV-SQL-01-VM”), то картина сразу же изменится. В списке появятся все диски сервера.

Данные могут появиться не сразу, т.к. правила обнаружения выполняются не так часто, как получение обычных метрик, но Вы можете запустить их вручную в настройках хоста.
Копипаст — зло! Будьте осторожны!
Ребут и агента нет
Бывают случаи, когда агент был успешно установлен и настроен на хосте, мониторинг работает как надо. НО! При очередном запланированном перезапуске сервера (хоста) Zabbix-агент не смог запуститься.
Причин тому может быть несколько:
- Агент запускается от доменной учетной записи, но на момент старта сервера связи с доменом не оказалось.
- В момент запуска агент пытался запуститься, когда еще не “поднялся” доступ к сети.
При этом в файле лога агента может не быть какой-либо полезной информации, но она есть в системных журналах ОС. Чаще всего это поведение встречал в ОС Windows.
Решение достаточно простое: нужно установить для службы Windows режим запуска “Автоматически (отложенный запуск)”. В большинстве случаев проблема будет решена.

Быстро и просто!
Особые проблемы со счетчиками
Особой проблемой, которая встречается не очень часто, бывают проблемы со счетчиками производительности Windows. После настройки мониторинга на сервере можно увидеть для хоста элементы данных со статусом “Не поддерживается”. При этом все они получаются через показатели производительности Windows. Обратившись к логам агента Zabbix можно увидеть следующее.
zabbix agent log: check_counter_path(): cannot make counterpath zabbix agent log: A required argument is missing or not correct. active check "perf_counter[. ]" is not supported
При этом для хоста у элементов данных будет такая ошибка.
ZBX_NOTSUPPORTED: Cannot obtain system information.
Проблема в некорректном списке доступных счетчиков производительности Windows на хосте с агентом, то есть на машине, которую мы собираемся мониторить. Можно проверить наличие нужного счетчика через “Монитор производительности” (perfmon.exe) или через ветку реестра:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009" # Ключ "Counter" содержит список всех доступных счетчиков производительности.
Если нужного счетчика нет, то можно попытаться перестроить все счетчики ОС командой:
lodctr /r # Утилита находится в "C:\WINDOWS\System32"
В большинстве случаев это помогает. Если остаются проблемы со счетчиками производительности сторонних приложений, то нужно изучить документацию по этим счетчикам. Например, для Microsoft SQL Server можно отдельно восстановить счетчики из поставляемых настроек. Подробнее можно узнать здесь.
Счетчики производительности для мониторинга Windows — отличный инструмент. И его, конечно же, нужно использовать.
Таймаут выполнения скриптов
Еще небольшой ошибкой может быть ситуация, когда на сервер не поступают данные по каким-либо элементам данных, а в логах агента можно увидеть ошибки вида:
ZBX_NOTSUPPORTED: Timeout while executing a shell script
Так происходит, поскольку выполняемый скрипт не укладывается в заданное время выполнения. Время задается также в конфигурации агента Zabbix и по умолчанию составляет 3 секунды.
### Option: Timeout # Spend no more than Timeout seconds on processing # # Mandatory: no # Range: 1-30 # Default: # Timeout=3
Имеется три основных варианта решения:
- Увеличить таймаут до подходящего значения. Например, до 30 секунд:
### Option: Timeout # Spend no more than Timeout seconds on processing # # Mandatory: no # Range: 1-30 # Default: # Timeout=3 Timeout=30
- Второй вариант — разобраться в причинах долгого выполнения и попытаться их исправить. Конечно, если это возможно.
- Отказаться от сбора этих метрик 🙂
В любом случае, посмотрите почему скрипт может выполняться дольше, чем запланировано. Только после этого меняйте настройки.
Продолжение следует
Это была еще одна небольшая публикация по теме мониторинга с помощью Zabbix. В следующих статьях мы поговорим об обновлении Zabbix с версии 4.0 на 5.0, создадим свой шаблон для сбора метрик и рассмотрим некоторые особенности этого процесса, настроим уведомления в Telegram-канал, а также получении данных с Prometheus и визуализации данных в Grafana. И, конечно же, оптимизация производительности сервера мониторинга Zabbix!
Будьте на связи 🙂
Будьте в курсе
Создание материалов будет продолжаться. Хотите быть в курсе последних обновлений? Подписывайтесь на канал.
По любым вопросам пишите на электронную почту. Адрес в самом низу страницы.