Nagios::Report (end of dev cycle).

Stanley.Hopcroft at Dest.gov.au Stanley.Hopcroft at Dest.gov.au
Tue Mar 21 06:06:06 CET 2006


Dear Sir,

I am writing to thank you for your letter and say,

>-----Original Message-----
>Content-Disposition: inline
>
>Hmm,
>
>it would be a pitty not to develop this thing further. Like 
>you say it provides the kind of reports management likes and 
>up until now it is the only way I have found to create biased 
>reporting.
>
>What do I mean ? I mean I don't care about how many hours 
>application or server xyz was down during the weekend. Those 
>hours are of no importance to me in terms of management 
>reports. The information and especially metrics outside of 
>these hours need to be taken for administration purposes of 
>course. But the weekend is used here for maintenance as is the 
>case in many places. For my SLA's these hours should not be 
>counted. Up until now your tool is the only tool I have found 
>that can ignore data based on time-table= s in its reports.
>
>So as far as I am concerned please keep up the good work.
>

The reason for saying that devel has prob ceased is that
I have run out of ideas for it and think it may have reached the 
limits imposed by some of the implementation choices.

OTOH, if there are things that need fixing or facilities I think can be
added, please let me know.

The other thing is that the modules reason for existence is to provide
an API 
for the only current source of availability data, namely avail.cgi.

avail.cgi is complicated and may not be maintained as responsively as
people 
may wish - I can't imagine submitting patches for it without a great
deal of hard
labour.

If on the other hand, somehow (as you say with the NEBs) outage details
can be stuffed by
the core into an RDBMS, then people can use all sorts of wonderful
software from the
DB/report world to generate very sophisticated reports.

In fact, when I heard about DBD::AnyData I thought this would blow the
original
API (of Nagios::Report) away because people would SELECT to their hearts
content.
As it turned out, the SQL implemented by the AnyData module is not as
powerful as
one would like and in fact is good for only basic filtering.

So my feeling is that Nagios::Report is a stop gap for me until
something better comes
along.

Another technique that I find useful is to have a Nag event handler
insert 
outage details into a table. This in principal allows one to
combine outages with (manual updates) with causes and commentary. 

>Question though .. DB NEB modules ?
>

Thanks for your encouraging words.


>Cheers,
>Hans

Yours sincerely.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list