- Xymon - Xymon mailman web

[hobbit] Confused with test settings!
by CHRIS.MORRIS＠RWEnpower.com 24 Jan '07

24 Jan '07

I would put a space between the # and BBNET Have a look at your bbnet-test man page - you can turn on various diagnostic options to see why pinging certain hosts may fail such as --report --dnslog=FILENAME and --debug These may help! > -----Original Message----- > From: Andy [SMTP:axg at syntec.co.uk] > Sent: Wednesday, January 24, 2007 1:38 PM > To: hobbit at hswn.dk > Subject: RE: [hobbit] Confused with test settings! > > Tried test ip and no joy.... > > The hobbit server has this entry: > > 192.168.4.61 IVRA1 #BBNET BBDISPLAY bbd testip > http://IVRA1/hobbit/ > > Does that point to any deficiencies? > > Andy Greening > Syntec Uk > Tel: 0845 092 8000 > DDI: 0845 092 2011 > Mob: 07980 813806 > > > -----Original Message----- > From: Rolf Schrittenlocher [mailto:Schrittenlocher at rz.uni-frankfurt.de] > Sent: 24 January 2007 13:10 > To: hobbit at hswn.dk > Subject: Re: [hobbit] Confused with test settings! > > Hi, > > are those servers known one's in DNS (or do they have an entry in > /etc/hosts or something similar?). If not try using testip. > Rolf > > Yes, and it makes no difference! > > > > Andy Greening > > Syntec Uk > > > > > > -----Original Message----- > > From: Johann Eggers [mailto:Johann.Eggers at teleatlas.com] > > Sent: 24 January 2007 12:55 > > To: hobbit at hswn.dk > > Subject: RE: [hobbit] Confused with test settings! > > > > > > > > > >> -----Original Message----- > >> From: Andy [mailto:axg at syntec.co.uk] > >> Sent: Mittwoch, 24. Januar 2007 13:50 > >> To: hobbit at hswn.dk > >> Subject: RE: [hobbit] Confused with test settings! > >> > >> bb-host entries are: > >> > >> My additions: > >> 192.168.4.151 FTV01 > >> 192.168.4.64 IVRA4 # testip pulldata > >> 192.168.4.196 Fax2Desk1 > >> 192.168.4.62 IVRA2 # conn > >> > >> Some of the existing ones: > >> 192.168.4.120 NAS1 > >> 192.168.4.121 NAS3 # testip > >> 192.168.4.122 Concierge # ftp http testip > >> 192.168.4.123 Concierge1 # ftp http testip > >> 192.168.4.124 Concierge2 # ftp http testip > >> 192.168.4.130 WMEnc1 # testip > >> 192.168.4.131 WMEnc2 # testip > >> > > > > > > Hmmm.... > > Strange... looks o.k. so far... > > Can you stop and restart the hobbit processes? > > > > > > To unsubscribe from the hobbit list, send an e-mail to > > hobbit-unsubscribe at hswn.dk > > > > > > > > > -- > Mit freundlichen Gruessen > Rolf Schrittenlocher > > HRZ/BDV, Senckenberganlage 31, 60054 Frankfurt > Tel: (49) 69 - 798 28908 Fax: (49) 69 798 2881 > LBS: lbs-f at mlist.uni-frankfurt.de > Persoenlich: schritte at rz.uni-frankfurt.de > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 23/01/2007 > 20:40 > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 23/01/2007 > 20:40 > > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > **************************************************************************** Make a New Year's resolution to get your heating equipment checked. If you don't you could be adding as much as 10% to your heating bill without knowing it. Source: Carbon Trust (2006) **************************************************************************** This e-mail is provided for general information purposes only and does not constitute investment or transactional advice. For the avoidance of doubt the contents of this email are subject to contract and will not constitute a legally binding contract. The information contained in this email is intended only for the use of the intended recipient at the email address to which it has been addressed. If the reader of this message is not an intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination or copying of the message or associated attachments is strictly prohibited. If you have received this e-mail in error, please notify postmaster at npower.com (UK 01384 275454) and delete it immediately from your system. Neither Npower nor any of the other companies in the RWE Npower group from whom this e-mail originates accept any responsibility for losses or damage as a result of any viruses and it is your responsibility to check attachments (if any) for viruses. RWE Npower plc Registered office: Windmill Hill Business Park, Whitehill Way, Swindon SN5 6PB. Registered in England and Wales: number 3892782. This e-mail may be sent on behalf of a member of the RWE Npower group of companies. *****************************************************************************

1 0

Confused with test settings!
by axg＠syntec.co.uk 24 Jan '07

24 Jan '07

All, I'm still having problems getting the 'conn' status to show on my newly added servers. I've been using the config report (that Hobbit so helpfully gives on the webpage) to compare a new and an exisiting machine. The exisiting machine has an entry in Network Tests for conn, whereas my new one has no entries for network tests at all. Question is this: How do I get an entry for network tests? Andy G Syntec Uk Tel: 0845 092 8000 DDI: 0845 092 2011 Mob: 07980 813806 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.8/649 - Release Date: 23/01/2007 20:40

3 6

Hobbit migration to a new box
by david＠stenhouseconsulting.com 23 Jan '07

23 Jan '07

Pardon me if this question has been asked before. I am installing a new server since the previous server we had has been crashing do to hardware issues. Is there a best practices for migrating the Hobbit data from the old box to the new? Thanks in advance. David Gilmore Consultant sc_logo 4 Traverse Street Providence, RI 02906 401-453-6900 Voice 401-454-7581 Fax Cert_Partner_rgb

5 11

[hobbit] Purples, all non-green view
by KauffmanT＠nibco.com 23 Jan '07

23 Jan '07

Oh, my! It certainly does! Tom Kauffman -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Friday, May 12, 2006 11:05 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Purples, all non-green view On Fri, May 12, 2006 at 02:41:19PM +0000, David Gore wrote: > There was some talk of the purples not showing up on the 'All non-green > view'. We are also disappointed that the purples have been removed from > this page. Our main page is the ANV page and would really like to have > that back. Could we at least have it back with a flag? Or did we some > how remove the purples on the ANV page with some flag in the latest > snapshot? Seems I broke it somewhere. This should put the purples back on the bb2 page. Henrik CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.

2 3

CPU limit per process?
by dan.mcdonald＠austinenergy.com 23 Jan '07

23 Jan '07

Is there a way to monitor how much CPU processes are consuming? We would like to alert when a particular process exceeds 15% of total CPU - that indicates that the process has run-away. In hobbit-clients.cfg I see a way to check the number of processes, but not the amount of CPU consumed.... -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX Austin Energy http://www.austinenergy.com

1 0

Could not use regular expressions in client-local.cfg [name] tag
by grsamy＠yahoo.com 22 Jan '07

22 Jan '07

Is it possible to use regular expression in client-local.cfg to specify hostname(s), as I could do so in hobbit-clients.cfg? I tried the same regular expression as in hobbit-client.cfg and it doesn't work. Tried on few servers without regular expression on hostnames and it worked. Please help as I have to configure clientt-local.cfg for hundreds of servers :( Thanks Ram --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.

3 5

Expression in pcretest works, but not Hobbit
by rsmrcina＠wi.rr.com 22 Jan '07

22 Jan '07

I'm trying to match a specific character in the third column of a list: ABC0010 28771 V RR ABC0 12/23/2006 TRL1923 18882 Q R1 ABC2 12/24/2006 E19V911 08766 V V1 RKSA 01/22/2007 I'm looking for V's with the following expression: \b\bV\b\b\b This works with pcretest, but when I plug it into Hobbit (yes with the preceding %), it seems to find nothing. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007

1 0

Dependency sytem in Hobbit
by emarganne＠be.tiauto.com 22 Jan '07

22 Jan '07

Hello all, I am Etienne Marganne, a new comer in TI Automotive, a society which uses Hobbit as a monitoring tool, I will be in charge of Hobbit tool. We would like to enhance our monitoring tool in order to get more detailed informations through it. One of the first thing we would like to do is to create a dependency system between monitored hosts across our network. For all the further discussion, please keep in mind that we have a very large network and two Hobbit servers where we would like to keep the same "hh-hosts" file. The idea of the dependency system is the following one: once we have a host that fails on a network path in our network all the hosts further that one will be very likely unreachable. This will cause a lot of alerts to be triggered because of one failure. This is not interesting because our team will be flooded by those alerts. Therefore it could be useful to create dependencies so that those further devices on the same path will not trigger alerts (basically turning red). There is a specific tag that can be used to do such a work, the "route" tag. In our case with two Hobbit servers, we would tune that with the "route_BBLOCATION" tag. Knowing that there are Hobbit clients on all the network nodes between the two endpoints, the simplest idea would be to list all the nodes in the description of those tags. This could work even if it would generate of job. A little bit further here, let's say that one node fails on a path, it is very probable that if you know that the following nodes are unreachable, you may not want to test them anymore (to forbid them to turn red). Now think of a big network with a lot of redundancy, it is very probable that there will be indeed a lot of network paths between a server and one final host. If on one path one node fails, it does not mean that the final client is not reachable. But with the "route" tag, that client would be signal as unreachable since a member of the "route" has failed. This is not comfortable at all. What we would like to know, or to get, if there is a way to get this dependency system work: Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client | | | --------- 5 ------------6 ----------- | There are two paths to reach the Final Client, one composed by 1, 2, 3, 4 and another one composed by 5, 6. With the current "route" tag we would have such a list of nodes: route_HobbitServerA:1,2,3,4,5,6 then if 1 fails and the path 1-2-3-4 would not work anymore but the 5-6 one would still. A good dependency system would to have such a thing: Final Client depends on 4, 4 depends on 3, 3 depends on 2, 2 depends on 1 but Final Clients also depends on 6 which depends on 5. More over this would also solve that kind of topology : Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client | | | | --------- 5 ------------6 ----------- | Where there is a link between 2 and 5, 2 and 6, 5 and 3, 6 and 3. Maybe that something could be set up with the "depends" tag, however I do not know how the informations will propagate through the different dependencies done that tag. Even further on the topic, the "route" tag performs only ping tests which does not seem enough to me. I would like to add cpu, disks, ... tests to the whole dependency system. Thank you for your help and answers, Regards, Etienne Marganne TI Automotive. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

10 9

Importance flag on alerts
by Jason.Chambers＠geosoft.com 22 Jan '07

22 Jan '07

Hi Henrik, My network admin was wondering if there was a way to set the high importance flag on the emails that are sent out by certain servers. It'll have his smartphone chime a different sound if the message is marked as high importance than regular mail. No big deal if it can't be done easily. Jason Chambers IT Helpdesk Support Geosoft Inc. 85 Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: 416-369-0111 x344 Fax: 416-369-9599 www.geosoft.com

3 2

[hobbit] Dependency sytem in Hobbit
by emarganne＠be.tiauto.com 22 Jan '07

22 Jan '07

Hello all, After another deep look into Hobbit mechanisms, it looks like the idea of using the combo tests to create a tree structure is good and you can link that structure to the alerts. This is done by putting rules that are based upon combo tests since they are considered as standard tests (with an historic, statistics ...). Now the idea would to stop the alert floods triggered when a critical device on a path falls down. The tree structure helps gathering all the necessary informations into one test. We can now trigger alerts on those alerts preferably than on common bb-hosts tests, but the flood still remains. It remains because you have to trigger alerts on each combo tests to know exactly where it has failed. And since all your combo tests are involved whenever a failure occurs at some point the following nodes will be unreachable in this case: A - 1 - 2 - 3 - F If anybody has an idea he is welcome ... :-) Etienne Marganne, TI Automotive. _____ From: Jones, Jason (Altrincham) [mailto:JasonAS_Jones at mentor.com] Sent: vendredi 19 janvier 2007 17:10 To: hobbit at hswn.dk Subject: RE: [hobbit] Dependency sytem in Hobbit Ok, have just read this E-mail but I thought that if you did the route tag on a host it only went yellow (unreachable by proxy) if itself and a device in it's route entry failed (i.e. if the gateway fails but the host still responds to ping then it stays green) though Henrik would have to confirm this as I haven't had such a situation. Also I'm curious how the CPU, hard drive etc, dependencies would work? If CPU on host1 has a high load what effect would that have on host2? Unless of course a database was being hosted by host1... Also can I ask, how large is this network? Henrik's is ~4000 or something ours is about 400-500. Jason. _____ From: Hubbard, Greg L [mailto:greg.hubbard at eds.com] Sent: 19 January 2007 14:56 To: hobbit at hswn.dk Subject: RE: [hobbit] Dependency sytem in Hobbit Etienne -- you are going to have to find someone to write that and add it to Hobbit. Path-based alarm suppression is one of the holy grails in the network management industry, and the reason it has not yet been solved is because it is a difficult problem. For small networks you can come up with a solution, but if you are using VLANs and WAN's and load balancers and all that other stuff it gets to be rather difficult. There are many commercial software vendors that claim to have this problem solved -- but sometimes even their demos do not work. The little bit of dependency specification that you can put into Hobbit does indeed work, but not across the board. GLH _____ From: Marganne, Etienne [mailto:emarganne at be.tiauto.com] Sent: Friday, January 19, 2007 5:58 AM To: hobbit at hswn.dk Cc: henrik at hswn.dk Subject: [hobbit] Dependency sytem in Hobbit Hello all, I am Etienne Marganne, a new comer in TI Automotive, a society which uses Hobbit as a monitoring tool, I will be in charge of Hobbit tool. We would like to enhance our monitoring tool in order to get more detailed informations through it. One of the first thing we would like to do is to create a dependency system between monitored hosts across our network. For all the further discussion, please keep in mind that we have a very large network and two Hobbit servers where we would like to keep the same "hh-hosts" file. The idea of the dependency system is the following one: once we have a host that fails on a network path in our network all the hosts further that one will be very likely unreachable. This will cause a lot of alerts to be triggered because of one failure. This is not interesting because our team will be flooded by those alerts. Therefore it could be useful to create dependencies so that those further devices on the same path will not trigger alerts (basically turning red). There is a specific tag that can be used to do such a work, the "route" tag. In our case with two Hobbit servers, we would tune that with the "route_BBLOCATION" tag. Knowing that there are Hobbit clients on all the network nodes between the two endpoints, the simplest idea would be to list all the nodes in the description of those tags. This could work even if it would generate of job. A little bit further here, let's say that one node fails on a path, it is very probable that if you know that the following nodes are unreachable, you may not want to test them anymore (to forbid them to turn red). Now think of a big network with a lot of redundancy, it is very probable that there will be indeed a lot of network paths between a server and one final host. If on one path one node fails, it does not mean that the final client is not reachable. But with the "route" tag, that client would be signal as unreachable since a member of the "route" has failed. This is not comfortable at all. What we would like to know, or to get, if there is a way to get this dependency system work: Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client | | | --------- 5 ------------6 ----------- | There are two paths to reach the Final Client, one composed by 1, 2, 3, 4 and another one composed by 5, 6. With the current "route" tag we would have such a list of nodes: route_HobbitServerA:1,2,3,4,5,6 then if 1 fails and the path 1-2-3-4 would not work anymore but the 5-6 one would still. A good dependency system would to have such a thing: Final Client depends on 4, 4 depends on 3, 3 depends on 2, 2 depends on 1 but Final Clients also depends on 6 which depends on 5. More over this would also solve that kind of topology : Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client | | | | --------- 5 ------------6 ----------- | Where there is a link between 2 and 5, 2 and 6, 5 and 3, 6 and 3. Maybe that something could be set up with the "depends" tag, however I do not know how the informations will propagate through the different dependencies done that tag. Even further on the topic, the "route" tag performs only ping tests which does not seem enough to me. I would like to add cpu, disks, ... tests to the whole dependency system. Thank you for your help and answers, Regards, Etienne Marganne TI Automotive. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

1 0