ntpdate question
list Dirk Kastens
Hi, before updating our hobbit server to version 4.2.0, I tested the ntp configuration with the bb-ntp-1_4.sh script on the client nodes. When I now configure the server to use the ntp network test instead, I realize that this doesn't work with most of our RedHat clients. I get the response ntpdate -u -q -p 2 a.b.c.d server a.b.c.d, stratum 0, offset 0.000000, delay 0.00000 29 Aug 10:53:26 ntpdate[3509]: no server suitable for synchronization found The network test works with all AIX clients and with older RedHat clients. The manual page of ntpdate on a RedHat machine says, that "the ntpdate program is to be retired from this distribution". Is there another way of testing the ntp synchronisation from the server side or do I still have to use the bb-ntp.sh script? Best wishes, Dirk Kastens
list Charles Goyard
▸
Dirk Kastens a écrit :
Is there another way of testing the ntp synchronisation from the server side or do I still have to use the bb-ntp.sh script?
You can use the "time offset" in the CPU column to make sure your hosts are on-time. The gain is that all you hosts don't cry when you restart your ntp server, and you have one less script to maintain. -- Charles Goyard - user-98f9625a7a59@xymon.invalid - (+33) 1 45 38 01 31
list Nicolas Lienard
Hi I don't know if it has been already asked, but i ask :) i d like to know if it s possible to make a trigger for disk space when the space grows very fast. (that means there is a problem sometimes). For instance, if the disk space grows up to 20% in a small time (to specify) , there is an alert (warning or red alert). Thanks Regards, Nicolas LIENARD
list Henrik Størner
▸
On Tue, Aug 29, 2006 at 11:00:54AM +0200, Dirk Kastens wrote:
before updating our hobbit server to version 4.2.0, I tested the ntp configuration with the bb-ntp-1_4.sh script on the client nodes. When I now configure the server to use the ntp network test instead, I realize that this doesn't work with most of our RedHat clients. I get the response ntpdate -u -q -p 2 a.b.c.d server a.b.c.d, stratum 0, offset 0.000000, delay 0.00000 29 Aug 10:53:26 ntpdate[3509]: no server suitable for synchronization found
Funny, this is the second question about NTP checking this morning.
▸
The network test works with all AIX clients and with older RedHat clients. The manual page of ntpdate on a RedHat machine says, that "the ntpdate program is to be retired from this distribution". Is there another way of testing the ntp synchronisation from the server side or do I still have to use the bb-ntp.sh script?
Currently you have to use client-side scripts if the ntpdate program
does not work.
For the 4.2.0 release, ntp checking really was not on my mind. It
would make lots of sense to include the output from
ntpq -c "rv 0"
in the client output, and then process this on the server to pickup
the current synchronization status, stratum and clock offset, with
suitable configuration settings to trigger an alert if it loses sync
or the stratum gets too high.
You can regard that as a promise to improve this in a later version.
Regards,
Henrik
list Henrik Størner
▸
On Tue, Aug 29, 2006 at 11:33:46AM +0200, Nicolas wrote:
i d like to know if it s possible to make a trigger for disk space when the space grows very fast. (that means there is a problem sometimes). For instance, if the disk space grows up to 20% in a small time (to specify) , there is an alert (warning or red alert).
No. Hobbit currently only warns on the current level, not the trend in how fast disk utilisation is growing. Regards, Henrik
list Rolf Schrittenlocher
Hi Nicolas, it seems to be not too complicate to write a custom script for that purpose. Store the output of df -k in a temporary file, check the difference in an intervall and alert if something is growing fast.
▸
Hi I don't know if it has been already asked, but i ask :) i d like to know if it s possible to make a trigger for disk space when the space grows very fast. (that means there is a problem sometimes). For instance, if the disk space grows up to 20% in a small time (to specify) , there is an alert (warning or red alert). Thanks Regards, Nicolas LIENARD
--
Mit freundlichen Gruessen
Rolf Schrittenlocher
HRZ/BDV, Senckenberganlage 31, 60054 Frankfurt
Tel: (XX) XX - XXX XXXXX Fax: (XX) XX - XXX XXXXX
LBS: user-1e39a1813094@xymon.invalid
Persoenlich: user-6ea8e907e200@xymon.invalid
list Steve Aiello
Instead of storing the history data in temporary files, you could just fetch the data out of the RRD files.
▸
-----Original Message----- From: Rolf Schrittenlocher [mailto:user-af137d856faa@xymon.invalid] Sent: Tuesday, August 29, 2006 5:59 AM To: user-ae9b8668bcde@xymon.invalid Subject: Re: [hobbit] new feature ? Hi Nicolas, it seems to be not too complicate to write a custom script for that purpose. Store the output of df -k in a temporary file, check the difference in an intervall and alert if something is growing fast.Hi I don't know if it has been already asked, but i ask :) i d like to know if it s possible to make a trigger for disk space when >the space grows very fast. (that means there is a problem sometimes). For instance, if the disk space grows up to 20% in a small time (to specify) , there is an alert (warning or red alert). Thanks Regards, Nicolas LIENARD-- Mit freundlichen Gruessen Rolf Schrittenlocher HRZ/BDV, Senckenberganlage 31, 60054 Frankfurt Tel: (XX) XX - XXX XXXXX Fax: (XX) XX - XXX XXXXX LBS: user-1e39a1813094@xymon.invalid Persoenlich: user-6ea8e907e200@xymon.invalid
list Greg L Hubbard
One note -- the clock drift can be both positive and negative, but the graphs only show positive numbers. I am not sure if this is a "feature" in hobbitgraph, or rrdtool, or what. GLH
▸
-----Original Message-----
From: Charles Goyard [mailto:user-98f9625a7a59@xymon.invalid]
Sent: Tuesday, August 29, 2006 4:16 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] ntpdate question
Dirk Kastens a écrit :Is there another way of testing the ntp synchronisation from the server side or do I still have to use the bb-ntp.sh script?
You can use the "time offset" in the CPU column to make sure your hosts are on-time. The gain is that all you hosts don't cry when you restart your ntp server, and you have one less script to maintain. -- Charles Goyard - user-98f9625a7a59@xymon.invalid - (+33) 1 45 38 01 31
list Dirk Kastens
▸
Charles Goyard schrieb:
You can use the "time offset" in the CPU column to make sure your hosts are on-time. The gain is that all you hosts don't cry when you restart your ntp server, and you have one less script to maintain.
That's a good idea. I haven't discovered this feature, yet. Thanks. Dirk Kastens
list Nicolas Lienard
Thanks for answear; i ll make an external script as Rolf suggered. Regards, Nicolas
▸
No. Hobbit currently only warns on the current level, not the trend in how fast disk utilisation is growing. Regards, Henrik
list Vernon Everett
Hi Henrik
I would like to propose a possible new feature.
In the hobbit-clients.cfg on the server, we can specify default
threshholds for most things, but the selection is based on hostname.
Is there a way to specify the machine architecture as an identifier.
(uname -n
To give an example, I run a mixed bag of Sun T2000, V440, V490, and
X4?00 servers.
Because of what we are running on each server type, we find a large run
queue on the T2000 is quite normal, but on one of the others, we expect
a very small run queue.
Instead of defining runqueue threshhold per host name, it would be nice
to have a ARCH option which could be overridden by the HOST
So we could define
ARCH=x86_64 # Linux
LOAD 5.0 10
ARCH=i86pc # Solaris on x86
LOAD 6 12
ARCH=SUNW,SPARC-Enterprise # A solaris 10 zone
LOAD 8 12
ARCH=SUNW,Sun-Fire-V490 # A Sun V490
LOAD 6 9
ARCH=SUNW,Sun-Fire-T200 # A T2000 reports as T200 - don't ask!
LOAD 15 25
However, if further down the list we had a HOST server01 we could
redefine the LOAD, despite it being a T2000.
HOST=server01
LOAD 10 15
The utility of this would mean I don't have to define every host
inividually, but
Of course, we could also use the same definitions for OS as returned by
uname -s
SunOS, Linux etc. (I see you use this in the client scripts)
It would be nice to have that flexibility in the configs.
Regards
Vernon
NOTICE: This email and any attachments are confidential.
They may contain legally privileged information or
copyright material. You must not read, copy, use or
disclose them without authorisation. If you are not an
intended recipient, please contact us at once by return
email and then delete both messages and all attachments.
list Buchan Milne
▸
On Wednesday 28 November 2007 08:01:44 Everett, Vernon wrote:
Hi Henrik I would like to propose a possible new feature. In the hobbit-clients.cfg on the server, we can specify default threshholds for most things, but the selection is based on hostname. Is there a way to specify the machine architecture as an identifier. (uname -n To give an example, I run a mixed bag of Sun T2000, V440, V490, and X4?00 servers. Because of what we are running on each server type, we find a large run queue on the T2000 is quite normal, but on one of the others, we expect a very small run queue. Instead of defining runqueue threshhold per host name, it would be nice to have a ARCH option which could be overridden by the HOST
But, IMHO, the threshold should be dependant more on the number of CPUs, rather than on the architecture. For example, we have a higher threshold on our X4600s (8 physical, dual core) than our X4100s/X4200s (2 physical, some dual-core). How many CPUs does the Sun T2000 have/report ? Regards, Buchan
list S Aiello
▸
On Wednesday 28 November 2007, Buchan Milne wrote:
But, IMHO, the threshold should be dependant more on the number of CPUs, rather than on the architecture. For example, we have a higher threshold on our X4600s (8 physical, dual core) than our X4100s/X4200s (2 physical, some dual-core). How many CPUs does the Sun T2000 have/report ?
I believe the T2000s report 32 processors, in reality there is only 1. 1 x 8 cores x 4 concurrent threads capable. But for all our devices we normally set our LA thresholds by the folowing formula: Warn: #CPU x 1 Panic: #CPU x 1.5 My hobbit-clients.cfg would be alot smaller if in the default section, if I could use a formula definition for LOAD instead of a hardcoded section.
▸
Instead of defining runqueue threshhold per host name, it would be nice to have a ARCH option which could be overridden by the HOST
You could hardcode the client's CLASS option to it's arch, and be able to do what you propose. ~Steve
list Tom L. Stewart
If you can have a standard host name convention, then you could use a regex. Tom
▸
-----Original Message-----
From: user-ce96540ed38f@xymon.invalid [mailto:user-ce96540ed38f@xymon.invalid]
Sent: Wednesday, November 28, 2007 4:11 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] New feature ?
On Wednesday 28 November 2007, Buchan Milne wrote:But, IMHO, the threshold should be dependant more on the number of CPUs, rather than on the architecture. For example, we have a higher threshold on our X4600s (8 physical, dual core) than our X4100s/X4200s
(2 physical, some dual-core). How many CPUs does the Sun T2000 have/report ?
I believe the T2000s report 32 processors, in reality there is only 1. 1 x 8 cores x 4 concurrent threads capable. But for all our devices we normally set our LA thresholds by the folowing formula: Warn: #CPU x 1 Panic: #CPU x 1.5 My hobbit-clients.cfg would be alot smaller if in the default section, if I could use a formula definition for LOAD instead of a hardcoded section.
Instead of defining runqueue threshhold per host name, it would be nice
to have a ARCH option which could be overridden by the HOST
You could hardcode the client's CLASS option to it's arch, and be able to do what you propose. ~Steve
list Vernon Everett
Hi Henrik
I have looked at the responses to my proposal, and based on that, and a
little more thought overnight, I would like to modify my proposal.
What if we have a "script" on the server, which gets run on the client,
and all definitions gathered from that "script" become available at the
server?
The script could be pseudo code (or real code) defining what variables
need to be set at server level, and how they are derived at the client
level.
For example.
ARCH=`uname -i`
PROCTYPE=`uname -p`
It starts getting more interesting once you need to define number of
processors, because it depends on your OS how you derive that info.
On SunOS it would be `psrinfo | wc -l`
On RedHat, it would probably be `dmidecode | grep "Central Processor" |
wc -l`
There may be another way - Red Hat admins can you help?
Probably need to use a case statement, like you use at the client.
This method will allow an administrator to define anything they want,
not just limited to hardware info.
HAS_A_GUI=`grep -v"^#" /etc/inittab | grep X11`
(I know, it's a silly example, but I only used it as an illustration of
what is possible)
I have no idea how this could be implemented in an elegant fashion, but
I think that's why I am a Sysadmin/DBA, and not a developer :-)
Regards
Vernon
▸
-----Original Message-----
From: Stewart, Tom L. [mailto:user-f210f371749e@xymon.invalid]
Sent: Wednesday, 28 November 2007 11:36 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] New feature ?
If you can have a standard host name convention, then you could use a
regex.
Tom
-----Original Message-----
From: user-ce96540ed38f@xymon.invalid [mailto:user-ce96540ed38f@xymon.invalid]
Sent: Wednesday, November 28, 2007 4:11 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] New feature ?
On Wednesday 28 November 2007, Buchan Milne wrote:But, IMHO, the threshold should be dependant more on the number of CPUs, rather than on the architecture. For example, we have a higher threshold on our X4600s (8 physical, dual core) than our X4100s/X4200s
(2 physical, some dual-core). How many CPUs does the Sun T2000 have/report ?
I believe the T2000s report 32 processors, in reality there is only 1. 1 x 8 cores x 4 concurrent threads capable. But for all our devices we normally set our LA thresholds by the folowing formula: Warn: #CPU x 1 Panic: #CPU x 1.5 My hobbit-clients.cfg would be alot smaller if in the default section, if I could use a formula definition for LOAD instead of a hardcoded section.
Instead of defining runqueue threshhold per host name, it would be nice
to have a ARCH option which could be overridden by the HOST
You could hardcode the client's CLASS option to it's arch, and be able to do what you propose. ~Steve NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.
list Asif Iqbal
▸
On 8/29/06, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:
On Tue, Aug 29, 2006 at 11:00:54AM +0200, Dirk Kastens wrote:before updating our hobbit server to version 4.2.0, I tested the ntp configuration with the bb-ntp-1_4.sh script on the client nodes. When I now configure the server to use the ntp network test instead, I realize that this doesn't work with most of our RedHat clients. I get the response ntpdate -u -q -p 2 a.b.c.d server a.b.c.d, stratum 0, offset 0.000000, delay 0.00000 29 Aug 10:53:26 ntpdate[3509]: no server suitable for synchronization foundFunny, this is the second question about NTP checking this morning.The network test works with all AIX clients and with older RedHat clients. The manual page of ntpdate on a RedHat machine says, that "the ntpdate program is to be retired from this distribution". Is there another way of testing the ntp synchronisation from the server side or do I still have to use the bb-ntp.sh script?Currently you have to use client-side scripts if the ntpdate program does not work. For the 4.2.0 release, ntp checking really was not on my mind. It would make lots of sense to include the output from ntpq -c "rv 0" in the client output, and then process this on the server to pickup the current synchronization status, stratum and clock offset, with suitable configuration settings to trigger an alert if it loses sync or the stratum gets too high. You can regard that as a promise to improve this in a later version.
Excellent!
Regards, Henrik
-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu