re-implement check_yum in C/C++ or Perl

[GoogleCodeExporter]

I think it would be good to re-implement check_yum either in C or C++... or 
possibly in Perl.

C/C++ have the typical advantages of real programming languages... 
(performance, etc.).

Perl, while also being a crappy script language, has at least some "special" 
support within Nagios/Icinga via the embedded Perl interpreter.


Anyway, this is surely a long term goal. 

Original issue reported on code.google.com by [email protected] on 9 Oct 2012 at 12:08

[HariSekhon]

As the original author I've also written a Perl version of this program but it doesn't support ePN as it's not worth the effort, plus it wouldn't be executed via ePN anyway as it's a local check to each server. See the full documentation of the original upstream project see here:

Advanced Nagios Plugins Collection

[calestyo]

Well that with ePN is not necessarily true... a proper rewrite of the plugin could e.g. allow to have the plugin run locally on the monitoring server, and only yum invoked remotely (e.g. via ssh) and it's output parsed by the local plugin.
Would have the advantage of not needing to distribute check_yum (which isn't packaged for any major distro, AFAICS)...

Whether this scales is however another question (as is, whether ePN would be still beneficial such case).

I've actually had started with re-writing it in perl some months ago, but this got basically infinitely interrupted right now, cause I have to relocate to another flat, etc. pp. ;-)

I think, there should be only one version of the plugin and not many just in different programming languages...
If it was a decision Python vs. Perl, than in principle I'd vote for perl for Icinga plugins, not because I'd like it so much, but because of the ePN thingy, and because Perl seems to be even a bit more "base software" than Python (e.g. in Debian perl is essential, while python is not).

Cheers,
Chris.

[HariSekhon]

Switching from NRPE to ePN + SSH would seem like a performance downgrade - iirc NRPE is written in C, ePN is still Perl just without interpreter re-start.

I worked with ePN years ago and it's a p.i.t.a., it's harder to debug and I already have test frameworks for most of the plugins in the Advanced Nagios Plugins Collection - it would be harder to correctly simulate ePN.

What I found with ePN was that plugins that worked normally on the CLI could easily fail or exhibit behaviour that appears random if not coded carefully and specifically for the ePN environment - so you end up wasting time fighting inside ePN shell.

Ultimately I found it to be a poor trade off of engineer time for negligible performance gain when more modern thinking is the opposite to just get faster servers and more of them. Also, given I ran 13,000 checks per nagios server on hardware available in 2010 this seems like completely premature optimization (and you know that engineer saying about the root of all evil), especially as we're in the age of distributed computing and horizontal scaling which is a much better architecture to work to and one that more modern nagios compatible enterprise monitoring servers seem to be aware of.

In short ePN is good in theory but not so great in practice - I don't foresee ever supporting ePN.

Regarding Python vs Perl I did go that way already, again around 2010, and I'm coming back the other way now. It's not such a big deal either way as advanced plugins usually need 3rd party libraries to interact with the software they're checking, which are usually more annoying to install than system packages like python.