September 2005 - Xymon - Xymon mailman web

[hobbit] Hobbit, Net-snmp snmptrap,and HPOV
by nfigaro＠effigie.fr 28 Jul '06

28 Jul '06

There is an option to snmptrap (from net snmp) to send full OIDs, otherwise they are cut. Instead of "snmptrap -v 1", the options should be : "snmptrap -v 1 -Of" Otherwise only the end of the OID is sent. Nicolas Figaro > -----Message d'origine----- > De : David Gore [mailto:David.Gore at mci.com] > Envoyé : lundi 19 septembre 2005 17:11 > À : hobbit at hswn.dk > Objet : Re: [hobbit] Hobbit, Net-snmp snmptrap,and HPOV > > > David Gore wrote: > > Coupe, Mark (ITD) wrote: > > > >> All, > >> > >> I'm trying to push alarms from Hobbit to HPOV. We have a custom > >> script that is invoking Netsnmp's snmptrap. The snmp traps are > >> reaching the HP Node Manager Event Browser correctly. > However, the OV > >> operations trap condition is not recognizing the trap. > The trap is > >> being displayed as "unmatched" in the Message Browser even though > >> there is a condition set up for that specific trap. > >> > >> When we look at the unmatched trap, it appears that the OID is not > >> being recognized and an '0' is inserted, for example instead of > >> .1.3.6.1.4.1.7058.0.XX, we are seeing .0.0.XX. > >> > >> Any guidance would be greatly appreaciated. > >> > >> Thanks, > >> > >> -Mark Coupe > > > > > > I, and perhaps others would be interested in what precisely you are > > doing? Are you pushing all hobbit alarms from the hobbit server to > > HPOV? > > > > Sorry, I am HPOV ignorant, but we are interested in > forwarding all the > > hobbit alarms/alerts as SNMP traps to one of Concord's > products. I am > > not to familiar with Concord's product either. I just know > the powers > > that be would like to have snmp traps from all our monitored hosts. > > > > In otherwords, I am interested in any system or methodology that > > someone > > has setup to forward alarms from the hobbit server to an > SNMP server. > > Any setups out there that someone is willing to share the details? > > > > David > > > > > > To unsubscribe from the hobbit list, send an e-mail to > > hobbit-unsubscribe at hswn.dk > > > > > > Here is Mark's script posted with permission: > > SCRIPT > > #!/bin/bash > > #SVCCODES="disk:100,cpu:200,procs:300,svcs:350,msgs:400,conn:5 > 00,http:60 > 0,ftp:721,ssh:722,ssh1:722,ssh2:722,telnet:723,smtp:725,fping: > 727,mq:729 > ,dns:800,pop2:809,pop-2:809,pop:810,pop3:810,pop-3:810,nntp:81 9,imap:843 > ,imap2:843,imap3:843,imap4:843,mrtg:850,swap:860,memory:870,sy > s:880,err: > 890,test:901" > > #Variables > #$OID - OID to be used without trailing value (.1.3.6.1.4.1.7058)(BB > default) > #$OIDTAIL - ending value of OID particluar to alarm type; > determined by "case" statement #$MACHIP - IP address of > device generating alarm; determined by hobbit #$BBHOSTNAME - > hostname of device generating alarm; determined by the hobbit > bb-hosts file #$BBSVCNUM - service code corresponding to the > service being monitored; determined by hobbit configuration > #$BBCOLORLEVEL - alarm level; determined by hobbit > #$RECOVERED - '0' denotes alarm; '1' denotes recovery #$HPOV > - the IP address of the destination HPOV server #TMPDIR - > directory for location of temporary file necessary for sed of $MACHIP > > ###Start script ### > ### > CHRONO=`date` > OID=.1.3.6.1.4.1.7058 > #Put your own OV server IP address in the next line. > HPOV=xxx.xxx.xxx.xxx TMPDIR=/home/hobbit/server/ext > > > case $BBSVCNUM in > 100) #Disk > OIDTAIL=10 > ;; > 200) #CPU > OIDTAIL=20 > ;; > 300) #Procs > OIDTAIL=30 > ;; > 350) #Svcs > OIDTAIL=40 > ;; > 400) #Msgs > OIDTAIL=50 > ;; > 500) #Conn > OIDTAIL=60 > ;; > 600) #Http > OIDTAIL=70 > ;; > #OIDTAIL=80 (not assigned) > 721) #FTP > OIDTAIL=90 > ;; > 722) #SSH > OIDTAIL=100 > ;; > 723) #Telnet > OIDTAIL=110 > ;; > 725) #SMTP > OIDTAIL=120 > ;; > 727) #Fping > OIDTAIL=130 > ;; > 729) #MQ > OIDTAIL=140 > ;; > 800) #DNS > OIDTAIL=150 > ;; > 809) #POP2 > OIDTAIL=160 > ;; > 810) #POP > OIDTAIL=170 > ;; > 819) #NNTP > OIDTAIL=180 > ;; > 843) #IMAP > OIDTAIL=190 > ;; > 850) #MRTG > OIDTAIL=200 > ;; > 860) #Swap > OIDTAIL=210 > ;; > 870) #Memory > OIDTAIL=220 > ;; > 880) #Sys > OIDTAIL=230 > ;; > 890) #ERR > OIDTAIL=240 > ;; > 901) #Test > OIDTAIL=250 > ;; > esac > > if [[ "$RECOVERED" = "0" ]]; then > if [[ "$BBCOLORLEVEL" = "purple" ]]; then > OIDTAIL=$(($OIDTAIL + 1)) > elif [[ "$BBCOLORLEVEL" = "yellow" ]]; then > OIDTAIL=$(($OIDTAIL + 2)) > elif [[ "$BBCOLORLEVEL" = "red" ]]; then > OIDTAIL=$(($OIDTAIL + 3)) > fi > elif [[ "$RECOVERED" = "1" ]]; then > BBCOLORLEVEL=green > fi > > #Following line: reads Hobbit IP into temporary file > echo $MACHIP > $TMPDIR/tmpfile.txt > > #Following lines: puts Hobbit 12 digit IP format in dotted > decimal and removes any leading zeroes. MACHIP=`sed > 's/$...$$...$$...$$...$/\1.\2.\3.\4/' > $TMPDIR/tmpfile.txt` > echo $MACHIP > $TMPDIR/tmpfile.txt > MACHIP=`sed -e 's/^00//' -e 's/^0//' -e 's/\.000/./' -e > 's/\.00/./' -e 's/\.0/./' -e 's/\.000/./' -e 's/\.00/./' -e > 's/\.0/./' -e 's/\.000/./' -e 's/\.00/./' -e 's/\.0/./' -e > 's/\.\.\./.0.0./' -e 's/\.\./.0./' -e 's/\.$/.0/' $TMPDIR/tmpfile.txt` > > #Following line: removes the temporary file > rm -f $TMPDIR/tmpfile.txt > > #Following line: forwards the error message to HPOV as an > SNMP message `snmptrap -v 1 -c mitcovo $HPOV "$OID" "$MACHIP" > 6 $OIDTAIL ""` > > echo "DATE: $CHRONO" >> /home/hobbit/server/ext/hpov-push.log > echo "snmptrap -v 1 -c public $HPOV "$OID" "$MACHIP" 6 > $OIDTAIL "" " >> /home/hobbit/server/ext/hpov-push.log > > > END SCRIPT > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

5 5

bb-disk_by_fs.sh
by iqbala-hobbit＠qwestip.net 29 Jan '06

29 Jan '06

Hi All Has anyone used bb-disk_by_fs.sh with BB client? I am trying to find out how it will work with HOBBIT? There are few things I am concern about. 1. How will I manage alerts per partition which this script offers? 2. How will the graph work? Thanks for any feedbacks. I guess I could always try it myself on a test system if there is no feedback already. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "It is not the strongest of the species that survives, not the most intelligent, but the one most responsive to change." - Charles Darwin

2 2

[hobbit] NCV handler problem
by matti＠saffron.net 01 Oct '05

01 Oct '05

Matti Klock wrote: > Is there a better way to get the NCV handler to ignore the colon in > http://? I'm running the snapshot from 21 Sep 2005 right now. Never mind, I figured it out. I'm having the same problem as Mario Andre did on 23 Sep. The NCV handler appears to have two bugs. First, it captures data of the form <name>:<string>, as well as of the form <name>:<number>; second, it reads beyond the end of the message sometimes, producing some really bewildering errors in rrd-status.log. This small patch fixed both problems, for what it's worth. Thanks, Matti

2 1

[hobbit] Termination errors in hobbit
by adam.scheblein＠marquette.edu 30 Sep '05

30 Sep '05

The patch has been applied, we will see what happens tonight Thanks, Adam -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Friday, September 30, 2005 10:59 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Termination errors in hobbit On Fri, Sep 30, 2005 at 10:27:09AM -0500, Adam Scheblein wrote: > Here is the gdb output: > #7 0x080500cf in add_count (pname=0x0, head=0x8060838) at > client_config.c:571 > #8 0x0804a42e in unix_disk_report (hostname=0xb7dcb035 > "optim.csd.mu.edu", hinfo=0x80615a0, > fromline=0x0, timestr=0x0, capahdr=0x8058289 "Capacity", > mnthdr=0x8058281 "Mounted", > dfstr=0xb7dcb14e "Filesystem 1024-blocks Used Available > Capacity Mounted on\n/dev/vg02/lvol1_snap") at hobbitd_client.c:308 OK, I think I've got it from this trace. Could you apply the attached patch on top of the snapshot you have, and see if that solves it ? Regards, Henrik

1 0

doubt about sendmail server
by wmp＠sinope.com.br 30 Sep '05

30 Sep '05

Hi all How I can define the default server for send messages (sendmail for example) ?! Regards Waldirio

2 1

noprop tag suppresses too much
by KauffmanT＠nibco.com 30 Sep '05

30 Sep '05

I'm running an old release (4.03RC1, no less!) so this may have been addressed since -- but I don't seem to remember seeing anything on the list about it. What I'm seeing is that this definition for whq-sapxisbx does indeed prevent red from propigating up -- page test-nt-systems <H3><A HREF="notes/TestNTSys.html"><I>Test NT Systems </I></H3> group-compress <H3><I>NT Systems (Testing)</I></H3> 10.8.50.21 whq-intranet-d # http://whq-intranet-d.nibco.com 10.8.10.2 whq-heintzberg1 # dialup NOPROPRED:msgs ftp ssh telnet 10.8.10.30 whq-kauffmant # dialup NOPROPRED:msgs !ftp !ssh !telnet 10.8.60.1 whq-sapxisbx # NOPROPRED:* !ftp !ssh !telnet It also prevents this sub-page from being red, which may also be nice. BUT -- there is NO indication on the summary display page (all non-green), and the 'Test NT Systems' dot on the main page is also green. What I need from the 'noprop' tags is to keep the background from changing based on the host flagged, but I still need to see that there is a problem down in the sub page; I'd like the main page to still be green, but the dot should show red for the 'Test NT Systems'. Is this do-able? (Or done, and I just need to upgrade?) TIA Tom Kauffman

1 0

[hobbit] Channel processing problem with 4.11
by Mark.Deiss＠acs-inc.com 30 Sep '05

30 Sep '05

Banging on it and no core dumps (yet). The hobbitd client channel process appears to resurrect off the parent channel process for the signal 6 faults (SIGABRT). Probably be able to get a core dump faster if re-disable the signals and pound the channel some more. I have narrowed down the fault in the client message to the first line in the df output (how strange). Below is the client side code where only reporting the initial client line and then the [df] block header and the df output. If the HPUX df header line is removed before sending out message, no error on channel. Using the hobbit bb binary for client side transmission. For the tests below, restored back the original hobbitd_channel binary with the standard signal handlers. Playing around with the content of the df header line to try and figure out what is so special about it. Very confusing, guess will go back in and disable the signal handlers and try and force out a core dump. !/bin/sh # #--------------------------------------------------------------------------- -# # HP-UX client for Hobbit # # # # Copyright (C) 2005 Henrik Storner <henrik at hswn.dk> # # # # This program is released under the GNU General Public License (GPL), # # version 2. See the file "COPYING" for details. # # # #--------------------------------------------------------------------------- -# # # $Id: hobbitclient-hpux.sh,v 1.4 2005/07/24 11:32:51 henrik Exp $ MACHINE=`/usr/bin/hostname` # no good - uname reports HP-UX, hobbit code uses hpux, need to ditch the minus sign #BBOSTYPE="`/usr/bin/uname -s | /usr/bin/tr '[A-Z]' '[a-z]'`" BBOSTYPE="hpux" { echo "client $MACHINE.$BBOSTYPE" ##echo "[date]" ##/usr/bin/date echo "[df]" # the default does not work - header and metrics #/usr/bin/df -Pk # the next line works - report filesystem metrics without a header line #/usr/bin/df -Pk | sed -ne '2,$p' # the next line causes error on channel - just printing header line /usr/bin/df -Pk | sed -ne '1p' ##echo "[memory]" ##echo "Total:`./bb-hp-memsz -p`" ##echo "Free:`./bb-hp-memsz -f`" } | ./bb --debug aaa.bbb.ccc.ddd "@" exit The message body that results in a channel error is (grabbing snapshot on client - the server client/tmp/msg.txt keeps catching the content of the server's local check): client csdaj401.hpux [df] Filesystem 1024-blocks Used Available Capacity Mounted on -----Original Message----- From: Henrik Storner [mailto:henrik at hswn.dk] Sent: Friday, September 30, 2005 9:07 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Channel processing problem with 4.11 In <FB13116A8C464943B4A5436A616C95F80530AB1F at rocexu01> "Deiss, Mark" <Mark.Deiss at acs-inc.com> writes: >First environment using Mandrake 9.0 server and Fedora Core 2 client - >client transmissions received and processed properly on server. >Second environment using Fedora Core 3 server and HP-UX 11i client, have >problems with hobbitd_channel on server. >Initial error was: Worker process died with exit code 6, terminating This means that the hobbitd_client program has crashed. There ought to be a core-dump in the ~hobbit/server/tmp/ directory; if you could run it through the procedure described in http://www.hswn.dk/hobbit/help/known-issues.html#bugreport it would make it simpler to find. >I reduced down the size of the HP-UX client message - no longer sending >ps/top/vmstat output; still blowing up. Please send me a copy of the client message. You'll find it in ~hobbit/client/tmp/msg.txt on the HP-UX server. I've had one other report of HP-UX clients causing the hobbitd_client module to crash, so there is probably something special about the client messages from HP-UX based systems that trigger this. >Also, has anyone configured hobbit server to work with a number of HPUX >clients? Looking to handle around 50 HPUX servers and 50 Windows servers >into a single Hobbit server. Shouldn't be a problem. I have about 1500 clients reporting into one Hobbit server (HP-UX, Solaris, Windows, AIX). Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

2 1

bbstatus
by tlp-hobbit＠holme-pedersen.dk 30 Sep '05

30 Sep '05

Running the latest snapshot from today. Found that in the bbstatus if I specify the --only option it complains that no DIR was set and exits error code 256. Adding a --DIR=~hobbithome/data/logs corrects the error. Should the standard DIR not be set using the env file ? BR Thomas

3 4

NCV handler problem
by matti＠saffron.net 30 Sep '05

30 Sep '05

Hello, I have an extension script called "send" that produces output containing "seconds: <foo>", which I pass through the NCV handler to create a graph. This works fine. The problem comes when I add a link to the graph to the end of send's output. It looks similar to <a href="http://$BBDISP/hobbit-cgi/stuff">. The graph appears on the test page, but data stops being collected, and rrd-status.log fills up with errors: 2005-09-30 03:30:42 RRD error creating /var/lib/hobbit/rrd/host/send.rrd: Duplicate DS name: http I tried adding "http:NONE" to NCV_send in hobbitserver.cfg, and I tried replacing the colon in "http://" with %3A. Both actions changed the errors to this: 2005-09-30 03:44:39 RRD error creating /var/lib/hobbit/rrd/host /send.rrd: Duplicate DS name: 127001hobbitcgihobb Is there a better way to get the NCV handler to ignore the colon in http://? I'm running the snapshot from 21 Sep 2005 right now. Thank you! Matti

1 0

Channel processing problem with 4.11
by Mark.Deiss＠acs-inc.com 30 Sep '05

30 Sep '05

Testing in two separate hobbit environments. Both environments are able to process BB-PE traffic. Using Hobbit 4.11 server release and a simple client test file to transmit status to the servers (modified hobbitclient-linux.sh and hobbitclient-hpux.sh). First environment using Mandrake 9.0 server and Fedora Core 2 client - client transmissions received and processed properly on server. Second environment using Fedora Core 3 server and HP-UX 11i client, have problems with hobbitd_channel on server. Initial error was: Worker process died with exit code 6, terminating I reduced down the size of the HP-UX client message - no longer sending ps/top/vmstat output; still blowing up. Commented out some of the signal handler lines and set to ignore some of the signals to drill into problem in the hobbitd_channel.c file. /* sigaction(SIGPIPE, &sa, NULL); */ signal(SIGPIPE, SIG_IGN); /* sigaction(SIGINT, &sa, NULL); */ signal(SIGINT, SIG_IGN); sigaction(SIGTERM, &sa, NULL); /* sigaction(SIGCHLD, &sa, NULL); */ signal(SIGCHLD, SIG_IGN); Rerun, error message is now: Our child has failed and will not talk to us.... Guessing that may have a blocking problem - even though there is only the server and the one client using the channel, increased the sleep value. else if (errno == EAGAIN) { /* * Write would block ... stop for now. * Wait just a little while before continuing, so we * dont do busy-waiting when the worker child is not * accepting more data. */ canwrite = 0; /* usleep(2500); */ usleep(25000) Same error. Any ideas what to look into next? Also, has anyone configured hobbit server to work with a number of HPUX clients? Looking to handle around 50 HPUX servers and 50 Windows servers into a single Hobbit server.

2 1