On Wed, 2006-06-28 at 16:06 +0200, Volker Maibaum wrote:
> > Brad O'Hara wrote:
> > > In line.
> > >=20
> > > Andreas Ericsson wrote:
> > >=20
> > >> Volker Maibaum wrote:
> > >> =20
> > >>
> > >>> Hi,
> > >>> I have some feature requests for nagios:
> > >>>
> > >>> - set contactgroups on host basis for services. So that if no
> contact is
> > >>> set for a service check the host contact group is used. That =
would
> make
> > >>> configuration a lot easier.
> > >>>
> > >>> =20
> > >>
> > >>
> > >> This I like.
> > >>
> > >> =20
> > >>
> > >>> - It would be nice if it would be possible to categorise the
> criticality
> > >>> of services and hosts. E.g. critical / uncritical / unimportant.
> So that
> > >>> the operating could easily decide if they have to call somebody
> during
> > >>> midnight or if the problem can wait till the next morning.
> > >>> I know this could also be done by host and servicegroups, but it
> would
> > >>> be nicer to have this as a parameter. Depending on the category
> the
> > >>> host/service could be highlighted with different colours in the
> > >>> web-frontend.
> > >>> =20
> > >>
> > >>
> > >> This I don't. It's very, very simple to make the right contacts
> the=20
> > >> contacts of critical hosts and services and have any script you
> want=20
> > >> do the actual contacting, so adding complexity to the core to =
give=20
> > >> another way of doing the same thing doesn't sound very useful to
> me.
> > >>
> > >> =20
> > >=20
> > > True enough. Our problem is that we have operations staff monitor =
> > > Nagios and notify people off hours based on how critical the
> "resource"=20
> > > is not the severity of the check.
> > >=20
> >=20
> > Ok. Then you're not using the first alternative, which would be to=20
> > create a notification script for the contacts supposed to be on call
> for=20
> > the night. Nagios is fully capable of dialing your technical staff
> and=20
> > telling them that "this and this unit isn't functioning". I think
> you're=20
> > also aware that you can use several different notification-commands=20
> > (they don't have to notify, they can do anything you can make a
> computer=20
> > do, really), and this in combination with the possibility of setting =
> > several or different contactgroups for each host and service is, =
imo,
> a=20
> > better solution than to implement configuration options. Mostly =
since=20
> > those options will easily become outdated, but also because of the
> need=20
> > to add more bloat to the core of Nagios.
> >=20
>=20
> The problem is not only about notification. I could implement two =
email
> scripts, one that writes in the subject "critical" and one that writes
> "not so important". But if the staff looks at the web-frontend of =
nagios
> they don't see any difference. A "kernel panic" appears in the same =
way
> as "the soda machine is out of water". The operating staff that looks =
at
> nagios does not now that the soda machine is not critical. But they =
have
> to decide if we have a critical situation and if they have to call an
> expert.
Here we set criticality with max_check_attempts, and there is a formal
way to staff for ticketing an incident. The higher the criticality is,
the lower max_check_attempts is, so when it reachs max check attempts,
there is a problem.=20
HTH,
Marcel.
> =20
> regards,=20
>=20
> Volker=09
>=20
> Using Tomcat but need to do more? Need to support web services, =
security?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
> =
http://sel.as-us.falkag.net/sel?cmd=3Dl ... 57&dat=3D=
121642
> _______________________________________________
> Nagios-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/lis ... gios-devel
AVISO: A informa=E7=E3o contida neste e-mail, bem como em qualquer de =
seus anexos, =E9 CONFIDENCIAL e destinada ao uso exclusivo do(s) =
destinat=E1rio(s) acima referido(s), podendo conter informa=E7=F5es
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]