Как узнать itemid zabbix

Поулчить максимальное значение Item в Zabbix

Добрый день Скажите, пожалуйста, гуру Zabbix. Как можно получить максимальное значение item’а за сутки? Это надо для того что бы взять это значение и записать в БД и будет отдельная аналитика по максимальным значениям в разрезе годов.

P.S. Думаю что можно использовать API Zabbix, авторизоваться получилось, а вытянуть максимальное значение конкретного итема не знаю как 🙁

darksmoke
27.06.19 13:55:48 MSK

Лучше всего через тренды (максимум/минимум/avg сохраняется раз в час):

Если вдруг тренды по каким-то причинам неприменимы:

2. Прямой запрос в базу к таблице history — наверное, выйдет оптимальнее

3. Делаете calculated item с flexible interval, который раз в сутки считает значение за прошлые сутки, и сохраняет в history, далее см. пункт 1 или 2 — вытаскиваете нужное вам значение за нужные сутки

AlexAT ★
( 02.07.19 11:47:58 MSK )
Последнее исправление: AlexAT 02.07.19 11:48:12 MSK (всего исправлений: 1)

4 августа 2019 г.
Ответ на: комментарий от AlexAT 02.07.19 11:47:58 MSK

Подскажите, где косячу. Возвращает пустоту 🙁 Смотрю в забиксе через веб морду, данные есть.

< "jsonrpc": "2.0", "method": "trend.get", "params": < "output": [ "itemid", "clock", "num", "value_min", "value_avg", "value_max" ], "itemids": ["728673"], "limit": "1", "time_from": ["1564790401"], "time_till": ["1564876799"] >, "id": 1, "auth": "48faa7e4d1abd72cdeeb2e17eb1dd072" > 

Использование 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 

19. API

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

• Создания новых приложений для работы с Zabbix;
• Интеграции Zabbix со сторонним программным обеспечением;
• Автоматизации рутинных задач.

Zabbix API является API на основе веб и поставляется как часть веб-интерфейса. Он использует протокол JSON-RPC 2.0, что имеет два значения:

• API состоит из набора отдельных методов;
• Запросы и ответы между клиентами и API закодированы с использованием формата JSON.

Более подробную информацию о протоколе и JSON можно найти на странице спецификации JSON-RPC 2.0 и домашней страницы JSON.

Структура

API состоит из ряда методов, которые условно сгруппированы в отдельные API. Каждый метод выполняет одну отдельную задачу. Например, метод host.create относится к API узла сети и используется для создания новых узлов сети. Исторически сложилось так, что API иногда назывался как «классы».

Большинство API содержит по крайней мере четыре метода: get , create , update и delete для получения, создания, обновления и удаления данных соответственно, однако, некоторые API могут предоставлять совершенно другой набор методов.

Выполнение запросов

Как только вы установите веб-интерфейс, вы можете использовать удаленные HTTP запросы для вызова API. Чтобы это сделать, вам необходимо отправлять HTTP POST запросы к файлу api_jsonrpc.php , который расположен в папке с веб-интерфейсом. Например, если ваш Zabbix веб-интерфейс установлен в http://company.com/zabbix, HTTP запрос для вызова метода apiinfo.version может выглядеть примерно так:

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1 Content-Type: application/json-rpc >

Запрос должен иметь заголовок Content-Type , который задан одним из следующих значений: application/json-rpc , application/json или application/jsonrequest .

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

Пример рабочего процесса

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

Аутентификация

Прежде чем вы сможете запросить любые данные с Zabbix вам необходимо выполнить вход и получить ключ аутентификации. Это можно сделать, используя метод user.login. Давайте предположим, что вы хотите выполнить вход с использованием стандартного пользователя Zabbix Администратора. Тогда ваш JSON запрос может выглядеть следующим образом:

   "jsonrpc": "2.0", "method": "user.login", "params":  "user": "Admin", "password": "zabbix" >, "id": 1, "auth": null >

Давайте познакомимся ближе с запросом объекта. Он имеет следующие свойства:

• jsonrpc — версия протокола JSON-RPC, которая используется API; Zabbix API реализует JSON-RPC версии 2.0;
• method — метод API, который вызывается;
• params — параметры, которые передаются API методом;
• id — произвольный идентификатор запроса;
• auth — ключ аутентификации пользователя; та как у нас его еще не имеется, укажем его равным null .

Если вы указали учетные данные правильно, полученный от API ответ будет содержать ключ аутентификации пользователя:

   "jsonrpc": "2.0", "result": "0424bd59b807674191e7d77572075f33", "id": 1 >

В свою очередь, объект ответа содержит следующие свойства:

• jsonrpc — снова, версия протокола JSON-RPC;
• result — данные полученные от метода;
• id — идентификатор соответствующего запроса.

Получение узлов сети

Теперь у нас есть валидный ключ аутентификации пользователя, которой можно использовать для доступа к данным в Zabbix. Например, давайте воспользуемся методом host.get, чтобы получить ID, имена узлов сети и интерфейсы всех настроенных узлов сети:

   "jsonrpc": "2.0", "method": "host.get", "params":  "output": [ "hostid", "host" ], "selectInterfaces": [ "interfaceid", "ip" ] >, "id": 2, "auth": "0424bd59b807674191e7d77572075f33" >

Обратите внимание, что свойство auth теперь задано равным ключу аутентификации, который мы получили вызвав user.login .

Объект ответа будет содержать затребованные данные о этих узлах сети:

   "jsonrpc": "2.0", "result": [   "hostid": "10084", "host": "Zabbix server", "interfaces": [   "interfaceid": "1", "ip": "127.0.0.1" > ] > ], "id": 2 >

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

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

Давайте создадим новый элемент данных у «Zabbix server», используя данные, которые мы получили из предыдущего запроса host.get . Это можно сделать воспользовавшись методом item.create:

   "jsonrpc": "2.0", "method": "item.create", "params":  "name": "Free disk space on $1", "key_": "vfs.fs.size[/home/joe/,free]", "hostid": "10084", "type": 0, "value_type": 3, "interfaceid": "1", "delay": 30 >, "auth": "0424bd59b807674191e7d77572075f33", "id": 3 >

Успешный ответ будет содержать ID только что созданного элемента данных, который может быть ссылкой на этот элемент данных при следующих запросах:

   "jsonrpc": "2.0", "result":  "itemids": [ "24759" ] >, "id": 3 >

Метод item.create , также как и другие методы создания, может также принимать массивы объектов и создавать несколько элементов данных за один запрос API.

Создание нескольких триггеров

Таким образом если методы создания принимают массивы, мы может добавить несколько триггеров вот так:

   "jsonrpc": "2.0", "method": "trigger.create", "params": [   "description": "Processor load is too high on ", "expression": ">5", >,   "description": "Too many processes on ", "expression": ">300", > ], "auth": "0424bd59b807674191e7d77572075f33", "id": 4 >

Успешный ответ будет содержать ID только что созданных триггеров:

   "jsonrpc": "2.0", "result":  "triggerids": [ "17369", "17370" ] >, "id": 4 >

Обновление элемента данных

Активируем элемент данных, то есть, укажем ему состояние «0»:

   "jsonrpc": "2.0", "method": "item.update", "params":  "itemid": "10092", "status": 0 >, "auth": "0424bd59b807674191e7d77572075f33", "id": 5 >

Успешный ответ будет содержать ID обновленного элемента данных:

   "jsonrpc": "2.0", "result":  "itemids": [ "10092" ] >, "id": 5 >

Метод item.update , а так же и другие методы обновления могут также принимать массивы объектов и обновлять несколько элементов данных за один API запрос.

Обновление нескольких триггеров

Активируем несколько триггеров, то есть, укажем им состояние 0:

   "jsonrpc": "2.0", "method": "trigger.update", "params": [   "triggerid": "13938", "status": 0 >,   "triggerid": "13939", "status": 0 > ], "auth": "0424bd59b807674191e7d77572075f33", "id": 6 >

Успешный ответ будет содержать ID обновленных триггеров:

   "jsonrpc": "2.0", "result":  "triggerids": [ "13938", "13939" ] >, "id": 6 >

Это предпочтительный метод обновления. Некоторые API методы, такие как host.massupdate , позволяют писать более простой код, однако не рекомендуется использовать эти методы, так как они будут удалены из будущих выпусков.

Обработка ошибок

До этого момента всё что мы пробовали работало прекрасно. Но что случится, если мы попробуем выполнить некорректный запрос к API? Давайте попробуем создать еще один узел сети при помощи вызова host.create, но не станем указывать обязательный параметр groups .

   "jsonrpc": "2.0", "method": "host.create", "params":  "host": "Linux server", "interfaces": [   "type": 1, "main": 1, "useip": 1, "ip": "192.168.3.1", "dns": "", "port": "10050" > ] >, "id": 7, "auth": "0424bd59b807674191e7d77572075f33" >

Тогда ответ будет содержать сообщение об ошибке:

   "jsonrpc": "2.0", "error":  "code": -32602, "message": "Invalid params.", "data": "No groups for host \"Linux server\"." >, "id": 7 >

Если произошла ошибка, то вместо свойства result , объект ответа будет содержать свойство error со следующими данными:

• code — код ошибки;
• message — короткое описание ошибки;
• data — более детально сообщение об ошибке.

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

Версии API

Чтобы упростить версионность API, начиная с Zabbix 2.0.4, версия API совпадает с версией самим Zabbix. Вы можете использовать метод apiinfo.version, чтобы узнать версию API, с которой вы работаете. Знание версии может пригодиться для корректировки вашего приложения, чтобы использовать возможности конкретной версии API.

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

Вы можете следить за всеми изменениями, внесенными в API на странице журнала изменений API.

Дополнительная литература

Теперь вы знаете достаточно для начала работы с Zabbix API, но не останавливайтесь на данном этапе. Для дальнейшего чтения мы предлагаем вам взглянуть на список доступных API.

Начало работы с Zabbix API

Как правило у вас есть только один путь для манипуляций, настройки и создания объектов в Zabbix — через PHP веб интерфейс. Это очень удобно, однако только до того момента пока вы не решите создать что то особенное: создать пакетный скрипт добавления/обновления, или пользовательский инструмент мониторинга, или что то еще, что не Zabbix GUI интерфейс не предоставляет по умолчанию.

Вот тогда Zabbix API и приходит на помощь. Он позволяет создавать, обновлять и получать объекты Zabbix(например, узлы сети, элементы данных, графики и др.) через протокол JSON RPC и делать все, что вам нравится (если у вас есть аккаунт, уполномоченный на эти действия, конечно).

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

Пример сессии

Для быстрого обзора, взгляните на пример сессии Zabbix API или читайте ниже для более подробного объяснения.

Использование JSON RPC

Если вы не знакомы с JSON RPC, не бойтесь, все сложности отмечены ниже. Весь рабочий процесс заключается в нескольких шагах:

1. Подготовка объекта JSON, который описывает то что вы хотите сделать (создать узел сети, получить график, обновить элемент данных и т.д.);
2. Отправка этого объекта используя метод POST на http://example.com/zabbix/api_jsonrpc.php, где http://example.com/zabbix/ это адрес вашего веб-интерфейса Zabbix;
3. Получитьответ с желаемыми данными в формате 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 претерпевшего изменение элемента.