We have the following:
x.x.x.x hostA # ssh
y.y.y.y hostB # ssh ldap://hostB.rit.edu:389/ou=People,dc=rit,dc=edu?uid?sub?(uid=authtest) depends=(conn:hostA/conn),(ldap:hostA/conn)
These run Solaris 10 zones. hostA is the physical system, hostB is a zone within hostA. So if the hostA goes down, then hostB will be down also. However it appears that if the "conn" test fails for hostA, it fails for hostB also, but hostB "conn" shows red, not clear.
Is this correct? We have many Solaris 10 zones that if the physical host goes down, then all the zones will fail the test too. We don't want to be emailed (or paged) with massive amounts of hosts going down, when we know that other host test will fail.
Thanks.
---Eric
I reported a similar problem several weeks ago on SLES9.
Eric Meddaugh wrote:
We have the following:
x.x.x.x hostA # ssh
y.y.y.y hostB # ssh ldap://hostB.rit.edu:389/ou=People,dc=rit,dc=edu?uid?sub?(uid=authtest) depends=(conn:hostA/conn),(ldap:hostA/conn)
These run Solaris 10 zones. hostA is the physical system, hostB is a zone within hostA. So if the hostA goes down, then hostB will be down also. However it appears that if the “conn” test fails for hostA, it fails for hostB also, but hostB “conn” shows red, not clear.
Is this correct? We have many Solaris 10 zones that if the physical host goes down, then all the zones will fail the test too. We don’t want to be emailed (or paged) with massive amounts of hosts going down, when we know that other host test will fail.
Thanks.
---Eric
-- 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
Try using the "route" tag to set up the dependencies. Don't let all the router talk in the documentation throw you...
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA
GLH
From: Eric Meddaugh [mailto:etmsys at rit.edu]
Sent: Thursday, November 09, 2006 7:45 AM
To: hobbit at hswn.dk
Subject: [hobbit] depends tag?
We have the following:
x.x.x.x hostA # ssh
y.y.y.y hostB # sshldap://hostB.rit.edu:389/ou=People,dc=rit,dc=edu?uid?sub?(uid=authtest) depends=(conn:hostA/conn),(ldap:hostA/conn)
These run Solaris 10 zones. hostA is the physical system, hostBis a zone within hostA. So if the hostA goes down, then hostB will be down also. However it appears that if the "conn" test fails for hostA, it fails for hostB also, but hostB "conn" shows red, not clear.
Is this correct? We have many Solaris 10 zones that if thephysical host goes down, then all the zones will fail the test too. We don't want to be emailed (or paged) with massive amounts of hosts going down, when we know that other host test will fail.
Thanks.
---EricExactly what I was looking for. Thanks so much!
---Eric
From: Hubbard, Greg L [mailto:greg.hubbard at eds.com] Sent: Thursday, November 09, 2006 10:11 To: hobbit at hswn.dk Subject: RE: [hobbit] depends tag?
Try using the "route" tag to set up the dependencies. Don't let all the router talk in the documentation throw you...
x.x.x.x hostA # ssh
y.y.y.y hostB # ssh route:hostA
GLH
From: Eric Meddaugh [mailto:etmsys at rit.edu]
Sent: Thursday, November 09, 2006 7:45 AM
To: hobbit at hswn.dk
Subject: [hobbit] depends tag?
We have the following:
x.x.x.x hostA # ssh
y.y.y.y hostB # sshldap://hostB.rit.edu:389/ou=People,dc=rit,dc=edu?uid?sub?(uid=authtest) depends=(conn:hostA/conn),(ldap:hostA/conn)
These run Solaris 10 zones. hostA is the physical system, hostBis a zone within hostA. So if the hostA goes down, then hostB will be down also. However it appears that if the "conn" test fails for hostA, it fails for hostB also, but hostB "conn" shows red, not clear.
Is this correct? We have many Solaris 10 zones that if thephysical host goes down, then all the zones will fail the test too. We don't want to be emailed (or paged) with massive amounts of hosts going down, when we know that other host test will fail.
Thanks.
---EricHello folks, when I am checking the disk fs graphs and trying to get a detailed view with using the zoom (little loupe on the right side of the graph), I get the view from an other disk instead of the disk for what I am looking for. e.g. I am interessted in /nfs/exp, I am using the loupe and get the graph from an other filesystem like /aldv/*
it is switching the view to
[Hobbit Monitor 4.2.0]
Any ideas?
Regards, Klaus
Which versions of hobbit and rrd are you using?
Jason.
From: Klaus Hustert [mailto:khustert at csc.com] Sent: 24 November 2006 09:59 To: hobbit at hswn.dk Subject: [hobbit] little bug in zooming graphs?
Hello folks, when I am checking the disk fs graphs and trying to get a detailed view with using the zoom (little loupe on the right side of the graph), I get the view from an other disk instead of the disk for what I am looking for. e.g. I am interessted in /nfs/exp, I am using the loupe and get the graph from an other filesystem like /aldv/*
it is switching the view to
[Hobbit Monitor 4.2.0] <http://hobbitmon.sourceforge.net/>
<http://hobbitmon.sourceforge.net/>
Any ideas?
Regards, Klaus
Hello Jason, Hobbit Monitor is version 4.2.0 and rrdtool is 1.0.49.
Thomas Seglard Enata wrote: Hello Klaus, I got this "problem" too. You certainly have some FS that were deleted on your server... Try to remove the rrd(s) corresponding to these non-existing FS in your "$BBHOME/data/rrd/{servername}/disk,[fsname].rrd" and try again. You may want to try a "find . -mtime 10" in the rrd directory to locate not updated rrds.
This solution is a bit problematical for a cluster environment, because of when a package is switching to another host you will never get rid of it without loosing history data. Best regards, Klaus
Which versions of hobbit and rrd are you using? Jason.
From: Klaus Hustert [mailto:khustert at csc.com] Sent: 24 November 2006 09:59 To: hobbit at hswn.dk Subject: [hobbit] little bug in zooming graphs?
Hello folks, when I am checking the disk fs graphs and trying to get a detailed view with using the zoom (little loupe on the right side of the graph), I get the view from an other disk instead of the disk for what I am looking for. e.g. I am interessted in /nfs/exp, I am using the loupe and get the graph from an other filesystem like /aldv/*
it is switching the view to
[Hobbit Monitor 4.2.0]
Any ideas?
Regards, Klaus
Hello Klaus,
I got this "problem" too. You certainly have some FS that were deleted on your server... Try to remove the rrd(s) corresponding to these non-existing FS in your "$BBHOME/data/rrd/{servername}/disk,[fsname].rrd" and try again. You may want to try a "find . -mtime 10" in the rrd directory to locate not updated rrds. Sincerly,
Thomas
Klaus Hustert <khustert at csc.com> a écrit sur 24/11/2006 10:59:00 :
Hello folks, when I am checking the disk fs graphs and trying to get a detailed view with using the zoom (little loupe on the right side of the graph), I get the view from an other disk instead of the disk for what I am looking for. e.g. I am interessted in /nfs/exp, I am using the loupe and get the graph from an other filesystem like /aldv/* [image supprimée] [image supprimée] [image supprimée] it is switching the view to [image supprimée] [Hobbit Monitor 4.2.0]
Any ideas?
Regards, Klaus
Ce message (et toutes ses pieces jointes eventuelles) est confidentiel et etabli a l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, CNP Assurances et ses filiales declinent toute responsabilite au titre de ce message, s'il a ete altere, deforme ou falsifie.
This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither CNP Assurances nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.
Sweet! Works for me too! Thanks.
Hubbard, Greg L wrote:
Try using the "route" tag to set up the dependencies. Don't let all the router talk in the documentation throw you...
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA
GLH
-- 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
we don't use ping at all. can I specify a service (ssh or other abitrary service) of hostA instead? In other words, will the following work? The man page of bb-hosts made it sounds like 'route:router1,route2' replies on ping or something?
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA.ssh
On 11/9/06, Rich Smrcina <rsmrcina at wi.rr.com> wrote:
Sweet! Works for me too! Thanks.
Hubbard, Greg L wrote:
Try using the "route" tag to set up the dependencies. Don't let all the router talk in the documentation throw you...
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA
GLH
-- 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I think the route tag will suppress some of the tests if conn fails. Otherwise you are out of luck. I believe that some sort of general "root cause" or "dependency-based suppression" is on Henrik's "to do" list (if I remember a previous post), but probably not at the top, and certainly not in the current version of the product.
GLH
From: Jerry Yu [mailto:jjj863 at gmail.com]
Sent: Friday, November 10, 2006 12:34 PM
To: hobbit at hswn.dk
Subject: Re: [hobbit] depends tag?
we don't use ping at all. can I specify a service (ssh or otherabitrary service) of hostA instead? In other words, will the following work? The man page of bb-hosts made it sounds like 'route:router1,route2' replies on ping or something?
x.x.x.x hostA # ssh
y.y.y.y hostB # ssh route:hostA.ssh
On 11/9/06, Rich Smrcina <rsmrcina at wi.rr.com > wrote:
Sweet! Works for me too! Thanks.
Hubbard, Greg L wrote:
> Try using the "route" tag to set up the dependencies.Don't let all the > router talk in the documentation throw you... > > x.x.x.x hostA # ssh > y.y.y.y hostB # ssh route:hostA > > GLH > > -- 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 To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
thanks for the info, Greg. I guess I'll set up the PING (or CONN) test for that host then.
On 11/10/06, Hubbard, Greg L <greg.hubbard at eds.com> wrote:
I think the route tag will suppress some of the tests if conn fails. Otherwise you are out of luck. I believe that some sort of general "root cause" or "dependency-based suppression" is on Henrik's "to do" list (if I remember a previous post), but probably not at the top, and certainly not in the current version of the product.
GLH
*From:* Jerry Yu [mailto:jjj863 at gmail.com] *Sent:* Friday, November 10, 2006 12:34 PM *To:* hobbit at hswn.dk *Subject:* Re: [hobbit] depends tag?
we don't use ping at all. can I specify a service (ssh or other abitrary service) of hostA instead? In other words, will the following work? The man page of bb-hosts made it sounds like 'route:router1,route2' replies on ping or something?
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA.ssh
On 11/9/06, Rich Smrcina <rsmrcina at wi.rr.com > wrote:
Sweet! Works for me too! Thanks.
Hubbard, Greg L wrote:
Try using the "route" tag to set up the dependencies. Don't let all the router talk in the documentation throw you...
x.x.x.x hostA # ssh y.y.y.y hostB # ssh route:hostA
GLH
-- 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
participants (7)
-
etmsys＠rit.edu
-
greg.hubbard＠eds.com
-
JasonAS_Jones＠mentor.com
-
jjj863＠gmail.com
-
khustert＠csc.com
-
rsmrcina＠wi.rr.com
-
thomas.seglard.enata＠cnp.fr