ntp check expansion thoughts
list Tracy di Marco White
We're a kerberos based shop, which means everything authenticating to kerberos needs to be within 5 minutes of our kerberos server's clock. We recently had problems with a few important servers having severe time keeping problems, as well as two of our time servers not keeping sync because of multiprocessor issues. For a lot of our servers it'd be nice to warn if time is more than a minute or two out from our reference clock on the kerberos servers, and go red at four or five minutes out. But it'd also be nice to have a warning if our central time servers are having problems keeping sync, or having other problems (I'm not intimately familiar with ntp, so I'm not sure what problems those could be). I think the ntp check right now only checks that ntp is running. It would be nice to check that there's a valid sys.peer, and maybe some number of acceptable candidates, maybe that the offset and jitter are within some reasonable parameters for the peers/servers. I'm mostly just thinking about implementing something like this at the moment, maybe someone already has this, or maybe there's a better way to think about this, so I'd appreciate input on it. Tracy J. Di Marco White Information Technology Services Iowa State University
list Larry Barber
There's an ntp script available on deadcat that I believe does what you
require (warning, html coming up):
Tue Jan 24 10:19:52 CST 2006 Clock is synchronized
Clock offset
(ms)Jitter
(ms)Clock drift
(ppm)Residual drift
(ppm)Stratum[image: green] 0.4850.126[image: green] -130.957[image:
green] 0.002[image: green] 2
ServerRefidStratumReachDelay
(ms)Jitter
(ms)Offset
(ms)Dispersion
(ms)Status165.221.90.22CDMA[image: green] 13770.8920.094[image: green]
0.48514.847[image: green] sel_sys.peerLOCAL(0)LOCAL(0)[image: green]
103770.0000.008[image: green] 0.0000.948[image: clear] unknown
NTP version: ntpd 4.1.2 at 1.892
bb-ntp.sh Version:0.9.2
Thanks,
Larry Barber
▸
On 1/24/06, Tracy Di Marco White <user-4d3c8321d54f@xymon.invalid> wrote:We're a kerberos based shop, which means everything authenticating to kerberos needs to be within 5 minutes of our kerberos server's clock. We recently had problems with a few important servers having severe time keeping problems, as well as two of our time servers not keeping sync because of multiprocessor issues. For a lot of our servers it'd be nice to warn if time is more than a minute or two out from our reference clock on the kerberos servers, and go red at four or five minutes out. But it'd also be nice to have a warning if our central time servers are having problems keeping sync, or having other problems (I'm not intimately familiar with ntp, so I'm not sure what problems those could be). I think the ntp check right now only checks that ntp is running. It would be nice to check that there's a valid sys.peer, and maybe some number of acceptable candidates, maybe that the offset and jitter are within some reasonable parameters for the peers/servers. I'm mostly just thinking about implementing something like this at the moment, maybe someone already has this, or maybe there's a better way to think about this, so I'd appreciate input on it. Tracy J. Di Marco White Information Technology Services Iowa State University
list Richard Deal
I use server-time-ntp.0.9.2.3.tar.gz from deadcat to do just that.
▸
-----Original Message----- From: user-4d3c8321d54f@xymon.invalid [mailto:user-4d3c8321d54f@xymon.invalid] Sent: Tuesday, January 24, 2006 11:16 AM To: user-ae9b8668bcde@xymon.invalid Subject: [hobbit] ntp check expansion thoughts We're a kerberos based shop, which means everything authenticating to kerberos needs to be within 5 minutes of our kerberos server's clock. We recently had problems with a few important servers having severe time keeping problems, as well as two of our time servers not keeping sync because of multiprocessor issues. For a lot of our servers it'd be nice to warn if time is more than a minute or two out from our reference clock on the kerberos servers, and go red at four or five minutes out. But it'd also be nice to have a warning if our central time servers are having problems keeping sync, or having other problems (I'm not intimately familiar with ntp, so I'm not sure what problems those could be). I think the ntp check right now only checks that ntp is running. It would be nice to check that there's a valid sys.peer, and maybe some number of acceptable candidates, maybe that the offset and jitter are within some reasonable parameters for the peers/servers. I'm mostly just thinking about implementing something like this at the moment, maybe someone already has this, or maybe there's a better way to think about this, so I'd appreciate input on it. Tracy J. Di Marco White Information Technology Services Iowa State University
list Paul Williamson
Craig Cook's ntp check on deadcat has an option to check all hosts. I do this from one of my BBNET (not running Hobbit, so I don't know if it will work for you) servers, checking all 8 of our time servers from one BBNET server. Of course, this is from the reference point of the BBNET server, but it would be a start to where you want to go. Paul
user-4d3c8321d54f@xymon.invalid 01/24/06 11:15 AM >>>
▸
We're a kerberos based shop, which means everything authenticating to kerberos needs to be within 5 minutes of our kerberos server's clock. We recently had problems with a few important servers having severe time keeping problems, as well as two of our time servers not keeping sync because of multiprocessor issues. For a lot of our servers it'd be nice to warn if time is more than a minute or two out from our reference clock on the kerberos servers, and go red at four or five minutes out. But it'd also be nice to have a warning if our central time servers are having problems keeping sync, or having other problems (I'm not intimately familiar with ntp, so I'm not sure what problems those could be). I think the ntp check right now only checks that ntp is running. It would be nice to check that there's a valid sys.peer, and maybe some number of acceptable candidates, maybe that the offset and jitter are within some reasonable parameters for the peers/servers. I'm mostly just thinking about implementing something like this at the moment, maybe someone already has this, or maybe there's a better way to think about this, so I'd appreciate input on it. Tracy J. Di Marco White Information Technology Services Iowa State University