Reporting and misc rave.

Stanley.Hopcroft at Dest.gov.au Stanley.Hopcroft at Dest.gov.au
Sun Feb 5 23:46:30 CET 2006


Dear Folks,

Firstly thanks to all that answered either on the list or privately.

I will now attempt to emulate a journalling file system by summarising
the responses.

1 Having Nagios availability in a DB is a good thing.

Doing so reduces the cost of reporting since there is are data
representation/conversion problems and the
extraction can be done with SQL thereby minimising the script-hell
problem.


2 Availability data capture 

Mr Shipways approach is too process the Nag logs periodically with
private/in-house (AFAIK) code to extract the
entries of interest and insert them as rows in a table(s).

(Incidentally, this sounds very enterprising since the extraction code
has to deal with all the cases handled by
avail.cgi. The difficulty of extracting outages from the logs is why I
chose to use avail.cgi as a source of
availability data).

Other approaches include event handlers that insert a row at the end of
an outage. This is easy to code but 
unfortch since AFAIk, there is no macro that indicates if scheduled down
time was prevailing may require manual 
post processing to update the column 'IN_SCHED_DOWNTIME'.

3 Reporting

>From Mr Shipway, Rouillard.

There are at least two DBs with ODBC connectors (SQL Lite and MySQL)
available.

This is very important since the availability of ODBC connectors make
available the wealth of
MS applications for 

  3.1 client programs eg update your DB with Excel

  3.2 reporting - use Excel charts for example

4 Re-use

Any site worth its salt will ultimately recognise the need for various
registries/directories that
reduce the cost of client coding.

Such registries/directories include

  4.1 Provider circuit IDs

  4.2 Addressing/subnets/VLANs etc etc

  4.3 Managed nodes

It would be helful if the Nagios config data could also be made
available as a DB.

Personally I think it would a bad thing if Nagios lost its template/text
driven 
config but the config data should be made available to other
applications so that there
is not the endless client code churn of mapping names between
applications.

One approach would be to use Al Tobeys Nagios::Config to load a config
DB.

Why is this useful ? At least one application is mapping structured node
names to
those used in Reports. What exec understands benrt200 ? What about
Bendigo ?


Thanks for your time.

Yours sincerely.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&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