RFC - advice actually - on availability reporting for management/PHB

Dear Ladies and Gentlemen,

I am writing with a plea for advice, or perhaps to point out an
opportunity for Nag/Netsaint development.

The opportunity is that while Netsaint 9and AFAIK Nagios) availability
reporting is magnificent, it doesn't meet management requirements of
being able to report against SLA.

The basic reason for this is that Netsaint is probably quite justifiably
ignorant of SLA factors such as

1. what elements (routers, servers, network nodes) are in a service

2. what constitutes the agreed level of service

(For example, if one is providing a LAN service

- all the switches, routers, SLBs serving the clients and servers are in
the service; as are the DNS, WINS, LDAP/AD and DHCP servers

- the agreement may be specified by completely arbitrary functions such
as

Service is OK if { DHCP, DNS and WINS servers are up 100%
                 { some proportion of client network nodes (switches
                   etc) are up 100%
                 { all server network nodes are up 100%
)

It seems to me that the second requirement - the specification of the
SLA function/agreement is completely arbitrary or site dependent and
therefore has no relationship with Nag/Netsaint whatsover. It belongs to
the reporting package - the bit that takes the SLA function, the
host/service downtime and produces the report.

(OTOH, Netsaint seems to adopt a simple SLA of agreement per host or
service based on the proportion of host/service up time.

Then again, it could be said that the reporting function _could_ employ
the existing host/service (node) downtime provided by avail.cgi
[the CSV report of node availability]

However, my experience is that even mailing the output of avail.cgi as
an Excel attachment [set MIME type of attachment] has failed to satsify
the local PHBs).

The approach my colleagues and I would therefore like to adopt is to
store in an ODBC accessible database (mySQL), records of node downtimes
eg

host_name, service_description, downtime, time_date (prob at the end of
the downtime)

and let folks report how they like from that using the reporting tools
they choose. They can see the downs [which they may already know about]
so rather than gawk at %UP/OKss they see the list of downs for that
node.

Please would you comment on

1 How helpful or otherwise you think this approach may be

2 How to update the DB with the interval for which the node was
unavailable (yes, the DB is really only acting as a file store but one
that is accessible to authorised users from their Win desktop, and that
provides simple queries).

In regard to 2, the global service handlers seem to be a means of
responding to HARD state changes. Logging them could produce a list
like

1034949832 mvs;Logon to production database;CRITICAL;HARD;3 Menu .. not
found: FWP use this service either press ENTER for guest access type
valid Userid and pres s ENTER For more information press N20205 SELECTED
APPLICA
1034950132 mvs;Logon to production database;OK;HARD;3 Logon to
Production database Ok.
1034968553 mvs;FTP;CRITICAL;HARD;Socket timeout after 10 seconds
1034968843 mvs;FTP;OK;HARD;FTP ok - 1 second response time

that could be batch processed to update the database periodically
(hoping that there is always an Ok or UP after each CRIT or DOWN, or
leaving it 'til next time).

Is there a way of doing this in 'real time' ie when the UP/OK event
occurs the event handler computes the down interval and issues the
update ?

What seems to be required is some way of registering a 'callback' or
handler for each CRIT/DOWN event that would be called in response to the
UP/OK event.

If I were to implement this, 

. the event handler would only respond to HARD states

. the event handler would update a persistent store with the DOWN/CRIT
details

. the event handler would search the store for any DOWN/CRIT record with
the same host and service name as the current UP/OK event, update the DB
with the details and delete the DOWN/CRIT details from the persistent
store.

This sounds pretty yukky and nasty, and prone to races (despite the
generally minute intervals between HARD state changes).

Are there better ways ?

Yours sincerely.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This sf.net email is sponsored by:
Access Your PC Securely with GoToMyPC. Try Free Now
https://www.gotomypc.com/s/OSND/DD