- Xymon - Xymon mailman web

Hobbit Alerts
by rlapuz＠fcpp.fujitsu.com 25 Jul '07

25 Jul '07

Good day! HOST=* COLOR=yellow,red SERVICE=* EXSERVICE=msgs,cpu,memory REPEAT=5h RECOVERED MAIL myemail at domain.com Referring to the above syntax, it means that i'll be receiving alerts for color red and yellow right? What if the service is already in yellow alert for an hour then I received the email notification, and then it becomes a red alert sooner than the specified REPEAT time, Is it normal that I will no longer receive an email notification for the red alert? Co'z I didn't receive one for the red alert. Thanks! Ryan

2 2

Hobbit Alerts
by rlapuz＠fcpp.fujitsu.com 24 Jul '07

24 Jul '07

Good day! HOST=* COLOR=yellow SERVICE=* EXSERVICE=msgs,cpu,memory REPEAT=5h RECOVERED MAIL myemail at domain.com Referring to the above syntax, it means that i'll be receiving alerts for color red and yellow right? What if the service is already in yellow alert for an hour then I received the email notification, and then it becomes a red alert sooner than the specified REPEAT time, Is it normal that I will no longer receive an email notification for the red alert? Co'z I didn't receive one for the red alert. Thanks! Ryan

1 0

timeline for 4.3.0
by Galen.Johnson＠sas.com 24 Jul '07

24 Jul '07

Hey Henrik, I know there's been a big drive since you announced the highlights for 4.3.0. I also noted that it will not be released until the hobbitfetch works without crashing (patch test pending). Do you have an idea of when you are going to release 4.3.0? Are you planning to do any RC releases prior to full release or just depend on the snapshots? This is mainly curiousity since there are some nice features in 4.3.0 that will be good to have and we tend to only want to use the prod version. That actually brings up the question of running the new version in parallel with the old (obviously this would need to be done on a separate box). Would this be as simple as adding it to the bbdisplay variable? just curious =G=

2 1

vmstat "b" graph
by scott＠PacketPushers.com 24 Jul '07

24 Jul '07

I checked the default vmstat rrd in hobbit, and a DS for "blocked (b)" is being collected. Blocked process indicate IO bound processes. Crude, but pretty effective. I am requesting an additional graph in the trends page specifically for the "b" DS of the vmstat rrd. This DS might not exist for all *IX, but for most. Forgive me if this is configurable, I still picking up the details of hobbit functionality. -bash-2.05b$ rrdtool info vmstat.rrd filename = "vmstat.rrd" rrd_version = "0003" step = 300 last_update = 1185291307 ..snip.. ds[cpu_b].type = "GAUGE" ds[cpu_b].minimal_heartbeat = 600 ds[cpu_b].min = 0.0000000000e+00 ds[cpu_b].max = NaN ds[cpu_b].last_ds = "UNKN" ds[cpu_b].value = 7.0000000000e+00 ds[cpu_b].unknown_sec = 0 Scott

3 3

DISK test: only monitor specific filesystems
by haertig＠avaya.com 24 Jul '07

24 Jul '07

I want to only monitor three specific filesystem on a host, and ignore the rest. I tried this in hobbit-clients.cfg: HOST=wcscbe5 DISK * IGNORE DISK /expsys 90 95 DISK /expert 90 95 DISK /inadsb 90 95 The above didn't list any filesystems in the textual df listing, but showed a single graph line for the root filesystem. The three filesystems I actually wanted were not there. Next I tried: HOST=wcscbe5 DISK /expsys 90 95 DISK /expert 90 95 DISK /inadsb 90 95 The above didn't appear to do anything different from the original default, which was "DISK * 90 95". All filesystems were shown in the textual df listing, and all filesystems were graphed. I did not try IGNORE'ing individual filesystems one-by-one, although my guess is that this might work. But that would get quite messy to maintain with most of the computers I'm monitoring, each having dozens of mounted filesystems (many unique to the specific computer). And new filesystems are added fairly regularly, each new filesystem would require me going back and modifying hobbit-clients.cfg. It would be nice if hobbit-client.cfg could interpret subsequent lines to override previous lines, as I attempted to configure in my first test. Maybe it does do this, and I just missed out on the correct syntax somehow. Any hints on how to do this? Thanks!

4 6

Administration Rights
by jwprkr＠gmail.com 24 Jul '07

24 Jul '07

Hello again, Is there a way to separate enabling/disabling alerts from acknowledging as far as who has the rights to do these things, i.e., authentication when clicking on the option from the drop down Administration menu. Can I have a separate user list for each of these functions? Thanks Jeff -- Jeff Parker jwprkr at gmail dot com

4 3

[hobbit] static declaration of 'sendfile' follows non-static declaration
by Robert-Manocchia＠IDEXX.com 24 Jul '07

24 Jul '07

Thanks but I found the problem. I needed to comment out some lines in one of the header files (osdefs.h) and modify the make file for the platform and point to the location of the gcc compiler. I have it up and running. Thanks again. Robert Manocchia UNIX System Administrator IDEXX Laboratories 207 556-6860 EMail Robert-Manocchia at idexx.com -----Original Message----- From: henrik at hswn.dk [mailto:henrik at hswn.dk] Sent: Tuesday, July 24, 2007 12:57 PM To: hobbit at hswn.dk Subject: Re: [hobbit] static declaration of 'sendfile' follows non-static declaration On Tue, Jul 24, 2007 at 09:06:49AM -0400, Manocchia, Robert wrote: > I am trying to compile hobbit 4.2.0 on HPUX 11.23 itanium. > > Does anyone know what is wrong here. I've followed a thread about this but I > provided no solution of where to get help. Someone with HP-UX knowledge may be able to help you. There's no reference to "sendfile" anywhere in the Hobbit code, so I believe this is a problem with the compiler setup on your machine, or the HP-UX include-files. Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

static declaration of 'sendfile' follows non-static declaration
by Robert-Manocchia＠IDEXX.com 24 Jul '07

24 Jul '07

I am trying to compile hobbit 4.2.0 on HPUX 11.23 itanium. Does anyone know what is wrong here. I've followed a thread about this but I provided no solution of where to get help. I have the proper versions of gmake and gcc file /usr/local/bin/gmake /usr/local/bin/gmake: ELF-32 executable object file - IA64 file /usr/local/bin/gcc /usr/local/bin/gcc: ELF-32 executable object file - IA64 Any help would be appreciated. Robert Manocchia UNIX System Administrator IDEXX Laboratories 207 556-6860 EMail Robert-Manocchia at idexx.com

2 1

Alerts color filtering
by Daniel.Hartmeier＠pax.ch 24 Jul '07

24 Jul '07

How do you configure hobbit-alerts.cfg so a specific recipient only gets notified on changes from/to color red? For example, I added HOST=* SCRIPT /path/alert.sh recipient COLOR=red,yellow REPEAT=4h RECOVERED where alert.sh appends a line to alert.log for each invokation: #!/bin/sh echo "$BBHOSTSVCCOMMAS $BBCOLORLEVEL ACKCODE=$ACKCODE DOWNSECS=$DOWNSECS RECOVERED=$RECOVERED RCPT=$RCPT" >>/path/alerts.log I manually simulate a sequence green -> yellow -> red -> yellow -> green on host.service with bb 127.0.0.1 "status host.service yellow `date`" bb 127.0.0.1 "status host.service red `date`" bb 127.0.0.1 "status host.service yellow `date`" bb 127.0.0.1 "status host.service green `date`" and in the log I see host.service yellow ACKCODE=282431 DOWNSECS=0 RECOVERED=0 RCPT=recipient host.service red ACKCODE=282431 DOWNSECS=13 RECOVERED=0 RCPT=recipient host.service yellow ACKCODE=-1 DOWNSECS=42 RECOVERED=1 RCPT=recipient Note that there is no invokation for the red -> yellow change, and that the yellow -> green change uses 'yellow' as current color. Now, if I add HOST=* MAIL mail.addr REPEAT=4h COLOR=red RECOVERED and simulate the same sequence, I only get a mail about Subject: Hobbit [282431] host:service CRITICAL (RED) and there is NO mail about the service recovering. I assume that's because the color changed from red -> yellow -> green, and that red -> yellow : does not match the RECOVERED criterion yellow -> green : does not match the COLOR=red criterion Is there any way to get a recovery mail in this scenario, WITHOUT changing the rule to COLOR=red,yellow? I don't want to spam the recipient with incidents which never reach color red (i.e. green -> yellow -> green). For this recipient, the incident is actually considered 'recovered' as soon as the color is no longer red... Or how do you explain to your recipient (who only wishes to see 'serious' incidents), that they can't rely on getting a 'recovered' mail in all cases? Daniel

1 0

[hobbit] BBWIN MSG Ignore rule problem
by bewhite＠fellowes.com 24 Jul '07

24 Jul '07

I feel so stupid. You were correct. The example ignore is within a comment block. It works fine now. Thanks for posting. It's the simple things we over look which often are the problem! ......Bruce -----Original Message----- From: s_aiello at comcast.net [mailto:s_aiello at comcast.net] Sent: Monday, July 23, 2007 8:23 AM To: hobbit at hswn.dk Subject: Re: [hobbit] BBWIN MSG Ignore rule problem On Monday 23 July 2007 09:12, Dugan, Darin D [EIT] wrote: > Bruce, > > I tend to ignore on a combination of eventid and source, but either > alone should work (as the examples indicate). What version of BBWin on > what platform? You might also recheck that you don't have a > conflicting match rule, the ignore is in the msgs block, the msgs > agent is enabled in the bbwin block, etc. > > > From: White, Bruce [mailto:bewhite at fellowes.com] > Sent: Friday, July 20, 2007 3:47 PM > Subject: RE: [hobbit] BBWIN MSG Ignore rule problem > > HELP! Anybody out there have any idea why the ignore is not working > the BBWIN config file? > Even though this sounds simple & stupid, I have been bitten by it. Look to see if there is a  (comments) surrounding the area you added your entry. Default bbwin.cfg file has a few of these giving you config sample. To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk ---------------------------------------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc. ----------------------------------------------------

1 0