Monday, May 11, 2009

Icinga musings

So I just heard about the Icinga fork of Nagios. Looking at the motivation, I can't say that I disagree with the fork. Obviously there are a standard set of "things" that most people add to Nagios. Many times those "things" feel like they should be standard and others are just fluff.

Looking over the Icinga project team, we can get a feel (and from the project goals) the things that they want to add on:

  • PNP
  • NagVis
  • Grapher
  • NagTrap
  • more NDO

I can get behind most of those. I think they're all wonderful addons. However, I have some reservations about one of the ones not listed. This is from the Icinga page:

The most significant modification and difference to Nagios is a completely new web interface based on PHP. This allows a wider circle of developers to contribute to the web interface and easier adjustments to be made by users to their individual environments.
I honestly just cannot get behind that in principle. I fully understand the concerns and problems people have. The Nagios interface is "ugly" in a sense but change for change's sake is just silly.

Why PHP? Why not perl (see Groundwork) or ruby or python? It's an arbitrary decision. I like my Nagios installations slim and doing what they do best, monitoring and alerting. You don't even HAVE to have a web interface. I don't want to have to bog down my monitoring server with YAP (yet another package). For all its warts, I like the way the Nagios web interface worked. There's nothing wrong with CGI scripts. They work. The Nagios cgis worked.

Was it a bitch to deal with them? Of course but moving to PHP isn't going to immediately make it better unless there's a framework or an API or standards to work against. I have full faith in the Icinga team to make an outstanding interface but I'm wondering what sort of process is going to be in place to make sure the interface is "stable". One thing that can be argued in favor of the current setup is that it's not at the whims of a constantly changing language like PHP.*

I guess my feeling is that the Icinga folks want to make something MORE of Nagios. Make it more than what it is at the core - network monitoring. There's a valid argument to be made that an "enterprise" monitoring system should have an SNMP trap handler but I personally don't think snmptt is the way to go. If it's that important, it should be something NOT written in a scripting language. If handling traps is of the utmost importance, it should be able to handle whatever volume of traps per second you throw at it. I can't find any performance numbers for snmptt so I can't tell you.

I think the biggest problem I've had with Nagios is that it isn't modular enough. It lacks something we've all come to appreciate these days - the concept of plugins. Admittedly, it's one guy. If he doesn't see a need for it, then we probably won't ever see it. Nagios really needs a standard way for people to plug in to it. Right now we have bolt-on solutions that never REALLY feel integrated. Maybe that's what Icinga wants to do. I can appreciate, however, the lean-ness that Nagios has had for this long. Maybe times have changed an monitoring doesn't just encompass monitoring anymore. I don't know but in my mind, monitoring is still a distinct entity from trending. They go hand in hand but Nagios has never billed itself as an all in one monitoring and trending solution. It monitors, and it alerts. Occasionally it "event handles" but long term storage and analysis of the data is out of scope.

Anyway, much of this has been a ramble based on first blush. I'm sure I'll have more to say. I'll follow the project closely and see what it does. I fully expect a lot of people to switch over just for the "completeness" and "asthetic" factor. Groundwork has clients after all. The demand is there. However, I'm just not sure if I'll make the switch myself.

Maybe the whole thing will prompt Ethan to respond in a positive way and make my wish list come true ;)

- API into the monitoring system
- Native support for RRD storage of perfdata information

Those are my two biggest. I would LOVE to have an API into the live core of the engine to make changes to resources. One thing that I loved about Groundwork (I think it was Groundwork) was that it had a command-line API for adding and removing hosts. I'm really hoping that in the end, we end up with Nagios as a framework with its own basic functionality but that better allows the design of solutions built on top of it. Want to build your own interface? Pull a list of hosts from the API. Pull a list of last known states for each host. Display it.

* By constantly changing, I mean compared to traditional languagues like C. PHP also has (and many developers will admit this) inconsistencies and other "gotchas" left over from years of backwards compatibility.


Mark Young said...

My information about icinga is that they are not going to be combining their respective graphing projects to the core. Instead they are focusing on developing the core with database (eg nagios w/ ndoutils), a separate db api, and a php web interface to use the db/api.

I think PHP is the way to go. And I don't understand why you have such a problem with it. I understand in some regards that PHP has some klingons from eons past.. but it is a widely accepted web language. With a remarkably wider programmer base than perl, python, and definitely ruby (which I love by the way, but is not widely accepted). And your first grip about PHP having growing pains needs to look no further than the perl version changes, which move slowly but make major code breaking changes.

PHP also has the benefit of being part of the ubiquitous LAMP stack which makes it easily available on all systems. (I had a mini microprocessor setup with php) No one worries about PHP working but getting other languages to work with Apache or Lighttpd is a PAIN. (needed if you run more sites than just perl, ruby, etc web services)

What I think you should be most excited about is the API. It will allow anyone to write a new web service, interface, etc making a few calls (in PHP). But I don't see that it will be long that you can make complete web service calls. I have plans for some iPhone development if everything takes off.

The code is available now to look at. I was given a sneak peak and have been checking it out for the last few days. Very interesting in regards to the API. Everything else is simply renaming.

Sorry to nag. Don't think to badly of me being a PHP advocate. :-) I understand the love of perl and ruby. Great post. Came from twitter (@zarzax). I'll be checking back soon!

lusis said...

@zarzax/Mark Young,

I should probably clarify my comment about php. I've worked it since the php3 days. I appreciate it as a language but when I mentioned it constantly changing, I was thinking more about things like this:

In fairness, that was from 5.0 to 5.3 but it became UNdeprecated. What's the point of deprecating it in the first place? There are plenty of examples of this throughout php's history. I can't find one off-hand but I even remember a point release having the same thing happen (removed in X.Y.1 and added back in X.Y.2).

And nothing that's deprecated is ever actually REMOVED from the code. Maybe if they stick to Zend Framework then it would be better (they being the Icinga folks) but I just feel like php is WAY more overhead than is needed.

Do I have php on all of my apache servers? Probably. It's pretty ubiquitous but I could run Nagios with whatever webserver I wanted using the CGIs.

I wasn't suggesting that they do the interface in any specific language just that php wouldn't have been my first choice. I'd probably wager that perl has a greater install base than php. Of course then you have the headache of mod_perl when you have performance issues.

I'm glad you're looking forward to it. It's good to get feedback from someone who's seen the code.

Scott said...

Hi... I'd be interested if you have any further opinions/experiences since this blog post was released?

Scott Evans (icinga-team)