April 2005 - Xymon - Xymon mailman web

[hobbit] New enable/disable tool ready for testing
by GThiesfeld＠webmd.net 14 Apr '05

14 Apr '05

> My solution works somewhat differently than the old "maint.pl" script: > The enable/disable functionality is no longer a separate webpage > listing all hosts; instead, this function is moved to each hosts' > "info" column page. I did this because I have about 2000 hosts, so the > list of all hosts was practically unusable in my setup. You can see > how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick > one of the "info" buttons. The demo looks good. My concern is that we often disable all tests on up to 30 servers at a time to deploy code and reboot. Having to do each box individually would be a real chore.

1 0

[hobbit] New enable/disable tool ready for testing
by Kevin.Hanrahan＠novainfo.com 14 Apr '05

14 Apr '05

I like the approach taken but can you disable ALL, ALL with a single action? Once a month, we have a fiasco called maintenance Sunday where all the different groups are at work taking down all their respective systems for patching, routine maint. And whatever needs to be done. I just select All hosts, All tests and disable for x hours. Will this still be available? Kevin -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Thursday, April 14, 2005 9:53 AM To: hobbit at hswn.dk Subject: [hobbit] New enable/disable tool ready for testing I've spent the past couple of days working on the enable/disable code, in an attempt to get rid of the maint.pl Perl script. I have something now that I believe works well, so if you feel like trying it out I've generated a patch for you against Hobbit 4.0.2. It is available at http://www.hswn.dk/beta/maintenance-feature.patch Installing is the usual: cd hobbit-4.0.2 patch -p0 </tmp/maintenance-feature.patch make stop Hobbit make install (as root) start Hobbit My solution works somewhat differently than the old "maint.pl" script: The enable/disable functionality is no longer a separate webpage listing all hosts; instead, this function is moved to each hosts' "info" column page. I did this because I have about 2000 hosts, so the list of all hosts was practically unusable in my setup. You can see how it looks on the demo site http://www.hswn.dk/hobbit/ - just pick one of the "info" buttons. You can of course disable tests (a single one, some of them, or all of them); you can re-enable tests that have been disabled; you can schedule a disable to happen at a later time; and you can cancel scheduled disables if they are no longer needed. The scheduled disabling is handled internally in the Hobbit daemon, so you no longer need "cron" running to handle it. I've never been fond of allowing my CGI scripts to run at-jobs from a security perspective... Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk Note: The information contained in this email and in any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. The recipient should check this email and any attachments for the presence of viruses. Sender accepts no liability for any damages caused by any virus transmitted by this email. If you have received this email in error, please notify us immediately by replying to the message and delete the email from your computer. This e-mail is and any response to it will be unencrypted and, therefore, potentially unsecure. Thank you. NOVA Information Systems, Inc.

1 0

bb-hist.sh strange problem
by truecker＠technologie-management.net 14 Apr '05

14 Apr '05

I updated 2 of 3 hobbits now to 4.0.2 and didn't get any errors. But I though one problem of 4.0.1 has been resolved. I got an alarm this night from the sensor procs of one host. After 5 minutes, the problem was solved. I also got a message about that. This morning I looked at the history and can't find the entry. After looking into the logfile from sensor, I found the entry, but bb-hist.sh don't show me this color-change. Here the part in the hist-file: ---snip--- Fri Jan 14 15:06:36 2005 green 1105711596 Tue Apr 5 16:02:32 2005 green 1112709752 16501 Tue Apr 5 20:37:33 2005 red 1112726253 301 Tue Apr 5 20:42:34 2005 green 1112726554 15646 Wed Apr 6 01:03:20 2005 purple 1112742200 24126 Wed Apr 6 07:45:26 2005 clear 1112766326 227 Wed Apr 6 07:49:13 2005 red 1112766553 295 Wed Apr 6 07:54:08 2005 green 1112766848 25803 Wed Apr 6 15:04:11 2005 red 1112792651 1201 Wed Apr 6 15:24:12 2005 green 1112793852 372952 Sun Apr 10 23:00:04 2005 red 1113166804 300 Sun Apr 10 23:05:04 2005 green 1113167104 14101 Mon Apr 11 03:00:05 2005 red 1113181205 300 Mon Apr 11 03:05:05 2005 green 1113181505 ---snap--- There are also entries in the histlogs, but bb-hist.sh shows me the following entry: ---snip--- Fri Jan 14 15:06:36 2005 green 86 days 19:12:47 ---snap--- The color also shows me a recent green. I got the problem on 4.0.1 and 4.0.2. Regards, Thomas

4 4

localize hobbit
by jonbjorn＠hi.is 14 Apr '05

14 Apr '05

I know this post has very little to do with hobbit's functionality but mabe you can help me. I´m trying to translate a few words in hobbit that are displayed under trends. So far I have been able to change everything but week (week 09, week10 ..etc. Does anyone know how to change this text into uge (danish) or vika (icelandic) ? rgds -- Jon Bjorn Njalsson <jonbjorn at hi.is>

2 2

[hobbit] Some thoughts about alerts, acks and escalations
by dstuffle＠deltafaucet.com 13 Apr '05

13 Apr '05

Henrik Stoerner wrote: > I'm beginning to look at the issue of escalating alerts. > And I've had an idea that I'd like to get some feedback > on before I go ahead and implement it. > > Right now, Hobbit doesn't handle escalating an alert. When > someone receives an alert message, they can ack it - when > they do, all alerts stop and the item disappears from the > "Critical systems" page (the NK page). > > BB has the concept of escalating an alert, meaning that > some recipients of an alert will get the alert message > even if the alert has been acknowledged. > > > What I'd like to have is the BB system with a finer > granularity. A recipient in the hobbit-alerts.cfg file > has an associated "level", default is 1. > > I want our NOC guys who do nothing but stare at the NK > page 24x7 to be able to acknowledge an alert - and that > just gets it off their monitor, it doesn't stop alerts > from going out. A "level 0" acknowledgment - this is just > to log that a trouble ticket has been raised for the > issue. > > A technician (who is a "level 1" recipient) can > acknowledge the alert he receives - this will stop alert > messages from going out to other "level 1" receipients, > so all of the engineers can concentrate on doing what > needs to be done. > > Alerts will still be sent to recipients who are "level 2" > and above - these are the equivalent of the BB > "escalation" alerts. They can ack the alert if they'd > like to turn off more alert messages, of course. > > You can have even higher levels if you like, probably > going up the hierarchy of managers. I don't think we'll > using more than the 3 levels I've described, but there is > no reason to impose any limit. > > > Does that sound like it would be useful? > > > Regards, > Henrik > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk I like it too. Would there still be a way to ack an alert which stops all alerts to everyone? This way your saying, "I see the alert and I know it's not a problem, so don't alert anyone else in any level." Similarly, sometimes I would like to say, "I see the alert, but I can't do anything about it right now because I'm on the golf course, so stop alerting me, but continue alerting everyone else, even people in my same level." Would the recipient levels be set per host? I may be level 1 on one host but level 3 on another. Somewhat related, one big problem we have is being able to mail ack an alert from a cell phone. When you reply to the message it doesn't keep the subject. But I believe it puts the ack code somewhere in the body. Could Hobbit search the body of the message for "Hobbit [xxxxxx]"? I don't think I've heard anyone else with this problem, am I missing something? Thanks Henrik. ~~~~~~~~~~~~~~ David Stuffle dstuffle at deltafaucet.com Delta Faucet Company (317) 571-4301 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

2 1

Some thoughts about alerts, acks and escalations
by henrik＠hswn.dk 13 Apr '05

13 Apr '05

I'm beginning to look at the issue of escalating alerts. And I've had an idea that I'd like to get some feedback on before I go ahead and implement it. Right now, Hobbit doesn't handle escalating an alert. When someone receives an alert message, they can ack it - when they do, all alerts stop and the item disappears from the "Critical systems" page (the NK page). BB has the concept of escalating an alert, meaning that some recipients of an alert will get the alert message even if the alert has been acknowledged. What I'd like to have is the BB system with a finer granularity. A recipient in the hobbit-alerts.cfg file has an associated "level", default is 1. I want our NOC guys who do nothing but stare at the NK page 24x7 to be able to acknowledge an alert - and that just gets it off their monitor, it doesn't stop alerts from going out. A "level 0" acknowledgment - this is just to log that a trouble ticket has been raised for the issue. A technician (who is a "level 1" recipient) can acknowledge the alert he receives - this will stop alert messages from going out to other "level 1" receipients, so all of the engineers can concentrate on doing what needs to be done. Alerts will still be sent to recipients who are "level 2" and above - these are the equivalent of the BB "escalation" alerts. They can ack the alert if they'd like to turn off more alert messages, of course. You can have even higher levels if you like, probably going up the hierarchy of managers. I don't think we'll using more than the 3 levels I've described, but there is no reason to impose any limit. Does that sound like it would be useful? Regards, Henrik

3 2

[hobbit] Some thoughts about alerts, acks and escalations
by rdeal＠tigr.org 13 Apr '05

13 Apr '05

Yes this sound useful, especially if there is any easy way to set when the alerts start going to the next level up. An escalation delay, for example that would determine how long something is in alert before going to the next level. Would be nice to be able to set the escalation delay globally, and to change it per host. Might also be nice (for some) to have different delays for each escalation level (10 mins from 0-to-1, but 30 mins from 1-to-2)? -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, April 13, 2005 1:49 AM To: hobbit at hswn.dk Subject: [hobbit] Some thoughts about alerts, acks and escalations I'm beginning to look at the issue of escalating alerts. And I've had an idea that I'd like to get some feedback on before I go ahead and implement it. Right now, Hobbit doesn't handle escalating an alert. When someone receives an alert message, they can ack it - when they do, all alerts stop and the item disappears from the "Critical systems" page (the NK page). BB has the concept of escalating an alert, meaning that some recipients of an alert will get the alert message even if the alert has been acknowledged. What I'd like to have is the BB system with a finer granularity. A recipient in the hobbit-alerts.cfg file has an associated "level", default is 1. I want our NOC guys who do nothing but stare at the NK page 24x7 to be able to acknowledge an alert - and that just gets it off their monitor, it doesn't stop alerts from going out. A "level 0" acknowledgment - this is just to log that a trouble ticket has been raised for the issue. A technician (who is a "level 1" recipient) can acknowledge the alert he receives - this will stop alert messages from going out to other "level 1" receipients, so all of the engineers can concentrate on doing what needs to be done. Alerts will still be sent to recipients who are "level 2" and above - these are the equivalent of the BB "escalation" alerts. They can ack the alert if they'd like to turn off more alert messages, of course. You can have even higher levels if you like, probably going up the hierarchy of managers. I don't think we'll using more than the 3 levels I've described, but there is no reason to impose any limit. Does that sound like it would be useful? Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

2 1

[hobbit] Some thoughts about alerts, acks and escalations
by Larry.Barber＠usda.gov 13 Apr '05

13 Apr '05

Yes, very useful. I think the biggest flaw with BigBrother is the way one red alert can mask subsequent red alerts, even alerts from different machines. There needs to be a way for the operations people to clear an alert after they've noticed it and logged it. Thanks, Larry Barber On Wed, 2005-04-13 at 00:49 -0500, henrik at hswn.dk wrote: > I'm beginning to look at the issue of escalating alerts. And I've had > an idea that I'd like to get some feedback on before I go ahead and > implement it. > > Right now, Hobbit doesn't handle escalating an alert. When someone > receives an alert message, they can ack it - when they do, all alerts > stop and the item disappears from the "Critical systems" page (the NK > page). > > BB has the concept of escalating an alert, meaning that some > recipients of an alert will get the alert message even if the alert > has been acknowledged. > > > What I'd like to have is the BB system with a finer granularity. A > recipient in the hobbit-alerts.cfg file has an associated "level", > default is 1. > > I want our NOC guys who do nothing but stare at the NK page 24x7 to > be > able to acknowledge an alert - and that just gets it off their > monitor, it doesn't stop alerts from going out. A "level 0" > acknowledgment - this is just to log that a trouble ticket has been > raised for the issue. > > A technician (who is a "level 1" recipient) can acknowledge the alert > he receives - this will stop alert messages from going out to other > "level 1" receipients, so all of the engineers can concentrate on > doing what needs to be done. > > Alerts will still be sent to recipients who are "level 2" and above - > these are the equivalent of the BB "escalation" alerts. They can ack > the alert if they'd like to turn off more alert messages, of course. > > You can have even higher levels if you like, probably going up the > hierarchy of managers. I don't think we'll using more than the 3 > levels I've described, but there is no reason to impose any limit. > > > Does that sound like it would be useful? > > > Regards, > Henrik > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0

[hobbit] Some thoughts about alerts, acks and escalations
by mlowery＠alliedtechgroup.com 13 Apr '05

13 Apr '05

Absolutely! I'm currently the level 3 guy, but if one of the level 1 guys ack the alert, I don't get it anymore... Sounds like a great idea! Michael -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, April 13, 2005 12:49 AM To: hobbit at hswn.dk Subject: [hobbit] Some thoughts about alerts, acks and escalations I'm beginning to look at the issue of escalating alerts. And I've had an idea that I'd like to get some feedback on before I go ahead and implement it. Right now, Hobbit doesn't handle escalating an alert. When someone receives an alert message, they can ack it - when they do, all alerts stop and the item disappears from the "Critical systems" page (the NK page). BB has the concept of escalating an alert, meaning that some recipients of an alert will get the alert message even if the alert has been acknowledged. What I'd like to have is the BB system with a finer granularity. A recipient in the hobbit-alerts.cfg file has an associated "level", default is 1. I want our NOC guys who do nothing but stare at the NK page 24x7 to be able to acknowledge an alert - and that just gets it off their monitor, it doesn't stop alerts from going out. A "level 0" acknowledgment - this is just to log that a trouble ticket has been raised for the issue. A technician (who is a "level 1" recipient) can acknowledge the alert he receives - this will stop alert messages from going out to other "level 1" receipients, so all of the engineers can concentrate on doing what needs to be done. Alerts will still be sent to recipients who are "level 2" and above - these are the equivalent of the BB "escalation" alerts. They can ack the alert if they'd like to turn off more alert messages, of course. You can have even higher levels if you like, probably going up the hierarchy of managers. I don't think we'll using more than the 3 levels I've described, but there is no reason to impose any limit. Does that sound like it would be useful? Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] Some thoughts about alerts, acks and escalations
by tbarnes1＠hfhs.org 13 Apr '05

13 Apr '05

YES - that would work well here. Terry Barnes Siemens Com @ HFHS 248-853-4968 (Office) 586-405-8382 (Cellular) 248-844-3030 (Fax) 5864058382 at messaging.nextel.com (Text Pager) tbarnes1 at hfhs.org >>> henrik at hswn.dk 4/13/05 1:49:07 AM >>> I'm beginning to look at the issue of escalating alerts. And I've had an idea that I'd like to get some feedback on before I go ahead and implement it. Right now, Hobbit doesn't handle escalating an alert. When someone receives an alert message, they can ack it - when they do, all alerts stop and the item disappears from the "Critical systems" page (the NK page). BB has the concept of escalating an alert, meaning that some recipients of an alert will get the alert message even if the alert has been acknowledged. What I'd like to have is the BB system with a finer granularity. A recipient in the hobbit-alerts.cfg file has an associated "level", default is 1. I want our NOC guys who do nothing but stare at the NK page 24x7 to be able to acknowledge an alert - and that just gets it off their monitor, it doesn't stop alerts from going out. A "level 0" acknowledgment - this is just to log that a trouble ticket has been raised for the issue. A technician (who is a "level 1" recipient) can acknowledge the alert he receives - this will stop alert messages from going out to other "level 1" receipients, so all of the engineers can concentrate on doing what needs to be done. Alerts will still be sent to recipients who are "level 2" and above - these are the equivalent of the BB "escalation" alerts. They can ack the alert if they'd like to turn off more alert messages, of course. You can have even higher levels if you like, probably going up the hierarchy of managers. I don't think we'll using more than the 3 levels I've described, but there is no reason to impose any limit. Does that sound like it would be useful? Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk ============================================================================== HFHS CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by replying in an email to the sender, delete the email from your computer system and shred any paper copies of the email you printed. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. These risks are described in our Privacy Policy at http://henryford.com. Review that policy carefully before continuing to communicate with us by e-mail. For greater Internet security, our policy describes the Henry Ford MyHealth electronic communication process - you may register at http://henryford.com. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. ==============================================================================

1 0