help setting up SNMP traps to Xymon
Hello, I'm running Xymon 4.2.3 on RHEL 5.4 and I'm trying to setup Xymon to receive SNMP traps from our Oracle database servers. We are also running Oracle Enterprise Manager on another server (we call it the "grid") that monitors the Oracle database servers too, but our DBA's want to use Xymon to alert them of Oracle problems instead of the grid server so they don't get alerts from two different places. The DBA's manage OEM(therefore I'm not familiar with it), and have configured it to recieve SNMP traps and send them to Xymon.
I configured the Xymon server to receive traps using the documentation at http://cerebro.victoriacollege.edu/hobbit-trap.html. We do receive traps, but there are two problems:
1- The trap status diamond does not change color when it gets a trap or when the trap clears. My understanding is that this is set in the Oracle MIBS that are translated to the /etc/snmp/snmptt.conf.oracle file. I'm not sure how to change the file to get it to give different alerts. If I change the word "NORMAL" in the following line to "SEVERE" the trap status will go red, but will not return to green when the trap clears. Any suggestions on how to fix this?
EVENT oraEM4Alert .1.3.6.1.4.1.111.15.2.0.1 "Status Events" Normal
2- The traps status changes for the grid server instead of the database server with the problem. Drilling down into the "trap" status, you will see an error for the database server though. The snmptrapd.log and snmptt.log files (examples below) show the traps coming from the grid server. Does anyone know how to get the traps to appear under the database server name rather than the grid server?
Example snmptrapd.log entry (host name changed): 2010-10-14 19:04:49 grid-server [xxx.xxx.xxx.xxx] (via UDP: [xxx.xxx.xxx.xxx]:51617) TRAP, SNMP v1, community public .1.3.6.1.4.1.111.15.2 Enterprise Specific Trap (1) Uptime: 0:06:31.00 .1.3.6.1.4.1.111.15.1.1.1.2.1 = STRING: "DB00157.world" .1.3.6.1.4.1.111.15.1.1.1.3.1 = STRING: "Database Instance" .1.3.6.1.4.1.111.15.1.1.1.4.1 = STRING: "database-server " .1.3.6.1.4.1.111.15.1.1.1.5.1 = STRING: "Status".1.3.6.1.4.1.111.15.1.1.1.6.1 = "" .1.3.6.1.4.1.111.15.1.1.1.7.1 = "" .1.3.6.1.4.1.111.15.1.1.1.8.1 = STRING: "Oct 14, 2010 7:04:00 PM EDT" .1.3.6.1.4.1.111.15.1.1.1.9.1 = STRING: "Critical" .1.3.6.1.4.1.111.15.1.1.1.10.1 = STRING: "Failed to connect to database instance: ORA-01033: ORACLE initialization or shutdown in progress (DBD ERROR: OCISessionBegin)." .1.3.6.1.4.1.111.15.1.1.1.11.1 = STRING: "Test SNMP database-server DB Down " .1.3.6.1.4.1.111.15.1.1.1.12.1 = STRING: "SYSMAN" .1.3.6.1.4.1.111.15.1.1.1.13.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.14.1 = "" .1.3.6.1.4.1.111.15.1.1.1.15.1 = STRING: "923A730174F36B87E040E6801417642D" .1.3.6.1.4.1.111.15.1.1.1.16.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.17.1 = "" .1.3.6.1.4.1.111.15.1.1.1.18.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.19.1 = "" .1.3.6.1.4.1.111.15.1.1.1.20.1 = STRING: "1" .1.3.6.1.4.1.111.15.1.1.1.21.1 = STRING: "923A421065A8A060E040E68015173993"
Example snmptt.log entry: Oct 14 19:04:52 xymon-server snmptt[0]: .1.3.6.1.4.1.111.15.2.0.1 SEVERE "Status Events" grid-server - The variables included in the oraEM4Alert trap. DB00157.world Database Instance database-server Status Oct 14, 2010 7:04:00 PM EDT Critical Failed to connect to database instance: ORA-01033: ORACLE initialization or shutdown in progress (DBD ERROR: OCISessionBegin). Test SNMP database-server DB Down SYSMAN 0 923A730174F36B87E040E6801417642D 0 0 1 923A421065A8A060E040E68015173993
Thanks in advance for any help. I'm sorry for the lengthy question.
Nicole Beck
Greetings all...
We've been running hobbit 4.2.0 for quite a while, and I've started the process to upgrade to xymon 4.2.3.
After the install which went pretty smooth, I realized that xymon 4.2.3 didn't support the hobbit-holidays.cfg, and I assume, a few other features.
So I see that 4.3.0-beta2 has been out for quite a while. Do many consider it to be a stable release, or stable enough that you are using it without problems?
So I take it hobbit-holiday.cfg is not part of the 4.3.0-beta2 code? Do you have to grab that from a snapshot version?
From: Taylor Lewick [mailto:tlewick at tradebotsystems.com] Sent: Friday, October 15, 2010 9:56 AM To: xymon at xymon.com Subject: [xymon] how beta is xymon 4.3.0-beta2
Greetings all...
We've been running hobbit 4.2.0 for quite a while, and I've started the process to upgrade to xymon 4.2.3.
After the install which went pretty smooth, I realized that xymon 4.2.3 didn't support the hobbit-holidays.cfg, and I assume, a few other features.
So I see that 4.3.0-beta2 has been out for quite a while. Do many consider it to be a stable release, or stable enough that you are using it without problems?
I downloaded the 4.3.0-beta2 version of xymon. I can see in the hobbitd/etcfiles directory that it contains hobbit-holidays.cfg, and in lib I can see holidays.c, holidays.h, and holidays.o.
But when I ran configure, make, make install, I'm not seeing the hobbit-holidays.cfg in /home/xymon/server/etc, nor in the man pages, nor any holidays binary files.
So do I need to specify some option via configure or in makefile to enable hobbit-holidays.cfg support?
Nevermind, figured out you have to manually copy the hobbit-holidays.cfg to your /home/hobbit/server/etc directory, and define HOLIDAYFORMAT in hobbitserver.cfg, then the Holidays show up in the info column.
From: Taylor Lewick [mailto:tlewick at tradebotsystems.com] Sent: Friday, October 15, 2010 2:07 PM To: xymon at xymon.com Subject: [xymon] enabling hobbit-holidays
I downloaded the 4.3.0-beta2 version of xymon. I can see in the hobbitd/etcfiles directory that it contains hobbit-holidays.cfg, and in lib I can see holidays.c, holidays.h, and holidays.o.
But when I ran configure, make, make install, I'm not seeing the hobbit-holidays.cfg in /home/xymon/server/etc, nor in the man pages, nor any holidays binary files.
So do I need to specify some option via configure or in makefile to enable hobbit-holidays.cfg support?
On 10/15/2010 10:56 AM, Taylor Lewick wrote:
So I see that 4.3.0-beta2 has been out for quite a while. Do many consider it to be a stable release, or stable enough that you are using it without problems?
You might consider holding off on 4.3.0-beta2, the developers are getting close to releasing a new beta that has many fixes and improvements. If it were up me, I'd stay on 4.2.3 for now and just get the new beta or release candidate when it comes out.
For more details, check out this thread:
http://sourceforge.net/mailarchive/message.php?msg_name=20101008133408.GA285...
Tom
Thanks, when you say close, can you be a bit more specific?
-----Original Message----- From: Tom Georgoulias [mailto:tomg at mcclatchyinteractive.com] Sent: Friday, October 15, 2010 2:05 PM To: xymon at xymon.com Subject: Re: [xymon] how beta is xymon 4.3.0-beta2
On 10/15/2010 10:56 AM, Taylor Lewick wrote:
So I see that 4.3.0-beta2 has been out for quite a while. Do many consider it to be a stable release, or stable enough that you are using it without problems?
You might consider holding off on 4.3.0-beta2, the developers are getting close to releasing a new beta that has many fixes and improvements. If it were up me, I'd stay on 4.2.3 for now and just get the new beta or release candidate when it comes out.
For more details, check out this thread:
http://sourceforge.net/mailarchive/message.php?msg_name=20101008133408.G A28575%40hswn.dk
Tom
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
In <98B0CDCB28A5EE4CB3678CD99406644E04313D94 at tbmail2.tradebot.com> "Taylor Lewick" <tlewick at tradebotsystems.com> writes:
Thanks, when you say close, can you be a bit more specific? =20
Next week, if I can convince the other developers that it's a good idea.
Regards, Henrik
I vote for "When it is ready."
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
On Fri, Oct 15, 2010 at 5:27 PM, Henrik Størner <henrik at hswn.dk> wrote:
In <98B0CDCB28A5EE4CB3678CD99406644E04313D94 at tbmail2.tradebot.com> "Taylor Lewick" <tlewick at tradebotsystems.com> writes:
Thanks, when you say close, can you be a bit more specific? =20
Next week, if I can convince the other developers that it's a good idea.
Regards, Henrik
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
Asked and answered. http://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Other_Docs/FAQ#Whe...
Regards Vernon
On Sat, Oct 16, 2010 at 4:28 AM, Taylor Lewick <tlewick at tradebotsystems.com>wrote:
Thanks, when you say close, can you be a bit more specific?
-----Original Message----- From: Tom Georgoulias [mailto:tomg at mcclatchyinteractive.com] Sent: Friday, October 15, 2010 2:05 PM To: xymon at xymon.com Subject: Re: [xymon] how beta is xymon 4.3.0-beta2
On 10/15/2010 10:56 AM, Taylor Lewick wrote:
So I see that 4.3.0-beta2 has been out for quite a while. Do many consider it to be a stable release, or stable enough that you are using it without problems?
You might consider holding off on 4.3.0-beta2, the developers are getting close to releasing a new beta that has many fixes and improvements. If it were up me, I'd stay on 4.2.3 for now and just get the new beta or release candidate when it comes out.
For more details, check out this thread:
http://sourceforge.net/mailarchive/message.php?msg_name=20101008133408.G A28575%40hswn.dk
Tom
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
1 - clearing the trap.
Unfortunately, the only way the SNMP trap status changes on Xymon is when it receives a new SNMP trap from the device. If the device would send an "all clear" type of trap when it was happy, that'd change the status back to green. If there's a way to create an event on the device that generates a "Normal" event, you could use that as a mechanism to change the SNMP status on Xymon. (Example, if saving the configuration generates a "Normal" SNMP trap....) Ugly, but it'd work.
The other way to address it would be to come up with a way to manually acknowledge or clear a trap similar to the alert acknowledgment in Xymon. I've never had time to pursue that.
2 - origination of the trap
The only way I can think of addressing this is if each database server can be configured to send SNMP traps on their own. The SNMPTRAPD daemon uses the sending device's hostname and that's what is used to send to Xymon.
Hope this helps, Andy
From: Nicole Beck [mailto:nskyrca at syr.edu] Sent: Friday, October 15, 2010 9:42 AM To: 'xymon at xymon.com' Subject: [xymon] help setting up SNMP traps to Xymon
Hello, I'm running Xymon 4.2.3 on RHEL 5.4 and I'm trying to setup Xymon to receive SNMP traps from our Oracle database servers. We are also running Oracle Enterprise Manager on another server (we call it the "grid") that monitors the Oracle database servers too, but our DBA's want to use Xymon to alert them of Oracle problems instead of the grid server so they don't get alerts from two different places. The DBA's manage OEM(therefore I'm not familiar with it), and have configured it to recieve SNMP traps and send them to Xymon.
I configured the Xymon server to receive traps using the documentation at http://cerebro.victoriacollege.edu/hobbit-trap.html. We do receive traps, but there are two problems:
- The trap status diamond does not change color when it gets a trap or when the trap clears. My understanding is that this is set in the Oracle MIBS that are translated to the /etc/snmp/snmptt.conf.oracle file. I'm not sure how to change the file to get it to give different alerts. If I change the word "NORMAL" in the following line to "SEVERE" the trap status will go red, but will not return to green when the trap clears. Any suggestions on how to fix this?
EVENT oraEM4Alert .1.3.6.1.4.1.111.15.2.0.1 "Status Events" Normal
- The traps status changes for the grid server instead of the database server with the problem. Drilling down into the "trap" status, you will see an error for the database server though. The snmptrapd.log and snmptt.log files (examples below) show the traps coming from the grid server. Does anyone know how to get the traps to appear under the database server name rather than the grid server?
Example snmptrapd.log entry (host name changed): 2010-10-14 19:04:49 grid-server [xxx.xxx.xxx.xxx] (via UDP: [xxx.xxx.xxx.xxx]:51617) TRAP, SNMP v1, community public .1.3.6.1.4.1.111.15.2 Enterprise Specific Trap (1) Uptime: 0:06:31.00 .1.3.6.1.4.1.111.15.1.1.1.2.1 = STRING: "DB00157.world" .1.3.6.1.4.1.111.15.1.1.1.3.1 = STRING: "Database Instance" .1.3.6.1.4.1.111.15.1.1.1.4.1 = STRING: "database-server " .1.3.6.1.4.1.111.15.1.1.1.5.1 = STRING: "Status".1.3.6.1.4.1.111.15.1.1.1.6.1 = "" .1.3.6.1.4.1.111.15.1.1.1.7.1 = "" .1.3.6.1.4.1.111.15.1.1.1.8.1 = STRING: "Oct 14, 2010 7:04:00 PM EDT" .1.3.6.1.4.1.111.15.1.1.1.9.1 = STRING: "Critical" .1.3.6.1.4.1.111.15.1.1.1.10.1 = STRING: "Failed to connect to database instance: ORA-01033: ORACLE initialization or shutdown in progress (DBD ERROR: OCISessionBegin)." .1.3.6.1.4.1.111.15.1.1.1.11.1 = STRING: "Test SNMP database-server DB Down " .1.3.6.1.4.1.111.15.1.1.1.12.1 = STRING: "SYSMAN" .1.3.6.1.4.1.111.15.1.1.1.13.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.14.1 = "" .1.3.6.1.4.1.111.15.1.1.1.15.1 = STRING: "923A730174F36B87E040E6801417642D" .1.3.6.1.4.1.111.15.1.1.1.16.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.17.1 = "" .1.3.6.1.4.1.111.15.1.1.1.18.1 = STRING: "0" .1.3.6.1.4.1.111.15.1.1.1.19.1 = "" .1.3.6.1.4.1.111.15.1.1.1.20.1 = STRING: "1" .1.3.6.1.4.1.111.15.1.1.1.21.1 = STRING: "923A421065A8A060E040E68015173993"
Example snmptt.log entry: Oct 14 19:04:52 xymon-server snmptt[0]: .1.3.6.1.4.1.111.15.2.0.1 SEVERE "Status Events" grid-server - The variables included in the oraEM4Alert trap. DB00157.world Database Instance database-server Status Oct 14, 2010 7:04:00 PM EDT Critical Failed to connect to database instance: ORA-01033: ORACLE initialization or shutdown in progress (DBD ERROR: OCISessionBegin). Test SNMP database-server DB Down SYSMAN 0 923A730174F36B87E040E6801417642D 0 0 1 923A421065A8A060E040E68015173993
Thanks in advance for any help. I'm sorry for the lengthy question.
Nicole Beck
participants (7)
-
Andy.Farrior@victoriacollege.edu
-
everett.vernon@gmail.com
-
henrik@hswn.dk
-
josh@imaginenetworksllc.com
-
nskyrca@syr.edu
-
tlewick@tradebotsystems.com
-
tomg@mcclatchyinteractive.com