Zabbix Documentation 4.2

2.23.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.43.23.4

User Tools

Site Tools


manual:api

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:api [2014/09/30 12:54]
127.0.0.1 external edit
manual:api [2019/01/28 14:51] (current)
sasha <code js> => <code java>
Line 1: Line 1:
-===== 17. API =====+====== 19. API ======
  
 ==== Overview ==== ==== Overview ====
Line 18: Line 18:
 The API consists of a number of methods that are nominally grouped into separate APIs. Each of the methods performs one specific task. For example, the ''​host.create''​ method belongs to the //host// API and is used to create new hosts. Historically,​ APIs are sometimes referred to as "​classes"​. The API consists of a number of methods that are nominally grouped into separate APIs. Each of the methods performs one specific task. For example, the ''​host.create''​ method belongs to the //host// API and is used to create new hosts. Historically,​ APIs are sometimes referred to as "​classes"​.
  
-<note tip>Most APIs contain at least four methods: ''​get'',​ ''​create'',​ ''​update''​ and ''​delete''​ for retrieving, creating, updating and deleting data respectfully, but some of the APIs may provide a totally different set of methods.</​note>​+<note tip>Most APIs contain at least four methods: ''​get'',​ ''​create'',​ ''​update''​ and ''​delete''​ for retrieving, creating, updating and deleting data respectively, but some of the APIs may provide a totally different set of methods.</​note>​
  
 ==== Performing requests ==== ==== Performing requests ====
Line 42: Line 42:
 Before you can access any data inside of Zabbix you'll need to log in and obtain an authentication token. This can be done using the ''​[[manual:​api:​reference:​user:​login|user.login]]''​ method. Let us suppose that you want to log in as a standard Zabbix Admin user. Then your JSON request will look like this: Before you can access any data inside of Zabbix you'll need to log in and obtain an authentication token. This can be done using the ''​[[manual:​api:​reference:​user:​login|user.login]]''​ method. Let us suppose that you want to log in as a standard Zabbix Admin user. Then your JSON request will look like this:
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 64: Line 64:
 If you provided the credentials correctly, the response returned by the API will contain the user authentication token: If you provided the credentials correctly, the response returned by the API will contain the user authentication token:
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 81: Line 81:
 We now have a valid user authentication token that can be used to access the data in Zabbix. For example, let's use the ''​[[manual:​api:​reference:​host:​get|host.get]]''​ method to retrieve the IDs, host names and interfaces of all configured [[manual:​api:​reference:​host:​object|hosts]]:​ We now have a valid user authentication token that can be used to access the data in Zabbix. For example, let's use the ''​[[manual:​api:​reference:​host:​get|host.get]]''​ method to retrieve the IDs, host names and interfaces of all configured [[manual:​api:​reference:​host:​object|hosts]]:​
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 103: Line 103:
  
 The response object will contain the requested data about the hosts: The response object will contain the requested data about the hosts:
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 128: Line 128:
 Let's create a new [[manual:​api:​reference:​item:​object|item]] on "​Zabbix server"​ using the data we've obtained from the previous ''​host.get''​ request. This can be done by using the ''​[[manual:​api:​reference:​item:​create|item.create]]''​ method: Let's create a new [[manual:​api:​reference:​item:​object|item]] on "​Zabbix server"​ using the data we've obtained from the previous ''​host.get''​ request. This can be done by using the ''​[[manual:​api:​reference:​item:​create|item.create]]''​ method:
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 148: Line 148:
 A successful response will contain the ID of the newly created item, which can be used to reference the item in the following requests: A successful response will contain the ID of the newly created item, which can be used to reference the item in the following requests:
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 161: Line 161:
  
 <note tip>The ''​item.create''​ method as well as other create methods can also accept arrays of objects and create multiple items with one API call.</​note>​ <note tip>The ''​item.create''​ method as well as other create methods can also accept arrays of objects and create multiple items with one API call.</​note>​
 +
 +=== Creating multiple triggers ===
 +
 +So if create methods accept arrays, we can add multiple [[manual:​api:​reference:​trigger:​object|triggers]] like so:
 +
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​method":​ "​trigger.create",​
 +    "​params":​ [
 +        {
 +            "​description":​ "​Processor load is too high on {HOST.NAME}",​
 +            "​expression":​ "​{Linux server:​system.cpu.load[percpu,​avg1].last()}>​5",​
 +        },
 +        {
 +            "​description":​ "Too many processes on {HOST.NAME}",​
 +            "​expression":​ "​{Linux server:​proc.num[].avg(5m)}>​300",​
 +        }
 +    ],
 +    "​auth":​ "​0424bd59b807674191e7d77572075f33",​
 +    "​id":​ 4
 +}
 +</​code>​
 +
 +A successful response will contain the IDs of the newly created triggers:
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​result":​ {
 +        "​triggerids":​ [
 +            "​17369",​
 +            "​17370"​
 +        ]
 +    },
 +    "​id":​ 4
 +}
 +</​code>​
 +
 +=== Updating an item ===
 +
 +Enable an item, that is, set its status to "​0":​
 +
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​method":​ "​item.update",​
 +    "​params":​ {
 +        "​itemid":​ "​10092",​
 +        "​status":​ 0
 +    },
 +    "​auth":​ "​0424bd59b807674191e7d77572075f33",​
 +    "​id":​ 5
 +}
 +</​code>​
 +
 +A successful response will contain the ID of the updated item:
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​result":​ {
 +        "​itemids":​ [
 +            "​10092"​
 +        ]
 +    },
 +    "​id":​ 5
 +}
 +</​code>​
 +
 +<note tip>The ''​item.update''​ method as well as other update methods can also accept arrays of objects and update multiple items with one API call.</​note>​
 +
 +=== Updating multiple triggers ===
 +
 +Enable multiple triggers, that is, set their status to 0:
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​method":​ "​trigger.update",​
 +    "​params":​ [
 +        {
 +            "​triggerid":​ "​13938",​
 +            "​status":​ 0
 +        },
 +        {
 +            "​triggerid":​ "​13939",​
 +            "​status":​ 0
 +        }
 +    ],
 +    "​auth":​ "​0424bd59b807674191e7d77572075f33",​
 +    "​id":​ 6
 +}
 +</​code>​
 +
 +A successful response will contain the IDs of the updated triggers:
 +<code java>
 +{
 +    "​jsonrpc":​ "​2.0",​
 +    "​result":​ {
 +        "​triggerids":​ [
 +            "​13938",​
 +            "​13939"​
 +        ]
 +    },
 +    "​id":​ 6
 +}
 +</​code>​
 +
 +<note tip>This is the preferred method of updating. Some API methods like ''​host.massupdate''​ allow to write more simple code, but it's not recommended to use those methods, since they will be removed in the future releases.</​note>​
 +
 === Error handling === === Error handling ===
  
 Up to that point everything we've tried has worked fine. But what happens if we try to make an incorrect call to the API? Let's try to create another host by calling ''​[[manual:​api:​reference:​host:​create|host.create]]''​ but omitting the mandatory ''​groups''​ parameter. ​ Up to that point everything we've tried has worked fine. But what happens if we try to make an incorrect call to the API? Let's try to create another host by calling ''​[[manual:​api:​reference:​host:​create|host.create]]''​ but omitting the mandatory ''​groups''​ parameter. ​
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 182: Line 290:
         ]         ]
     },     },
-    "​id": ​3,+    "​id": ​7,
     "​auth":​ "​0424bd59b807674191e7d77572075f33"​     "​auth":​ "​0424bd59b807674191e7d77572075f33"​
 } }
Line 189: Line 297:
 The response will then contain an error message: The response will then contain an error message:
  
-<​code ​js>+<​code ​java>
 { {
     "​jsonrpc":​ "​2.0",​     "​jsonrpc":​ "​2.0",​
Line 197: Line 305:
         "​data":​ "No groups for host \"​Linux server\"​."​         "​data":​ "No groups for host \"​Linux server\"​."​
     },     },
-    "​id": ​3+    "​id": ​7
 } }
 </​code>​ </​code>​
Line 210: Line 318:
 ==== API versions ==== ==== API versions ====
  
-To simplify API versioning, ​starting from Zabbix 2.0.4, the version of the API matches the version of Zabbix itself. You can use the ''​[[manual:​api:​reference:​apiinfo:​version|apiinfo.version]]''​ method to find out the version of the API you're working with. This can be useful for adjusting your application to use version-specific features.+To simplify API versioning, ​since Zabbix 2.0.4, the version of the API matches the version of Zabbix itself. You can use the ''​[[manual:​api:​reference:​apiinfo:​version|apiinfo.version]]''​ method to find out the version of the API you're working with. This can be useful for adjusting your application to use version-specific features.
  
 We guarantee feature backward compatibility inside of a major version. When making backward incompatible changes between major releases, we usually leave the old features as deprecated in the next release, and only remove them in the release after that. Occasionally,​ we may remove features between major releases without providing any backward compatibility. It is important that you never rely on any deprecated features and migrate to newer alternatives as soon as possible. We guarantee feature backward compatibility inside of a major version. When making backward incompatible changes between major releases, we usually leave the old features as deprecated in the next release, and only remove them in the release after that. Occasionally,​ we may remove features between major releases without providing any backward compatibility. It is important that you never rely on any deprecated features and migrate to newer alternatives as soon as possible.
  
-<note tip>You can follow all of the changes made to the API in the [[manual:api:changes_2.2_-_2.4|API changelog]].</​note>​+<note tip>You can follow all of the changes made to the API in the [[manual/api/changes_3.4_-_4.0|API changelog]].</​note>​
 ==== Further reading ==== ==== Further reading ====
  
 You now know enough to start working with the Zabbix API, but don't stop here. For further reading we suggest you have a look at the [[manual:​api:​reference|list of available APIs]]. You now know enough to start working with the Zabbix API, but don't stop here. For further reading we suggest you have a look at the [[manual:​api:​reference|list of available APIs]].
 +