December 2005 - Xymon - Xymon mailman web

Email alert based on specific process
by iqbala-hobbit＠qwestip.net 15 Nov '06

15 Nov '06

Hi All I am using bb-proctab to monitor a list of processes and if any process a whole group get alert. Is there a way I can setup the alert with process specific. So if proc 1 out the list dies only user 1 get alert and so on. I know I could use the SCRIPT feature but like to keep that as the last resort. I am using hobbit 4.1.2 on Solaris 8. The process list I am concern about is running bb1.9c client on Solaris 8 as well. Sorry if it were already discussed in the mailing list. Thanks -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi

6 7

Small enhancement to Hobbit JavaScript menu
by frederic.mangeant＠steria.com 05 Oct '06

05 Oct '06

Hi Henrik I didn't find bb-datepage.sh the first time I set up Hobbit, maybe this small modification to ~/server/www/menu/menu_items.js would be helpful : --- menu_items.js.orig 2005-11-18 15:46:58.000000000 +0100 +++ menu_items.js 2005-11-18 15:53:50.000000000 +0100 @@ -6,7 +6,12 @@ ], ['Reports', null, null, ['Event log Report', '/hobbit-cgi/bb-eventlog.sh'], - ['Availability Report', '/hobbit-cgi/bb-rep.sh'], + ['Availability Reports', null, null, + ['Daily Report', '/hobbit-cgi/bb-datepage.sh?type=day'], + ['Weekly Report', '/hobbit-cgi/bb-datepage.sh?type=week'], + ['Monthly Report', '/hobbit-cgi/bb-datepage.sh?type=month'], + ['Custom Report', '/hobbit-cgi/bb-rep.sh'], + ], ['Snapshot Report', '/hobbit-cgi/bb-snapshot.sh'], ['Config Report', '/hobbit-cgi/hobbit-confreport.sh'], ], Regards, -- Frédéric Mangeant Steria EDC Sophia-Antipolis

3 2

[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

stop receiving notice alerts
by iqbala-hobbit＠qwestip.net 01 Jun '06

01 Jun '06

Hi All I just realized that we are not receiving NOTICE alerts anymore when disable or enable host.service through the web. tail -10 /var/log/hobbit/enadis.log. I have always seen them but not showing the host whose service I disabled and then enabled. 2005-11-30 07:52:15 Could not remove disable-file '/export/home/hobbit/data/disabled/maskit,inet,here,net.scanmsg':No such file or directory 2005-11-30 07:52:15 Could not remove disable-file '/export/home/hobbit/data/disabled/maskit,inet,here,net.top':No such file or directory 2005-11-30 07:52:15 Could not remove disable-file '/export/home/hobbit/data/disabled/maskit,inet,here,net.netinfo':No such file or directory Also not receiving any email related to NOTICE. ./bin/bbcmd hobbitd_alert --dump-config [..] HOST=%(.*) MAIL groupemail at here.net FORMAT=TEXT REPEAT=30 NOTICE NOALERT Version: ./bin/bbgen --version bbgen version 4.1.2 I do not think I made any recent changes. Thanks -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi

2 4

Downsecs wrong?
by patrick_a_vaughan＠hotmail.com 01 Jun '06

01 Jun '06

I've just noticed that the $DOWNSECS variable seems to be wrong. I've seen lots of times that it's 0. I found one time today where the history page says the duration was 1:49:57, but $DOWNSECS in the recovery message was set to 48. I don't know when this started, but I've got odd recovery times going back a couple of weeks.

2 1

RECOVERED alerts still sent outside of TIME window
by EES2Y＠hscmail.mcc.virginia.edu 29 May '06

29 May '06

Howdy all, We just had one of our engineers get a rude awakening last night by a UPS that had recovered from an error; I had thought that the RECOVERED pages were under the same TIME restrictions as normal alerts, but a quick look at the code leads me to believe that this is not so. Before I (or somebody else ;) attempts a fix, I wanted to make sure that there wasn't a valid reason behind this implementation. (I'm looking at the criteria match routine in the do_alerts.c file, specifically lines 899 through 914). TIA, -Eric Schwimmer Network Engineer UVA HSCS Network Engineering

2 1

OpenLDAP performance and replication monitoring with Hobbit
by bgmilne＠staff.telkomsa.net 09 May '06

09 May '06

We run a number of OpenLDAP servers, currently we have about 11 in production (depending how you count clusters) and a few in DR sites etc. We have been doing performance monitoring in the past (ie running scripts via snmp, monitoring with mrtg), but it seemed logical to move it to Hobbit and do everything in one place (useful for the syncrepl monitoring below). We have two separate instances that we manage, only one currently uses Hobbit for production monitoring (the other installation has hobbit installed, which is publicly accessible at present, but isn't used for production monitoring). The instance with the publicly accessible installation has OpenLDAP 2.1 and 2.2 servers, the other one has OpenLDAP 2.3 servers (using sync replication). So, I have written an extension script using perl-ldap (and Date::Manip) which we are now using via Hobbit's ncv module for performance monitoring. Replication status of sync-repl slaves is also checked (green for in sync, yellow for out of sync, clear if the sync-repl master could not be contacted to check the contextCSN, green if it is not a sync-repl slave). The script is available here: http://www.zarb.org/~bgmilne/bb-openldap.pl An extract from hobbitgraph.cfg is available here: http://www.zarb.org/~bgmilne/hobbitgraph-ol.cfg Some examples: http://196.25.211.20/hobbit/ldap/ldap.html Slave running OpenLDAP 2.2.x: http://196.25.211.20/hobbit-cgi/bb-hostsvc.sh?HOSTSVC=io.ol Master cluster running OpenLDAP 2.1.x: http://196.25.211.20/hobbit-cgi/bb-hostsvc.sh?HOSTSVC=metis.ol The only problem is with the parsing in ncv when a slave is out of sync. For slaves using sync-repl (no examples publicly available for now), the "&green Not a syncrepl slave" can be something like: &yellow dc=mydomain,dc=com out of sync 4 weeks 4 days 15:5:11 behind or &green dc=mydomain,dc=com in sync (with one such line for each syncrepl database, we have two or more on our production OL 2.3 boxen) Now, I could s/:/;/g or similar, but it would be nice if there were a way to prevent ncv from parsing a line (since I would also like to be able to graph the CIM extension results with ncv, but it has output and &green/&yellow/&red's all over). Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

2 1

hobbitclient on solaris: using iostat for cpu stat
by grossi＠acantho.net 09 May '06

09 May '06

Hi Henrik, I have seen that hobbit clients collects cpu stats via vmstat, now i think that the cpu information provided by "iostat -c" is more accurate, because it has the "%waiting for i/o" columns, wich is also in the linux version of vmstat. do you think you can add this information? -- Gianluca

2 1

Disk RRD problem with hobbit-client and OSF1 (Tru64)
by astavitsky＠yahoo.com 04 May '06

04 May '06

Hi! I'm using hobbit 4.1.2 server and clients. Some of my OSF1 (Tru64 4.0&5.1) clients' filesystems are being captured in RRD by mountpoint name and others by the device/domain. These are RRD files for a particular host:: ls -l HOSTNAME/disk* -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,arc.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,nfs,BOSS.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,nfs.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-26 20:13 HOSTNAME/disk,report.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,root_domain#root.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,rpt,MakPrd,progesaPrd,Act,CWNY.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,rpt,MakPrd,progesaPrd,Act,LongIsland.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,rpt,MakPrd,progesaPrd,Act,NewJersey.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,rpt,MakPrd,progesaPrd,Act.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,rpt.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,tmp_domain#tmp.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,usr_domain#usr.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,var,ase,mnt,asearc,arc.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,var,ase,mnt,asenfs,nfs.rrd -rw-r--r-- 1 hobbit hobbit 38532 2005-10-30 13:04 HOSTNAME/disk,var_domain#var.rrd And here is the hobbitlog for this: HOSTNAME|disk|green||1130372298|1130621525|1130623325|0|0|172.16.52.21|-1|||Y green Sat Oct 29 17:31:58 EDT 2005 - Filesystems OK Filesystem 512-blocks Used Available Capacity Mounted on root_domain#root 409600 252902 128032 67% / usr_domain#usr 2516576 1825636 638672 75% /usr var_domain#var 9437184 4114720 5284080 44% /var tmp_domain#tmp 409600 2682 385376 1% /tmp /nfs at asenfs 88821680 37803820 50792192 43% /nfs /arc at asearc 106643104 69304154 37257648 66% /arc nfs_dmn#nfs 88821680 37803820 50792192 43% /var/ase/mnt/asenfs/nfs arc_dmn#arc 106643104 69304154 37257648 66% /var/ase/mnt/asearc/arc /NFS at CEBOSS 377479160 298515328 78963832 80% /nfs/BOSS rpt_dmn#progesa 106643104 61776456 44815856 58% /rpt rptact_dmn#act 106643104 75460796 31101280 71% /rpt/MakPrd/progesaPrd/Act rptcwny_dmn#cwny 106643104 28278562 78320496 27% /rpt/MakPrd/progesaPrd/Act/CWNY rptli_dmn#li 71095392 19095496 51949920 27% /rpt/MakPrd/progesaPrd/Act/LongIsland rptnj_dmn#nj 71095392 3627144 67417760 6% /rpt/MakPrd/progesaPrd/Act/NewJersey I read earlier messages about hobbit_larrd misdetecting NT/UNIX disk output, but in this case it uses different columns for different filesystems on the SAME host. I'm at a loss why this is happening and how to fix it. Thanks,

4 4

[hobbit] Dumb hobbit network test question
by frederic.mangeant＠steria.com 30 Jan '06

30 Jan '06

Hi Tom > -----Original Message----- > From: Kauffman, Tom [mailto:KauffmanT at nibco.com] > Sent: Tuesday, November 29, 2005 11:28 AM > To: hobbit at hswn.dk > Subject: [hobbit] Dumb hobbit network test question [snip] > Here's a sample of the network test error: > Service ftp on hudson is not OK : Unexpected service response > Service smtp on hudson is not OK : Unexpected service response Are you using the "--checkresponse" option ? I had the same "Unexpected service response" warnings until I removed it. http://www.hswn.dk/hobbit/help/manpages/man1/bbtest-net.1.html --checkresponse[=COLOR] When testing well-known services (e.g. FTP, SSH, SMTP, POP-2, POP- 3, IMAP, NNTP and rsync), bbtest-net will look for a valid service- specific "OK" response. If another reponse is seen, this will cause the test to report a warning (yellow) status. Without this option, the response from the service is ignored. The optional color-name is used to select a color other than yellow for the status message when the response is wrong. E.g. "-- checkresponse=red" will cause a "red" status message to be sent when the service does not respond as expected.

2 1