July 2006 - Xymon - Xymon mailman web

[hobbit] How to totally disable alerts for a particular host?
by brodie＠mcw.edu 13 Jul '06

13 Jul '06

In truth, I think my issue is I'm not completely understanding the "perl compatable" regular expressions. Can someone perhaps include some examples? I am finding that some of my attempts below are actually causing ALL alerts to simply cease-- with nothing in the log files to indicate I have an issue!!! -----Original Message----- From: Brodie, Kent [mailto:brodie at mcw.edu] Sent: Wednesday, July 12, 2006 10:20 PM To: hobbit at hswn.dk Subject: [hobbit] How to totally disable alerts for a particular host? I'm not sure I understand the docs here... is something like this correct? # These rules eliminate printers from warnings/alerts ##HOST=%^pr*.hmgc.mcw.edu ## IGNORE HOST=lp4.phys.mcw.edu IGNORE ##HOST=%^hp* ## IGNORE # Misc hosts we do not want alerts on ##HOST=mac1.hmgc.mcw.edu ## IGNORE ##HOST=canadeo-disk.brc.mcw.edu ## IGNORE ##HOST=sharpe.phys.mcw.edu ## IGNORE HOST=bc1s7.phys.mcw.edu IGNORE # # Now on to our regular monitoring rules for things we DO want alerts on # HOST=uram.hmgc.mcw.edu MAIL brodie at phys.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT MAIL kent.brodie at pager.mcw.edu REPEAT=30 RECOVERED FORMAT=SMS ##SERVICE=disk ## MAIL brodie at phys.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT HOST=loki.phys.mcw.edu SERVICE=disk MAIL brodie at phys.mcw.edu REPEAT=60 RECOVERED FORMAT=TEXT SERVICE=conn MAIL sysadmins REPEAT=30 RECOVERED FORMAT=TEXT MAIL pagers REPEAT=30 RECOVERED FORMAT=SMS SERVICE=oracle MAIL szacher at hmgc.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT MAIL sysadmins REPEAT=30 RECOVERED FORMAT=TEXT MAIL kent.brodie at pager.mcw.edu REPEAT=30 RECOVERED FORMAT=SMS [hobbit at coffman etc]$ To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

2 1

How to totally disable alerts for a particular host?
by brodie＠mcw.edu 13 Jul '06

13 Jul '06

I'm not sure I understand the docs here... is something like this correct? # These rules eliminate printers from warnings/alerts ##HOST=%^pr*.hmgc.mcw.edu ## IGNORE HOST=lp4.phys.mcw.edu IGNORE ##HOST=%^hp* ## IGNORE # Misc hosts we do not want alerts on ##HOST=mac1.hmgc.mcw.edu ## IGNORE ##HOST=canadeo-disk.brc.mcw.edu ## IGNORE ##HOST=sharpe.phys.mcw.edu ## IGNORE HOST=bc1s7.phys.mcw.edu IGNORE # # Now on to our regular monitoring rules for things we DO want alerts on # HOST=uram.hmgc.mcw.edu MAIL brodie at phys.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT MAIL kent.brodie at pager.mcw.edu REPEAT=30 RECOVERED FORMAT=SMS ##SERVICE=disk ## MAIL brodie at phys.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT HOST=loki.phys.mcw.edu SERVICE=disk MAIL brodie at phys.mcw.edu REPEAT=60 RECOVERED FORMAT=TEXT SERVICE=conn MAIL sysadmins REPEAT=30 RECOVERED FORMAT=TEXT MAIL pagers REPEAT=30 RECOVERED FORMAT=SMS SERVICE=oracle MAIL szacher at hmgc.mcw.edu REPEAT=30 RECOVERED FORMAT=TEXT MAIL sysadmins REPEAT=30 RECOVERED FORMAT=TEXT MAIL kent.brodie at pager.mcw.edu REPEAT=30 RECOVERED FORMAT=SMS [hobbit at coffman etc]$

2 1

msgs test switching between white and green
by stephane.caminade＠ias.u-psud.fr 12 Jul '06

12 Jul '06

Hi, I ve got a surprising thing happening with the msgs test on a server on which I want to monitor mail logs for deferred and several kind of related errors : Wed Jul 12 13:33:21 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 13:32:50 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 13:28:20 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 13:27:49 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 13:23:19 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 13:22:48 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 13:18:18 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 13:17:48 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 13:13:17 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 13:12:47 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear [...] Wed Jul 12 10:47:27 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 10:42:44 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 10:42:26 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 10:37:43 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 10:37:25 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 10:32:42 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 10:32:24 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear Wed Jul 12 10:27:40 2006 inf-mail2.ias.u-psud.fr msgs clear From -> To green Wed Jul 12 10:27:24 2006 inf-mail2.ias.u-psud.fr msgs green From -> To clear In client-local.cfg, I have : [inf-mail2.ias.u-psud.fr] log:/var/log/maillog:20480 ignore spamd trigger deferred In hobbit-clients.cfg, the part referring to the mail log is : HOST=inf-mail2.ias.u-psud.fr LOG /var/log/maillog %.*deferred COLOR=red Is something wrong with my setup ? How come the msgs column keeps switching ? Regards, Stephane -- _____________________________________________________________________________ Stephane Caminade Administrateur Systèmes et Réseaux \ <Stephane.Caminade at ias.u-psud.fr> Institut d'Astrophysique Spatiale / tel : (33) (1) 69 85 87 03 Batiment 121, Universite Paris XI \ fax : (33) (1) 69 85 86 75 F-91405 ORSAY Cedex / www : http://www.ias.u-psud.fr/ _____________________________________________________________________________

2 1

Unwanted delay in hobbit alerts
by bernie9998＠gmail.com 12 Jul '06

12 Jul '06

It seems that hobbitd_alert for whatever reason, is sending alerts only once every half hour. In other words, if I was to test an alert as such: bbcmd hobbitd_alert --test [hostname] [test] It will immediately output that it found a matching rule, and states the action being taken (mail -s etc. . .), however, the notification will not come up in the notifications.log or in the mail server logs until either :06 or :36 past the hour. Also, the output of the resulting messages in the alerts are time stamped just before the message is sent/received as opposed to when the command was first called to run the test. I have not tested to see if this happens when a machine actually goes down (the test in question for this particular alert), just with the test option in hobbitd_alert (actually, the host I've chosen for the test was already down). The alert rule in question is rather simple: HOST=* SERVICE=conn MAIL [user](a)[server].[tld] RECOVERED Any help in this would be greatly appreciated. -Brian

2 1

bug report? bb-network tests do not run if bb-hosts' apache tag has a typo
by tomg＠mcclatchyinteractive.com 12 Jul '06

12 Jul '06

Last night I made a typo in the apache performance test tag, forgetting to add '//' after 'http:'. This little typo prevented hobbit from running any of the network based tests, and the tests remained purple until I corrected the error. My log/bb-network.log file was full of lines like this: 2006-07-11 16:25:54 Malformed URL missing '//' in 'http:webserver:80/server-status?auto' Is that expected behavior for this kind of user error? It would be cool if Hobbit were able to handle that kind of oversight better, and simply drop that typo-ridden test or even all the network tests for that host, but still run everything else. Just wanted to pass this thought along. (BTW, this was on 4.1.2p1) Tom

2 1

[hobbit] PORTs help?
by brodie＠mcw.edu 12 Jul '06

12 Jul '06

Hmm! Based on the server and how I know it's used, there really shouldn't be 900+ close-Wait processes out there.... :-) --------------------------------------------------------- Kent C. Brodie - brodie at phys.mcw.edu Department of Physiology Medical College of Wisconsin (414) 456-8590 -----Original Message----- From: Sean Hennessey [mailto:sean.hennessey1 at verizonbusiness.com] Sent: Wednesday, July 12, 2006 8:54 AM To: hobbit at hswn.dk Subject: RE: [hobbit] PORTs help? Kent, I just wanted to point out that close_wait is a normal state for tcp connections to be in. It is part of a passive close process. You can refer to 18.5 of TCP/IP Illustrated Volume 1 by W.R. Stevens. To quote: "TCP provides the ability for one end of a connection to terminate its output, while still receiving data from the other end. This is called a half-close. Few applications take advantage of this capability, as we mentinoned earlier." http://support.microsoft.com/kb/137984/ http://everything2.com/index.pl?node_id=1411928 This is an interesting read. Maybe your java apps isn't supposed to be doing passive closing. http://java.sun.com/j2se/1.5.0/docs/guide/net/articles/connection_releas e.ht ml Sean -----Original Message----- From: Brodie, Kent [mailto:brodie at mcw.edu] Sent: Tuesday, July 11, 2006 5:37 PM To: hobbit at hswn.dk Subject: [hobbit] PORTs help? Hi-- I'm wrestling with the PORTS option of a host, trying to watch for a specific issue. While I have successfully matched rule(s) for simple things like SSH port(s) listening, I cannot seem to get a rule to match the following: We have a stupid java server thing that keeps leaving ports in a close_wait state. See example below. What rule would I use for watching for these? I'm trying something along the lines of: HOST=starr.brc.mcw.edu PORT "REMOTE=%*.8085" STATE=CLOSE_WAIT max=20 color=red TRACK=hung TEXT=hung But it never matches. I've tried lots of variations. Any help appreciated!! (goal: If I see more than "N" number of these ports, I want to flag red) Tue Jul 11 16:30:46 CDT 2006 - Ports NOT ok hung (found 0, req. between 1 and 20) <== this is the rule that doesn't work.. ssh (found 7, req. 1 or more) Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- 127.0.0.1.50447 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50447 49152 0 49152 0 ESTABLISHED *.3003 *.* 0 0 49152 0 LISTEN 127.0.0.1.50448 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50448 49152 0 49152 0 ESTABLISHED 127.0.0.1.50449 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50449 49152 0 49152 0 ESTABLISHED 127.0.0.1.50457 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50457 49152 0 49152 0 ESTABLISHED 141.106.224.175.50533 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51260 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.54844 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.55651 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.56483 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.57541 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.58667 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.37218 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.38052 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39008 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39872 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40498 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49005 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49750 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50382 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51211 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52210 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59122 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59721 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.60606 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.61293 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.61992 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.38432 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39131 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39752 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40451 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.41008 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50174 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50782 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51399 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52041 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52717 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.64337 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.64991 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39232 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39877 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40560 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.41289 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.42002 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49473 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50084 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50681 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51227 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51784 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.58596 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59169 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59728 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.60321 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.32820 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.33395 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.33956 141.106.224.175.8085 49152 0 49152 0 To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

PORTs help?
by brodie＠mcw.edu 12 Jul '06

12 Jul '06

Hi-- I'm wrestling with the PORTS option of a host, trying to watch for a specific issue. While I have successfully matched rule(s) for simple things like SSH port(s) listening, I cannot seem to get a rule to match the following: We have a stupid java server thing that keeps leaving ports in a close_wait state. See example below. What rule would I use for watching for these? I'm trying something along the lines of: HOST=starr.brc.mcw.edu PORT "REMOTE=%*.8085" STATE=CLOSE_WAIT max=20 color=red TRACK=hung TEXT=hung But it never matches. I've tried lots of variations. Any help appreciated!! (goal: If I see more than "N" number of these ports, I want to flag red) Tue Jul 11 16:30:46 CDT 2006 - Ports NOT ok hung (found 0, req. between 1 and 20) <== this is the rule that doesn't work.. ssh (found 7, req. 1 or more) Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- 127.0.0.1.50447 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50447 49152 0 49152 0 ESTABLISHED *.3003 *.* 0 0 49152 0 LISTEN 127.0.0.1.50448 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50448 49152 0 49152 0 ESTABLISHED 127.0.0.1.50449 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50449 49152 0 49152 0 ESTABLISHED 127.0.0.1.50457 127.0.0.1.6100 49152 0 49152 0 ESTABLISHED 127.0.0.1.6100 127.0.0.1.50457 49152 0 49152 0 ESTABLISHED 141.106.224.175.50533 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51260 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.54844 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.55651 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.56483 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.57541 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.58667 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.37218 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.38052 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39008 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39872 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40498 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49005 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49750 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50382 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51211 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52210 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59122 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59721 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.60606 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.61293 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.61992 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.38432 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39131 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39752 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40451 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.41008 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50174 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50782 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51399 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52041 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.52717 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.64337 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.64991 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39232 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.39877 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.40560 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.41289 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.42002 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.49473 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50084 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.50681 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51227 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.51784 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.58596 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59169 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.59728 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.60321 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.32820 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.33395 141.106.224.175.8085 49152 0 49152 0 CLOSE_WAIT 141.106.224.175.33956 141.106.224.175.8085 49152 0 49152 0

3 2

RRD graphing not showing up
by pmalenfa＠videotron.ca 12 Jul '06

12 Jul '06

Hello, I'm still on this problem. By testing manually hobbitgraph.sh, I received the following output: Content-type: text/html <html><head><title>Invalid request</title></head> <body>Invalid request - no host or service</body></html> Does someone have an idea where I should look? Here is the other details I already sent. The graphs do not show up on one Hobbit server I installed on AIX. All the other hobbit servers I installed on AIX 5.2 and 5.3 do work fine. I used the same procedure for installing Hobbit (same pre-reqs). All the pages shows up properly but the graphs images are not produced. The server is on AIX 5.3, running 64 bits kernel. I tried many things following what I found in the list but without success. Here is what I tried already: - Tested manually hobbitgraph.sh, with the Apache user (REQUEST_METHOD, REQUEST_URI, etc). It return data. - Recompiled a few times using different options - I saw the list thread about problems on HPUX and 64 bits compilations. So I tried recompiling with my server in 32 bits and same problem - rrd files gets populated and rrdtool dump is working In my apache error log, I have the following: Premature end of script headers: /home/hobbit/cgi-bin/hobbitgraph.sh In my rrd-data.log, I have (I don't think it matters) Internal error: Duplicate match ignored Any ideas? Pierre

1 1

--extra-script stopped working
by P.vanEldijk＠uci.ru.nl 12 Jul '06

12 Jul '06

Hi, I'm using hobbit 4.1.2. I've added an external script to hbbitd_rrd with the --extra-script and --extra-test options. It ran ok for a few days, but then just stopped updating the rrds. Now, even when restarting hobbit the script is not launched anymore. the section in hobbitlaunch.cfg is: [rrdstatus] ENVFILE /data/hobbit/server/etc/hobbitserver.cfg NEEDS hobbitd CMD hobbitd_channel --channel=status --log=$BBSERVERLOGS/rrd-status.log hobbitd_rrd --rrddir=$BBVAR/rrd --extra-script=/data/hobbit/server/scripts/rrd.pl --extra-tests=oradb when running the script by hand it works just fine, so why doesn't it run anymore? The logfile gives no clue. Help! Paul

2 2

Newbie questions
by brodie＠mcw.edu 11 Jul '06

11 Jul '06

First, I want to say-"wow". I have been using BB for the better part of the past 2 years, monitoring 124 hosts. I always expounded upon the virtues of BB. A few weeks ago at USENIX, I was introduced to HOBBIT- and I must admit, I'm both thrilled and impressed. The integrated RRD stuff is well, way too cool for words, and more useful than you can imagine. The "sslcert" deal is also quite cool. I like new toys. Overall, the new environment (compared to BB) is just much cleaner, and more effective. I appreciate all the work put into this. Even though I'm a (former!) BB user, I have a few questions to help me along the way......... 1 - What is the best way to permanently disable a test for a particular host? I can't seem to figure out how to do this in bb-hosts or the hobbit-clients.cfg file. For example, in some operating systems (AIX, for example), the messages (msgs) test will not work due to mucked up permissions of the system messages/log file. In these cases, I'd just rather disable the test all together. When formerly configured with a BB client, the test shows up as disabled. How to do this in HOBBIT? (My goal, "all green"......) 2 - It would be super helpful if people could post samples of the hobbit bb-hosts files here... I am a bit overwhelmed by all of the bbgen/display options, and am a bit confused as to how that all works. Specifically, what I am interested in doing is grouping pages together in different combinations. For example, I have all of my "Sun" systems in one group, all of my "terminal servers" in another group, etc. With the newer page/subpage/etc functionality, I'd like to add multiple groups that may include some of the same systems. For example, in addition to my "Sun", "HP", etc systems pages, I also want pages for "Production Servers", "Development Servers", etc. I am unclear on how to do this without defining host entries multiple times (which, I am assuming you want to avoid!). Examples or whatever explanation can be provided would be super helpful. 3 - Critical systems. I am stumped, I cannot seem to get this to work, despite following the documentation. No matter what I do, all I get is "All Monitored Systems OK", even though I've attempted adding critical records via the GUI. Am I missing something, or is this not quite working in the current beta? 4 - messages/syslog click/download? If I am in the messages screen, I see (for example) the phrase "/var/adm/syslog/syslog.log" highlighted as a clickable link. But, if I click on it, my browser attempts to download the file "bb-hostsvc.sh". Is this a known issue? Just wondering. Thanks for any help people can provide! -kcb --------------------------------------------------------- Kent C. Brodie - brodie at phys.mcw.edu Department of Physiology Medical College of Wisconsin (414) 456-8590

3 4