[naemon-users] Naemon - an ITIL hint ...

[Andreas Ericsson]

On 2013-11-24 16:27, Martin Rueckert wrote:
> Hi Andreas,
>

Hey Martin.

> I've visited your presentation von Naemon on the OSMC in Nürnberg.
> Let me first tell you (just formally), that I have updated the "Nagios"
> page on the german wikipedia with the information about your fork...
>

Oh, that's awesome. Thanks! :)

> The primary purpose of my mail is to suggest a revision of the term "
> Problem" as it is used by Nagios until today:
> Corresponding to the analysis and exact definition of terms by ITIL, a
> monitoring tool like Nagios/Naemon can only determine Incidents.
> According to ITIL a problem is a (mostly not directly visible) trouble on
> a subjacent layer which can express itself by repeating incidents, or the
> other way round: The reason of some (repeating) incidents is a (subjacent)
> problem.
> Strategies and techniques to find and identify (the real) problem are
> quite tricky and usually need the execution oft tests and so on, so we can
> assume, that in the foreseeable future no monitoring software will have
> any opportunity to discover "problems".
> This lack of definition will become peculiar obviously when you join such
> worded monitoring alerts with an ITIL compliant ticket system.
>
> We run several Nagios based monitoring systems at our Managed Service
> Customers and to solve this "bug" I made some carefule changes in the
> Nagios code (V 3.x) and recompiled it:
> There a two locations in the code of base/notifications.c like
> mac.x[MACRO_NOTIFICATIONTYPE] = "PROBLEM";
> or
> mac.x[MACRO_NOTIFICATIONTYPE] = (char *)strdup("PROBLEM");
> and one in cgi/status.c where the item "problem"  has to be changed.


Hmm... Changing the names in the core really only affects notifications
and (to some extent) the NERD channels one can subscribe to.
Since a lot of people have already made custom notification scripts and
other addons that use the term "PROBLEM" as a marker, I'm uncomfortable
changing it without at least making it configurable.

As for the CGI's.. They're scrapped now and we'll be using Thruk as the
default UI.

> I wrote a (dirty hack) script to accelerate this modifications, maybe it
> will be helpful:
> cd /usr/local/src/nagios
> cat base/notifications.c | sed '/MACRO_NOTIFICATIONTYPE]
> =.*"PROBLEM"/s/PROBLEM/INCIDENT/' > base/notifications.c.NEW
>
> mv base/notifications.c base/notifications.c.ORG
> mv base/notifications.c.NEW base/notifications.c
>
> cat cgi/status.c | sed 's/All Problems/All Incidents/g' > cgi/status.c.NEW
> mv cgi/status.c cgi/status.c.ORG
> mv cgi/status.c.NEW cgi/status.c
>
> By this investigations of the source code I could see that the item
> "problem" is used for many many variable names. Without any overview about
> the whole code I kept my hands off them, ... grinding teeth.
>

Internal variables have little to do with the outside world though. The
integration points may be tought to use ITIL wordings, but modifying the
internals is a lot more troublesome (as it breaks module compatibility
and adds no value, so it gets chalked up as "harmful codechurn").

> Until now I didn't gave this input to nagios.org (their more and more
> commercialized website and their behaviour displeased me), but your
> presentation and the accentuation of "openness" sounds good for me so I
> thought, just try it  :-)
>

I appreciate it. To keep things that way, I've added the naemon-users
list to the To list here, so everyone can chime in if they like.

/Andreas

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.