Hi David,
The problem is that the Alarm backend only allows you to
create a single
event type from a status change.
Therefore, although you get the ok /
degraded text
through to the Event, it will always be raised at the same
severity, which I suspect is not what you want.
I had a similar issue some time ago where I was monitoring an
OID which had
some concept of the severity of the
alarm, and provided multiple states,
rather than just
up or down, and wanted to raise an alarm and event relevent
to this severity. In order to do this, I wrote the multi_alarm
backend,
which will take "|" separated descriptors
which will translate the poller
outputs (ok, down,
degraded etc) into the associated Event IDs (defined in
the JFFNMS database). Therefore when the poller returns "down",
it will
raise one (Critical) event, when it returns
"degraded" it can generate
another (say Minor).
See my mail in the archive at
http://www.mail-archive.com/jffnms-users@lists.sourceforge.net/msg03176.html,
which describes the setup, and has the files required.
Note that you will
have to pipe the SQL file through
MYSQL, and replace the have_other_alarm()
function in
/opt/jffnms/lib/api.events.inc.php with that included in the
"function_have_other_alarm.php" file. The multi_alarm.php file
can be
dropped into the engine/backend directory as it
stands. I would strongly
recommend backing up
your database and files first!!
(BTW, Javier, I haven't forgotten about submitting the
interface types which
I was working on - will get
those through soon).
Hope this helps.
Regards,
Craig
> ----- Original Message -----
>
From: "LIMA David" <[EMAIL PROTECTED]>
> To:
"Javier Szyszlican" <[EMAIL PROTECTED]>
> Cc:
<jffnms-users@lists.sourceforge.net>
> Sent:
Tuesday, August 02, 2005 2:06 PM
> Subject: RE :
[jffnms-users] Generic snmp_status and
>
temperature_aggreagation
>
>
>
> Hi
Javier
>
>
> > snmp_status allows you to put more than 2 states.
The first that matches
> will
> > be returned, and if no match is found, it will return "down"
(that is
hard
> >
coded).
>
>
> So if for example I create this ==>
>
.1.3.6.1.4.1.232.6.2.6.7.1.9.<chassis>.<fanindex>,2=up|1=other|3=degraded
>
> How do I manage the 1 or 3
alarm state? do I have to add another alarm
type,
> because I want to know when my fan
is in degraded mode (not down or up)
>
>
> 2-
temperature_aggregation
>
> My discovery script is good because I pass the interface name to
the
table.
> When I look at
other aggregration graphs (Compaq) it's the same thing, the
> hostname and short-client are displayed in front of each rrdtool
line but
> not the interface name (if you have 2
temp for the same host you can't
find
> out which line if for which sensor)
>
>
_______________
> David LIMA
> Professional Services
>
www.scc.com
>
>
>
>
> -----Message d'origine-----
> De :
[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
De la part de Javier
> Szyszlican
> Envoyé : dimanche 31 juillet 2005 17:00
> Cc : jffnms-users@lists.sourceforge.net
> Objet : Re: [jffnms-users] Generic snmp_status and
temperature_aggreagation
>
> Hi David,
>
> >
> > The problem is the same
with Compaq temperature or fan interface type,
>
JFFNMS is
> > sometime reporting down state but
when we look at the Compaq Mib the
> > fans can
be in other(1) ok(2) degraded(3) or failed(4) mode. When i
look
> at the logs I saw that
Other state happens some times (I have less down
>
events when I put this in the poller ==>
>
.1.3.6.1.4.1.232.6.2.6.7.1.9.<chassis>.<fanindex>,2=up|1=other)
> > Perhaps we can extend the snmp_status to manage 3
or 4 states ?
>
>
snmp_status allows you to put more than 2 states. The first that
matches
> will be
>
returned, and if no match is found, it will return "down" (that is
> hard-coded).
>
> >
> > 2-
temperature_aggregation
> >
> > The temperature graph is well shown but I can't see the
Interface
> > Name front of each RRD line
on the aggregation graph (only host name
and
> > zone shortname + RRD data: Average Max and
Min). Do I miss something
in
> > the Interface declaration ?
> >
>
> The
interface name is taken from the "interface" field in the interfaces
> table,
> you should check if
the name is correctly set there, that is set by the
> discovery script.
>
> Javier
>
>
--
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
Javier Szyszlican, Project Leader, JFFNMS
>
[EMAIL PROTECTED]
>
> I
hope JFFNMS or I were helpful to you, if you
> can,
please donate at http://jffnms.org/donate
>
>
>
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
> from IBM. Find simple to follow
Roadmaps, straightforward articles,
> informative
Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jffnms-users mailing list
>
jffnms-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jffnms-users
>
>
>
--------------------------------------------------------------------------
--
> --------------
>
> Ce message contient des
informations dont le contenu est susceptible
d'être
> confidentiel.
> Il est destiné au(x) destinataire(s) indiqué(s)
exclusivement.
>
> A
moins que vous ne fassiez partie de la liste des destinataires, ou que
> vous soyez
> habilité à
recevoir le mail à leur place, il vous est interdit de le
copier,
> de l'utiliser
> ou de dévoiler son contenu à un tiers.
>
> Si vous avez reçu cet email par
erreur, merci de prendre contact avec
>
l'émetteur.
>
> Les
opinions exprimées dans cet e-mail sont celles de l'émetteur et ne
> reflètent pas
>
nécessairement celles de l'entreprise.
>
> Ce e-mail peut contenir des pièces jointes dont
certaines pourraient
> contenir des virus
> qui pourraient endommager votre système
informatique.
>
> La
compagnie a pris toutes dispositions afin de minimiser ce risque et
> décline toute
>
responsabilité pour toute perte ou dommage résultant directement ou
> indirectement de
>
l'utilisation de cet email ou de son contenu.
>
> Il vous appartient d'effectuer vos
propres contrôles anti-virus avant
>
d'ouvrir
> la ou les pièces jointes.
>
--------------------------------------------------------------------------
--
> --------------
>
>
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference
& EXPO
September 19-22, 2005 * San Francisco, CA *
Development Lifecycle Practices
Agile &
Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
jffnms-users mailing list
jffnms-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jffnms-users
