API Discussion

[nelsonab]

Let's move the discussion of an API to it's own thread

Here are some of the earlier discussions:

I would like to be able to add/remove/change hosts, templates, and groups from it. I don't need to administer items or triggers or most other things from the API (nor do I see a lot of sense in that, since those can be messed with pretty perfectly in the web interface)

add/change/remove hosts
add/change/remove host profile data
add/change/remove host group assignment
add/change/remove host template assignment
Enable/Disable monitoring on HOST(x)
Enable/Disable monitoring on template members (all hosts in a template affected)
Enable/Disable monitoring on group members (all hosts in a group affected)

Being able to apply templates to large numbers of hosts is the single most critical item to me. All my hosts get items assigned to them based on function, each function has a template. This would make adding a template to 500+ hosts at a time so much easier. We can't link groups since we use groups too identify which property(ies) the server is working under.

A faster way of creating maps would be slick too (but it's a purely nice-to-have). Perhaps if I could feed an XML with grid coordinates and boundaries to the API it load it into the DB faster than I can click and select.

Pease add the following to the wishlist also
- User management
- UserGroup management (including add/remove permissions for nodes/hostgroups/hosts
- Action mgt (tricky i know)

I'd add the following:
add/change/remove items to host(without templates. It's usefull in some situations)
add/change/remove graphs
add/change/remove screens


Well I think wouldn't lie if I say that most of these functions can be found in the php frontend. =))

@alexei
I've been looking at the zabbix code with a colleague to see how much time it would take and how complex it would be.
Basically, all real functionality is already available via php functions in the webcode. The only real decision to be made is what kind of interface would the API have, cmdline / webbased (i.e. soap), XML or something else, etc, etc.
We've been looking at the API (xml) spec used by mediawiki, perhaps this is a good example.

Purposes for this API (imho) are purely administrative yes; you don't want this level of 'open' management available outside of your control.
For example to hook Zabbix to a CMDB for automatic host/hostgroup/users/usergroup management. Another example would be to write a script to rotate phonenumers of standby services. The applications are endless ofcourse, but purely backend related.

There is some work required to move to an API interface such as SOAP. For what it's worth, I'm a big proponent of using SOAP. It's a very flexible interface and scripting languages such as Perl and Ruby have SOAP libraries standard.

The current Zabbix frontend code has a very heavy reliance on global variables which won't work under SOAP. All functions need to run discreetly from each other. I started work on a simple SOAP interface and ran into some troubles converting the existing authentication code into an Object Oriented approach. I know that Alexei and the Zabbix team would like to see someone step up and sponsor such a development push.

It will likely be some time until we see an API. Without knowing anything about the long term roadmap I would guess the earliest we might see the beginings of a full API would be the 1.7 development branch. However that is pure speculation on my part.

In the meantime let's try and thresh out an API list and perhaps an implementation priority list as this will likely help streamline that aspect for the Zabbix team if and when they start work on that. After I get HA working (which is getting close) I might start putting some effort into this myself.

[Alexei]

It will likely be some time until we see an API. Without knowing anything about the long term roadmap I would guess the earliest we might see the beginings of a full API would be the 1.7 development branch. However that is pure speculation on my part.

In the meantime let's try and thresh out an API list and perhaps an implementation priority list as this will likely help streamline that aspect for the Zabbix team if and when they start work on that. After I get HA working (which is getting close) I might start putting some effort into this myself.

Thanks for making a new thread.

It is crucial that any new code should be used by both existing ZABBIX framework and the API. Otherwise I expect huge problems with maintenance of the code. The API is important to 1-2% of users, most probably even less.

Let's focus on defining functionality of the API first!

[teferi]

Let's focus on defining functionality of the API first!

Obviosly the API should allow to perform all the basic management functions with hosts, templates, items, etc. (This will allow administrators to easily create 1000 different graphs for 1000 different hosts etc.)

I cannot really think out anything other than configuration really. If you want me to create a list of wanted functions - I'm ready to provide such, but most of them are obvious.

[r3dn3ck]

teferi and I are on the same page. Being able to directly add 1000's of maps, graphs, templates, hosts, whatever is what I'd like. I think graphs and maps are the hardest part to currently deal with since they take the most time to create. XML uploading isn't always the easiest thing to do as it requires that the XML be created in the first place which is a whole separate script.

[ghislain]

The API is important to 1-2% of users, most probably even less.

+1 for the api, being able to add host/items automaticaly is a big + as we have so many systems nowadays with virtualisation that you cannot trust everybody to make manual change. Automating is the key to success in IT.

regards,
Ghislain.

[nelsonab]

The API is important to 1-2% of users, most probably even less.

I would disagree. I think it's a situation of build it and they will use it... The API, like HA is something I needed so I started to hack it. :-)

[Alexei]

I would disagree. I think it's a situation of build it and they will use it... The API, like HA is something I needed so I started to hack it. :-)

I think you are right. Also I believe that size of ZABBIX setup matters a lot when it come to use of the API.

[pgillan]

+1 for the api, being able to add host/items automaticaly is a big + as we have so many systems nowadays with virtualisation that you cannot trust everybody to make manual change. Automating is the key to success in IT.

It's not even an issue of trusting people to make the change. At some point, when you reach a certain size and complexity, you have to automate, as there comes a point where no one person could possibly know everything that needs to be updated when a new server is added or an existing configuration changes. We've created a central repository of that information for a reason, and all information needs to flow from it. We have to be able to automatically update everything downstream, or the system is not viable.

[onslo]

It's not even an issue of trusting people to make the change. At some point, when you reach a certain size and complexity, you have to automate, as there comes a point where no one person could possibly know everything that needs to be updated when a new server is added or an existing configuration changes. We've created a central repository of that information for a reason, and all information needs to flow from it. We have to be able to automatically update everything downstream, or the system is not viable.

I couldn't have put it better myself - absolutely bang on the money.

Rgs

Onslo

[hwinkel]

SOAP or REST

we are also moving to use Zabbix. API access comes in my mind. The Initital Requiremts for us are to get informations out of Zabbix to display or use them in outer systems. i.e. SLA violation etc. It would be graet to hat a SOAP or REST basted API where can get values of monitored object i.e. Host Interface stat. out of zybbix by calling a URL per resources.

[NOB]

XML Import/Export

Hi

from the original announcement for V 1.6:

Functionality:

XML backup/restore

Development:

0%

Testing

0%

I think part, if not all, requirements of this thread could be fulfilled with the implementation of the announced feature - in its intended use (from the command-line).
AFAIS this is not implemented in 1.6.
I would be happy, if I am wrong
Will this be implemented in one of the 1.6.x branches ?
As I mentioned in an earlier post, it is not as easy as it looks like,
e.g., triggers covering items from different hosts, trigger depencies, etc.

Another scenario of usage: Migration from a different monitoring tool with similar
structure, e.g. hostgroups, hosts, items, etc.

Regards

Norbert.

[nelsonab]

we are also moving to use Zabbix. API access comes in my mind. The Initital Requiremts for us are to get informations out of Zabbix to display or use them in outer systems. i.e. SLA violation etc. It would be graet to hat a SOAP or REST basted API where can get values of monitored object i.e. Host Interface stat. out of zybbix by calling a URL per resources.

That's my biggest desire for an API. The desire came out of a discussion at the client site I'm at now. They want to create a intranet portal like system. In this portal system they would like to show various aspects of Zabbix without having to log into Zabbix.

I can also see something like this being useful for other scripts as you mentioned.

Looks like I need to research more on REST.

[hwinkel]

That's my biggest desire for an API. The desire came out of a discussion at the client site I'm at now. They want to create a intranet portal like system. In this portal system they would like to show various aspects of Zabbix without having to log into Zabbix.

I can also see something like this being useful for other scripts as you mentioned.

Looks like I need to research more on REST.

We have exatly the same use case. our architecture relies on WSO2.org components. may the WS framwork for PHP http://wso2.org/projects/wsf/php can help to export informations from Zabbix as webservice. REST, JSON, SOAP it does not really matter. after that you can consume the data in a Portal you want.

[richlv]

That's my biggest desire for an API. The desire came out of a discussion at the client site I'm at now. They want to create a intranet portal like system. In this portal system they would like to show various aspects of Zabbix without having to log into Zabbix.

i think it would make sense to create a page on wiki for api design, wouldn't it ?
current state would be easier to track that way instead of a fullforum thread

we also had some discussion on irc regarding api, and the main conclusions we had :

1. web interface should use this api;
2. api can be introduced gradually by moving some functionality to it and make things like web interface use these new api calls;
3. api should be easily accessible in scripting languages;
4. in the end, web frontend communicates to api only.

now, i'm not sure about zabbix server - i guess there's currently some code duplication between zabbix server & frontend, but making server go through the api might be a performance drop oh-mighty...
as i don't code, this is all over my head, just something to consider for those who do.

i guess it's clear that first phase can cover web interface transition only. when api is available, other official interfaces (like cli) can be created, but what i hope most for - 3rd party involvement.
thoughts about plasma data source for zabbix warm my heart, and with the api neat applets could pop up.

[mcarbonneaux]

+5
i'm ok with that idea!!
SOAP, REST, XML-RPC, json... as you whant!!!
can be very usefull to automate many aspect of zabbix with large deployement...

and make possible to developpe web portal, special dashboard for manager...