Feature - NTP stratum too high - test shows yellow
list John Horne
Hello, Using Xymon 4.3.7 the NTP test currently shows a green result if the NTP daemon is running, and red if not. However, what we want to know is if the NTP daemon is running, but not synchronised to any high stratum clock. When this happens the NTP daemon will return time based on the servers own local clock (if so configured), and this will usually be a low stratum value (on RHEL/CentOS this is stratum 10). We don't want this, and want to be warned if it happens. Attached is a patch which will allow admins to specify at what stratum level the 'ntp' test should turn yellow. If the returned stratum value (from 'ntpdate') is greater than or equal to the given value, then the 'ntp' test will show yellow. If the stratum is not specified, then the ntp test uses the default behaviour (that is, no test of the stratum value). This does not work if sntp is used. I had a look at this, but it seems that older versions of sntp did not return the stratum value. New versions do, but as far as I can gather sntp is not usually supplied because of licensing problems. John. -- John Horne Tel: +XX (X)XXXX XXXXXX Plymouth University, UK Fax: +XX (X)XXXX XXXXXX
list Josh Luthman
Wow! Great work! Thank you for sharing. Josh Luthman Office: XXX-XXX-XXXX Direct: XXX-XXX-XXXX XXXX Wayne St Suite XXXX Troy, OH XXXXX
▸
On Apr 11, 2012 9:52 AM, "John Horne" <user-e95f1ec2f147@xymon.invalid> wrote:
Hello, Using Xymon 4.3.7 the NTP test currently shows a green result if the NTP daemon is running, and red if not. However, what we want to know is if the NTP daemon is running, but not synchronised to any high stratum clock. When this happens the NTP daemon will return time based on the servers own local clock (if so configured), and this will usually be a low stratum value (on RHEL/CentOS this is stratum 10). We don't want this, and want to be warned if it happens. Attached is a patch which will allow admins to specify at what stratum level the 'ntp' test should turn yellow. If the returned stratum value (from 'ntpdate') is greater than or equal to the given value, then the 'ntp' test will show yellow. If the stratum is not specified, then the ntp test uses the default behaviour (that is, no test of the stratum value). This does not work if sntp is used. I had a look at this, but it seems that older versions of sntp did not return the stratum value. New versions do, but as far as I can gather sntp is not usually supplied because of licensing problems. John. -- John Horne Tel: +XX (X)XXXX XXXXXX Plymouth University, UK Fax: +XX (X)XXXX XXXXXX
list Paul Root
Nice. I'll have to try that. Paul Root - Senior Engineer Managed Services Systems - CenturyLink
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of John Horne Sent: Wednesday, April 11, 2012 8:52 AM To: xymon at xymon.com Subject: [Xymon] Feature - NTP stratum too high - test shows yellow
▸
Hello,
Using Xymon 4.3.7 the NTP test currently shows a green result if the
NTP
daemon is running, and red if not. However, what we want to know is if
the NTP daemon is running, but not synchronised to any high stratum
clock. When this happens the NTP daemon will return time based on the
servers own local clock (if so configured), and this will usually be a
low stratum value (on RHEL/CentOS this is stratum 10). We don't want
this, and want to be warned if it happens.
Attached is a patch which will allow admins to specify at what stratum
level the 'ntp' test should turn yellow. If the returned stratum value
(from 'ntpdate') is greater than or equal to the given value, then the
'ntp' test will show yellow. If the stratum is not specified, then the
ntp test uses the default behaviour (that is, no test of the stratum
value).
This does not work if sntp is used. I had a look at this, but it seems
that older versions of sntp did not return the stratum value. New
versions do, but as far as I can gather sntp is not usually supplied
because of licensing problems.
John.
--
John Horne Tel: +XX (X)XXXX XXXXXX
Plymouth University, UK Fax: +XX (X)XXXX XXXXXXThis communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
list Mark Deiss
I am running into an issue with my 4.33 and 4.37 Xymon servers with the received disk test results. I am running cases of either the BB df test or the Xymonclient module that reports df results. In both cases, the header line from the df output is being processed into an rrd database file and into graph entries (on 4.33 and 4.37 servers). I am not seeing this bahaviour with the Xymon demo site; the df header line is appearing in the disk detail web page; the graphs look fine there. Which file(s) should I be looking at where the df header line should be suppressed for rrd purposes? I thought maybe this would be defined in one of the configuration files but now am thinking it may be explicitly handled in of the C binaries. Googling around I see where there is mention of special filters required for usage with custom scripts but no mention on how the standard tests are being massaged to eliminate chaff lines.
list Mark Deiss
It looks like I need to spend time with the xymond/rrd/do_disk.c source code. I can see where the code would have an issue handling the BB test variant. Have not figured out why the xymonclient df report section would also be acting up.
▸
-----Original Message-----
From: Deiss, Mark
Sent: Wednesday, April 11, 2012 10:51 AM
To: xymon at xymon.com
Subject: Question on rrd parsing of disk report
I am running into an issue with my 4.33 and 4.37 Xymon servers with the
received disk test results. I am running cases of either the BB df test
or the Xymonclient module that reports df results. In both cases, the
header line from the df output is being processed into an rrd database
file and into graph entries (on 4.33 and 4.37 servers).
I am not seeing this bahaviour with the Xymon demo site; the df header
line is appearing in the disk detail web page; the graphs look fine
there.
Which file(s) should I be looking at where the df header line should be
suppressed for rrd purposes? I thought maybe this would be defined in
one of the configuration files but now am thinking it may be explicitly
handled in of the C binaries.
Googling around I see where there is mention of special filters required
for usage with custom scripts but no mention on how the standard tests
are being massaged to eliminate chaff lines.
list Henrik Størner
▸
On 11-04-2012 16:51, Deiss, Mark wrote:
I am running into an issue with my 4.33 and 4.37 Xymon servers with the received disk test results. I am running cases of either the BB df test or the Xymonclient module that reports df results. In both cases, the header line from the df output is being processed into an rrd database file and into graph entries (on 4.33 and 4.37 servers).
Could you send me an example of the output from the Xymon client ? Click on the "client data" link in the disk status message and then mail me the output from the "[df]" section. Regards, Henrik
list Henrik Størner
▸
On 11-04-2012 15:52, John Horne wrote:
Attached is a patch which will allow admins to specify at what stratum level the 'ntp' test should turn yellow. If the returned stratum value (from 'ntpdate') is greater than or equal to the given value, then the 'ntp' test will show yellow. If the stratum is not specified, then the ntp test uses the default behaviour (that is, no test of the stratum value).
Thanks, very nice - you even updated the documentation! Bonus points for that :-) Unfortunately all of the "xymonnet" code is being ripped apart currently and especially the ntp tests have been completely re-done now; they no longer require any external binaries - the NTP protocol code is built-in. And the configuration files will probably change as well. But I'll make sure that the NTP stratum can also be checked in the new version. Regards, Henrik
list John Horne
On Wed, 2012-04-11 at 09:55 -0400, Josh Luthman wrote:
Wow! Great work! Thank you for sharing.
Thank you. However, it is simply offered to the Xymon developers for consideration :-) It may be that there is a better way to do this. A couple of points I perhaps should have mentioned are that: 1) 'ntpdate' (used in the 'ntp' test) is somewhat deprecated. Although the use of 'ntpd -q' is suggested instead, as far as I can tell this does not do what we want (i.e. return the stratum value). As such, it may be better to use something like 'ntpq -nc peers <host>' for the 'ntp' test to list the NTP peers, and then process that output. Fortunately it shows the peers in use, and their stratum levels. 2) Making it work with sntp may be nice :-) (As said the sntp output in later versions does show the stratum level - on the end of the output line I gather.)
▸
John.
--
John Horne Tel: +XX (X)XXXX XXXXXX
Plymouth University, UK Fax: +XX (X)XXXX XXXXXX
list John Horne
▸
On Wed, 2012-04-11 at 17:20 +0200, Henrik Størner wrote:
Unfortunately all of the "xymonnet" code is being ripped apart currently and especially the ntp tests have been completely re-done now;
Oh! I looked at what I thought was the SVN code and it didn't seem to have changed much (from the supplied 4.3.7 code). I went to http://www.xymon.com and clicked on the 'Xymon Project' link, then 'SVN browser' and finally on 'trunk'. I assumed this was showing me the latest code.
But I'll make sure that the NTP stratum can also be checked in the new version.
Thanks :-)
▸
John.
--
John Horne Tel: +XX (X)XXXX XXXXXX
Plymouth University, UK Fax: +XX (X)XXXX XXXXXX
list Henrik Størner
▸
On 11-04-2012 17:35, John Horne wrote:
On Wed, 2012-04-11 at 17:20 +0200, Henrik Størner wrote:Unfortunately all of the "xymonnet" code is being ripped apart currently and especially the ntp tests have been completely re-done now;Oh! I looked at what I thought was the SVN code and it didn't seem to have changed much (from the supplied 4.3.7 code). I went to http://www.xymon.com and clicked on the 'Xymon Project' link, then 'SVN browser' and finally on 'trunk'. I assumed this was showing me the latest code.
It is ... and the xymonnet.c file hasn't changed, that is correct. But there is a new xymonnet2.c file (and a bunch of other new files) - try sorting the file list by "Age" and you'll see where all the action is. I just haven't deleted the old ones yet. Perhaps I should. Regards, Henrik
list John Horne
▸
On Wed, 2012-04-11 at 18:00 +0200, Henrik Størner wrote:
On 11-04-2012 17:35, John Horne wrote:On Wed, 2012-04-11 at 17:20 +0200, Henrik Størner wrote:Unfortunately all of the "xymonnet" code is being ripped apart currently and especially the ntp tests have been completely re-done now;Oh! I looked at what I thought was the SVN code and it didn't seem to have changed much (from the supplied 4.3.7 code). I went to http://www.xymon.com and clicked on the 'Xymon Project' link, then 'SVN browser' and finally on 'trunk'. I assumed this was showing me the latest code.It is ... and the xymonnet.c file hasn't changed, that is correct. But there is a new xymonnet2.c file (and a bunch of other new files) - try sorting the file list by "Age" and you'll see where all the action is.
Ah, okay. Thanks for that.
▸
John.
--
John Horne Tel: +XX (X)XXXX XXXXXX
Plymouth University, UK Fax: +XX (X)XXXX XXXXXX