So, what's up in the Opsview's world?

We're comparing APIs. A user was asking how Opsview's API compares to Icinga's API. We spent a bit of time investigating what the competition are up to.

What's an API?

According to Wikipedia, an Application Programming Interface is a way of having two programs talk to each other, in a known and consistent way.

So what does Icinga's API do?

Looking at their documentation, they have two APIs: a plugins API and a status API (which they call the Icinga API). The contents of the plugins API document looks almost exactly the same as the Nagios document - it looks like some liberties were taken there.

But the main point is that anything that calls itself "Nagios-compatible" will use the same Nagios Plugins API, in order to reach into the large number of plugins that are available. Opsview also uses the Nagios Plugins API - we just don't make much noise about it.

So it's nothing special?

Correct.

You said there were two APIs?

Their 2nd API is a status API, a way of getting host and service state information. It looks like it is just a thin layer to getting information from their recommended data store using IDOUtils. IDOUtils is based on NDOUtils, which Opsview has been using for the last 4 years (where we've also sent back lots of fixes and enhancements back upstream). The type of status information available in the database is very rudimentary: is this host up or down? Is this service critical or not?

So how does it stack up next to Opsview?

Here's why I think the Opsview API is superior:

  • Our API is a webservice, so anything that can talk HTTP can communicate with it. Our community have written dynamic web pages which present the data in a different way and we have a perl module on cpan to easily get data back. We've even prototyped a dashboard app to prove its functionality
  • Our API requires authentication, so users only see what they are allowed to see. Icinga's API is wide open, which means the responsibility for security falls onto programmers rather that the system itself
  • Our status APIs aggregate data, so you can get information like in the host group hierarchy pages which gives summarised totals for host and service states based on hierarchical information. The Icinga API will not scale to thousands of hosts because a program would need to count each state itself

The XML that describes the data on that page can be found on Opsview's Labs Blog.

Wow, that's neat!

Yes, because it decouples the data from the presentation. But the biggest advantage with our API is that it includes the ability to make configuration changes.

Why is changing your configuration via an API useful?

It's for automating changes. We have users that write scripts to talk to the API to add and delete hosts as part of their build process. Some users hook Opsview to their central configuration databases. As nice as our web UI is, you don't want to be doing regular changes all the time in the browser.

So Opsview comes out on top?

Yes, but I think this is because API is a bit of a loose term. Icinga's use of API is "how to write programs to get status information". Opsview considers "API" to mean "getting status data and making changes via a webservice". On those grounds, I think its a bit unfair to compare the APIs at the moment because the Opsview API is doing much more, at a much higher level.

Got any plans for the future?

Definitely! But I'll tell you about them later :)