June 2013 - Xymon - Xymon mailman web

XYMONTMP vs XYMONVAR
by feld＠feld.me 10 Jun '13

10 Jun '13

I've noticed what I believe to be discrepancies between the supplied configs and documentation. I'm currently the xymon port maintainer on FreeBSD, and it has bugged me that the acks, data, and disabled directories never seem to have anything in them, even when we have tons of things acked or disabled. I figured I'd start hunting things down and comparing our configuration to the supplied examples and this is what I have found. Straight out of the tarball -- xymon-4.3.11/xymond/etcfiles/xymonserver.cfg.DIST: # Server specific directories XYMONVAR="@XYMONVAR@" # The xymonvar directory holds all monitoring data XYMONACKDIR="$XYMONVAR/acks" # Acknowledge event info stored here (xymond_alert) XYMONDATADIR="$XYMONVAR/data" # Data files go here (xymond_filestore --data) XYMONDISABLEDDIR="$XYMONVAR/disabled" # Enabled/disabled flags are stored here (xymond_filestore --enadis) XYMONHISTDIR="$XYMONVAR/hist" # History logs are stored here (xymond_history) XYMONHISTLOGS="$XYMONVAR/histlogs" # Historical detail status-loge are stored here (xymond_history) XYMONRAWSTATUSDIR="$XYMONVAR/logs" # Status logs go here (xymond_filestore --status). Not needed by Xymon. I think that may be incorrect here xymon-4.3.11/xymond/etcfiles/tasks.cfg.DIST: # "alert" sends out alerts. [alert] ENVFILE @XYMONHOME@/etc/xymonserver.cfg NEEDS xymond CMD xymond_channel --channel=page --log=$XYMONSERVERLOGS/alert.log xymond_alert --checkpoint-file=$XYMONTMP/alert.chk --checkpoint-interval=600 Why is the xymond_alert checkpoint-file going to XYMONTMP? Isn't it supposed to be going to XYMONACKDIR? Or is that unrelated? Can anyone explain why XYMONACKDIR, XYMONDATADIR, and XYMONDISABLEDDIR are always empty? Thanks!

2 2

how to view xymon variables?
by jlaidman＠rebel-it.com.au 09 Jun '13

09 Jun '13

On 31 May 2013 19:50, deepak deore <deepakdeore2004 at gmail.com> wrote: > So, do you mean to say that these variables which I listed are only > available during alerts ? > Can I echo these variables in any of my custom script? > Yes. > eg. put "echo $BBALPHAMSG > some_file" in my custom script? > Only in an alert script. J

2 3

blank recovered sms alerts on mail
by deepakdeore2004＠gmail.com 09 Jun '13

09 Jun '13

Bill, thanks a lot for the code. I made few changes in this code as per my requirement and mail command was not working with this. Also Recovered BBCOLORLEVEL was always red. So made that change as well. Here is my script here if anyone else needs this. ---------------------------------------------------------------------------------------------------------- #!/bin/bash TO="$RCPT" NOTICE=`echo "$BBALPHAMSG" | grep " INFO"` if [ ! -z "$NOTICE" ]; then EVENT=`echo "$BBALPHAMSG" | grep "Monitoring of"` REASON=`echo "$BBALPHAMSG" | grep "Reason:" | cut -d':' -f2-` if [ -z "$REASON" ]; then MSG="$EVENT" else MSG="$EVENT:$REASON" fi else if [ "$RECOVERED" = "1" ]; then RECOVERED=" (Recovered)" BBCOLORLEVEL="green" else RECOVERED="" fi UPSVCNAME=`echo $BBSVCNAME | tr [:lower:] [:upper:]` MSG="$RECOVERED ($BBCOLORLEVEL) $UPSVCNAME on $BBHOSTNAME:\n Problem for $DOWNSECS seconds" fi EMAIL="$TO\n\n$MSG" echo -e "$EMAIL" | /usr/bin/mail -t ---------------------------------------------------------------------------------------------------------- On Sat, May 25, 2013 at 9:17 PM, Bill Arlofski <waa-hobbitml at revpol.com>wrote: > On 05/25/13 06:46, deepak deore wrote: > > FORMAT=PLAIN is working, I am receiving the recovered messages on my > mobile. > > But that message is way long since it is not in sms format. > > > > could you tell where should i look? > > deepak, I think I may have run into a similar issue a long time ago, or > maybe > my issue was that I didn't like the level, or type of detail in the SMS > format > (i forget now), so I wrote a script to take the PLAIN format and TXT it to > me > via the AT&T email-to-SMS gateway. The benefit of this is that you have > complete control to manipulate the format and contents of the SMS that > gets sent. > > > Here's what I did: > > > First, in alerts.cfg > > # Define recipient variables > # -------------------------- > $waaphone=########## > > # Define scripts > # -------------- > $xymon-email-alert=/usr/local/sbin/xymon-email-alert.sh > $xymon-sms-alert=/usr/local/sbin/xymon-SMS-alert.sh > > # Define Times > # ------------ > $ninetofive=W:0900:1700 > $afterhours=W:1701:0859 > $weekends=60:0000:2359 > $smsalerthours=W:0730:2359,60:0900:2200 > $never=365d > > # Define Alerts > # ------------- > # Match ALL FIREWALLS > # ------------------- > PAGE=revpol/client_firewalls > SCRIPT $xymon-sms-alert $waaphone TIME=$smsalerthours DURATION>5m / > FORMAT=SMS REPEAT=$neverCOLOR=yellow,red RECOVERED > > > > Then my SMS alert script (/usr/local/sbin/xymon-SMS-alert.sh) follows. It > could probably use some improvement, been a while since I worked with it. > :) > (this may wrap poorly in email) > > --[snip]-- > #!/bin/bash > # > # waa - 20100209 > # --------------- > date=`date +%Y%m%d-%H:%M:%S` > log="/tmp/xymon-SMS.log" > FROM="From: RP Xymon <someone at example.com>" > TO="To: $RCPT" > > # First, determine if this is a NOTICE message > # (eg: disabling or enabling a test) > # -------------------------------------------- > NOTICE=`echo "$BBALPHAMSG" | grep " INFO"` > if [ ! -z "$NOTICE" ]; then > > # This is an INFO type report, so get the event > # (what was enabled/disabled) and the reason > # --------------------------------------------- > EVENT=`echo "$BBALPHAMSG" | grep "Monitoring of"` > REASON=`echo "$BBALPHAMSG" | grep "Reason:" | cut -d':' -f2-` > if [ -z "$REASON" ]; then > MSG="$EVENT" > else > MSG="$EVENT:$REASON" > fi > > else > # This was not an INFO type report so create > # and format the normal SMS message > # ------------------------------------------ > > # Determine if this is a recovery notice for a test > # ------------------------------------------------- > if [ "$RECOVERED" = "1" ]; then > RECOVERED=" (Recovered)" > else > RECOVERED="" > fi > > # Uppercase the service name > # -------------------------- > UPSVCNAME=`echo $BBSVCNAME | tr [:lower:] [:upper:]` > > # Set the message text > # -------------------- > MSG="$RECOVERED ($BBCOLORLEVEL) $UPSVCNAME on $BBHOSTNAME\nDown for > $DOWNSECS seconds" > fi > > EMAIL="$FROM\n$TO\n\n$MSG" > > # Send the email to the email-to-SMS gateway > # ------------------------------------------ > echo -e "$EMAIL" | /usr/sbin/sendmail -t > --[snip]-- > > > Hope this helps. > > -- > Bill Arlofski > Reverse Polarity, LLC > http://www.revpol.com/ > --not responsible for anything below this line-- > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

1 0

devmon Nortel/Avaya template
by feld＠feld.me 08 Jun '13

08 Jun '13

Attached is something I whipped up while visiting a friend. It should work on more than just an Avaya 4500 -- the entire Nortel Baystack line should work as well as they're nearly identical devices. I'm sure it could use a little refinement, but it reports the important data. I didn't get a chance to investigate further about why some of the graphs don't work or add a few other features like Fan reporting, but the most important information is there! Hopefully someone can get some use out of this.

1 0

devmon/xymon wishlist or feature requests
by tlewick＠apsaranetworks.com 08 Jun '13

08 Jun '13

Cross posting to both the devmon and xymon mail lists. The following features for devmon, would in my opinion, greatly extend/enhance the snmp monitoring capabilities of devmon/xymon. 1. Devmon should be able to poll different devices on different intervals. Having a global poll cycle is too limiting. For example, there may be a piece of critical SNMP data that you need to query on a device, but its limited to only one or two MIB objects. For SLA or other reporting purposes, you may need to poll every 10 seconds or 5 seconds. But for most other devices, or devices with large MIBs (Network switch) every 5 minutes might be sufficient. Such a setup would allow you to aggressively poll the devices you need to, while not causing SNMP responses to exceed the poll time on the other devices. We run into this issue now while trying to poll key devices, if we tighten the polling cycle, we start to get timeouts on our "larger" devices, as the latency over the VPN connection is a bit high. If this is something devmon supports, I am not aware of it, and I've used both single node and multimode (database based) versions. 2. Devmon should easily support logging any/all retrieved SNMP data to a database. I setup the multinode installation and saw the test_data table in mysql, and was excited as I thought the data would be logged there. Turns out no, and then after some researching looks like a method was started to be able to use it, i.e. dbtable. I downloaded the code from sourceforge, but was unable to get it to work. I think better integration or documentation of this feature would be very nice. Here the justification should be obvious, sometimes the RRD graphs aren't sufficient for the granularity they provide, and having access to your SNMP data in a sql database can be very valuable/insightful. Again, if anyone knows how to do this, I'd love to find out more about how to implement it. Xymon Feature/bugfix requests: (I'm running 4.3.8, so if the following features are available in a later version, great). 1. After a reboot of the xymon server, any of the disabled devices, always come back enabled. These should persist past a reboot. A reboot shouldn't invalidate the fact that I've knowingly disabled a device, or if it does, there should be an option to allow you to select disabled devices persist after reboot and/or restart. 2. Also, I've noticed a bug with xymon dates, currently if I disable an alert and I select say 6 months out, it marks the times as something nonsensical. For instance, I currently disabled a few hosts and chose disable until November 1, 2013, and they are saying disabled until Sat Jun 14, 14:13:44 1902. At some random time, usually a few days to a few weeks later, they re-enable themselves, which is annoying. I just read the 4.3.9 through 4.3.11 release notes, and the 4.3.9 release notes state "Fix error in disable-until-TIME or disable-until-OK code" Does this fix address the same bug I just described? 3. Would like to request a disable/reenable all alerts via one button on the enable/disable screen. It should be smart enough so that if you already have some hosts disabled, then upon re-enabling the alerts those hosts still have their disable settings applied. We have some devices we monitor which degrade in poor weather, and when a big storm comes through it would be nice to just click one button and halt alerting.

4 4

ifconfig request
by traxler＠lsu.edu 07 Jun '13

07 Jun '13

When the clients collects data to send the server, one of the commands issues is ifconfig. Where can I go to edit this so that the ifconfig becomes "ifconfig 2>/dev/null"? It turns out that systems with network interfaces that have mac addresses larger than 8 bytes cause ifconfig to print the following message to standard error: Ifconfig uses the ioctl access method to get the full address information, which limits hardware addresses to 8 bytes. Because Infiniband address has 20 bytes, only the first 8 bytes are displayed correctly. Ifconfig is obsolete! For replacement check ip. So, if I can edit the command list so that standard error is sent to /dev/null, my xymonclientlog will not fill up. -- Isaac Traxler AIX,Linux Admin Louisiana State University, LONI traxler at lsu.edu High Performance Computing 225-578-1923 Storage & Infrastructure

2 1

tcp traceroute
by betsy.schwartz＠gmail.com 07 Jun '13

07 Jun '13

One thing you could do is loop down the board with bbhostgrep looking for http* when you find an httptest, query the board for status on http and conn which looks something like $BB $BBDISP "xymondboard host=$host test=http* fields=color"` then if http is not green,see if conn is green then call your custom traceroute test. you'll have to have an else clause that puts a status into your test so it doesn't go purple. OR you could just call it for every host with http and do the right thing when conn is down. Might be useful to gather metrics that way too.

2 1

Fun with xymon - xynagios and xymondboard
by betsy.schwartz＠gmail.com 07 Jun '13

07 Jun '13

I installed xynagios, which allows dropin execution of nagios plugins in xymon (and a variant xynagios.yellow ) Since there are a lot of useful nagios plugins out there, this represents a huge increase in tests we can use off-the-shelf. Using nagios plugins has an interesting ‘gotcha’. Nagios is event driven ; if it receives an alert, that alert stays unchanged until either a human clears it or a new alert arrives. Xymon however is poll-driven; it expects alert statuses at regular intervals and turns an alert purple if no updates occur within the lifetime (set clientside by the “status” variable in the returned line). As xynagios is run regularly, it does the right thing to update single alerts. But what happens if a Nagios test sends more than one sort of alert? I installed the check_hp_bladechassis plugin, which uses snmp. It sends an “hp_bladechassis” alert when snmp is up but an “snmp” alert when snmp fails. So how to keep these from going stale? What I did was use the ‘xymondboard’ feature to query board status (perl code below) If snmp has not logged recently, we know it must no longer be yellow (since xynagios would have sent a fresh yellow) so set it to green If snmp is yellow, we know the hp_bladechassis data is stale, so set it to clear. my $boardinfo = `$BB $BBDISP "xymondboard host=$blade test=snmp fields=color,logtime"`; ( $color, $logtime ) = split( '\|', $boardinfo ); if ( ( $epoch - $logtime ) > $STALE ) { $bbcmd = "$BB $BBDISP 'status+2h $blade.snmp green $date SNMP now OK on $blade'"; system($bbcmd); } if ( $color eq "yellow" ) { $bbcmd = "$BB $BBDISP 'status+2h $blade.hp_bladechassis clear $date SNMP error unable to run HP test on $blade'"; system($bbcmd); } }

1 0

Xymon 4.3.11 released
by Bernd.Frick＠t-systems.com 07 Jun '13

07 Jun '13

Hello Henrik, to evaluate a replacement for the discontinued "Big Brother Professional Edition" I installed Xymon 4.3.11 on a Solaris 10 SPARC and experienced the same as Matt Goebel did in April: a crashing xymongen. In this thread you announced to fix this with release 4.3.12. Do you already have a ETA for this release? Is there a workaround for this issue (apart from compiling release 4.3.10 and using the older binary)? Thank you. Kind regards Bernd Frick T-Systems DDM GmbH Archive Applications Bernd Frick Josef-Eggler-Straße 8, 88250 Weingarten +49 751 5695-318 (Tel.) E-Mail: bernd.frick at t-systems.com<mailto:hans.mustermann at t-systems.com> Internet: http://www.t-systems.de<http://www.t-systems.de/> Geschäftsführer: Peter Dehm Josef-Bayer-Str. 5, 88250 Weingarten, Deutschland Sitz der Gesellschaft Weingarten Amtsgericht Ulm HRB 552722 WEE-Reg.Nr.DE176062543 Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

1 0

tcp traceroute
by troy＠athabascau.ca 06 Jun '13

06 Jun '13

Let's say an HTTP test fails but the conn test for the same host still works . What I want to do at that point, is a tcptraceroute. I need to know where TCP/80 is getting stuck. / Troy ----- Original Message ----- From: cleaver at terabithia.org To: "Troy Adams" <troy at athabascau.ca>, me at tdiehl.org Cc: "Xymon Email List" <xymon at xymon.com> Sent: Thursday, May 30, 2013 4:06:11 PM GMT -07:00 US/Canada Mountain Subject: Re: [Xymon] tcp traceroute > On Thu, 30 May 2013, Troy Adams wrote: > >> In the same way that the conn test can be asked to "trace" by performing >> a >> traceroute upon failure, I would like to perform a TCP traceroute when a >> TCP test fails with "no route to host". I expect this isn't built right >> into Xymon now but has anybody got any pointers on what to hack to >> implement this myself? > > Magic built in not tacked on later!! > > From the hosts.cfg man page: > > trace > If the connectivity test fails, run a "traceroute" and include the > output > from this in the status message from the failed connectivity test. > Note: > For this to work, you may have to define the TRACEROUTE environment > variable, see xymonserver.cfg(5) > > Is that what you are looking for? > > -- "trace" in hosts.cfg and a suitable entry in xymonserver.cfg should be all you need. (You can also just add --trace to the xymonnet options in tasks.cfg.) Since you're running as the 'xymon' user (presumably), don't forget privilege escalation for traceroute in TCP mode. tasks.cfg: CMD xymonnet --report --ping --trace --checkresponse xymonserver.cfg:TRACEROUTE="sudo /bin/traceroute -I" HTH, -jc -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. ---

1 0