Hi Torsten
That looks excellent. Unfortunately, I will only be back at $CLIENT next week, but I will give that a go when I get there. It looks like exactly what I am looking for.
Thanks Vernon
On 17 December 2014 at 16:02, Torsten Richter <bb4 at richter-it.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Vernon,
I actually do this for a client too. Since the alerting is outsourced to an external company over the weekend and this company uses BMC P*** I need to forward all of the red or purple alerts to this console.
This is what I have in alerts.cfg:
SCRIPT /home/bbrother/hobbit/server/ext/sendpatrol <IPofCONSOLE> DURATION>6 COLOR=red,purple RECOVERED
Thus it sends for all red and purple alerts a trap to the remote console and if something goes back to green another trap is sent to autoclose the event.
The recovery is not working if something goes from red to yellow and THEN to green. Therefor I use a cron script that checks every hour if there are alerts that are expired and then sends the autoclose trap to the remote console.
The remote guys need to have the information in a special order. So basically the script is calling snmptrap with some parameters and thats it.
The command looks like this:
SNMP="/usr/bin/snmptrap" MIBNAME="NET-SNMP-EXAMPLES-MIB" MIBTLVL="netSnmpExampleScalars" MIBSCLR="netSnmpExampleString" SNMPLOG="${BBTMP}/patrol.log"
${SNMP} -v ${VERSION} -c ${COMMUNITY} -Lf ${SNMPLOG} ${RCPT} ""
${MIBNAME}::${MIBTLVL} ${MIBSCLR} s
"${BBHOSTNAME};${BBSVCNAME};${BBCOLORLEVEL};ALARM ${ALARMNUM}
(${ESCALATION});${BBCOLORLEVEL}"SNMPLOG is a file where snmptrap puts some useless information and it is overwritten every time.
As most of the variables are self explaining I will only explain 2 of them:
ALARM ${ALARMNUM} - ALARM is the keyword and ALARMNUM is a phone no. the guys have to call. ${ESCALATION} - is the phone no. of the manager on duty if they don't reach someone on the other line.
HTH Torsten
On 17.12.2014 05:24, Vernon Everett wrote:
Hi all
At $CLIENT, an "executive decision" was made to do all monitoring using $OTHER_TOOL. $OTHER_TOOL uses only SNMP. Although the results in Wintendo-land are acceptable, what we get in Solaris-land is not.
As a compromise, it was resolved to keep Xymon for Solaris-land for admin team monitoring and diagnostics, but get it to send critical elerts to $OTHER_TOOL in the form of SNMP traps. This might not even make sense, but somehow, probably using the SCRIPT directive in alerts.cfg, I need to notify $OTHER_TOOL of critical events.
Any tips on how?
Regards Vernon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
+---------------------------------------------------------+ | E-mail : bb4 [at] richter-it.net | | | | Homepage: http://www.richter-it.net/ | +---------------------------------------------------------+ Download my public key from: http://gpg-keyserver.de/pks/lookup?search=0x899093AC&op=get -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32)
iEYEARECAAYFAlSROLMACgkQ7DlmxomQk6yPAgCdHO4N1fs94508jDRW/CdIBq+U UeYAoNMWjNBOMk3F7/nkpERewmJYVX80 =+xZ4 -----END PGP SIGNATURE-----
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- "Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton