CLOCK and CPU test
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I suspect I know the answer to this but want to check:
I'm running Xymon 4.3.12. My manager has recently brought up the need to have the clock drift monitored (it caused problems with a DB server when there was massive drift once for some reason). I looked into how to do this and it looks like the highest level that clock drift can cause Xymon to alert at is yellow. This means that if I wanted to be alerted, I'd have to also get alerted for yellow CPU on that machine, right? So far my only idea is to raise the yellow level for CPU. I don't really want to bother with an external test.
Any tips?
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJDOxQACgkQmb+gadEcsb4kIACePC1gBVn4bTvMJFmyinpmcAz4 Ve4AnjMZ+B/CN3zdMFYJVdtBlS3iDUvj =+9dQ -----END PGP SIGNATURE-----
On Wed, September 25, 2013 12:35 pm, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I suspect I know the answer to this but want to check:
I'm running Xymon 4.3.12. My manager has recently brought up the need to have the clock drift monitored (it caused problems with a DB server when there was massive drift once for some reason). I looked into how to do this and it looks like the highest level that clock drift can cause Xymon to alert at is yellow. This means that if I wanted to be alerted, I'd have to also get alerted for yellow CPU on that machine, right? So far my only idea is to raise the yellow level for CPU. I don't really want to bother with an external test.
Any tips?
According to http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html you should be able to add a line like
CLOCK 15 red
... to an analysis.cfg file (or *.d/ entry) to have it go red if the clock delta exceeds that absolute value. I have to admit not having tested that ever though.
If that doesn't work, you might be able to simulate it (or assign the color to a different test entirely) with a DS entry; something like:
DS cpu clock.rrd:la <-15 COLOR=red "TEXT=System clock is &V seconds off" DS cpu clock.rrd:la >15 COLOR=red "TEXT=System clock is &V seconds off"
HTH,
-jc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 04:16 PM, Japheth Cleaver wrote:
On Wed, September 25, 2013 12:35 pm, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I suspect I know the answer to this but want to check:
I'm running Xymon 4.3.12. My manager has recently brought up the need to have the clock drift monitored (it caused problems with a DB server when there was massive drift once for some reason). I looked into how to do this and it looks like the highest level that clock drift can cause Xymon to alert at is yellow. This means that if I wanted to be alerted, I'd have to also get alerted for yellow CPU on that machine, right? So far my only idea is to raise the yellow level for CPU. I don't really want to bother with an external test.
Any tips?
According to http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html you should be able to add a line like
CLOCK 15 red
... to an analysis.cfg file (or *.d/ entry) to have it go red if the clock delta exceeds that absolute value. I have to admit not having tested that ever though.
If that doesn't work, you might be able to simulate it (or assign the color to a different test entirely) with a DS entry; something like:
DS cpu clock.rrd:la <-15 COLOR=red "TEXT=System clock is &V seconds off" DS cpu clock.rrd:la >15 COLOR=red "TEXT=System clock is &V seconds off"
Wonderful! I must have been reading an old copy of that documentation (Google'd for it instead of using what was on the system). Thanks Japheth!
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJDRdAACgkQmb+gadEcsb61SQCaAgCrteviCwy+bUMIdDqsp0gd +N8AoL9Wy6srB22AS1kA9iWdus++2gJZ =d+Pi -----END PGP SIGNATURE-----
Just FYI, the clock drift is measured by comparing the date/time sent at the bottom of the client message against the Xymon server clock. I have some systems on slow network connections and sometimes it takes a couple of retries for the status report to get through, and by then the client time is often 10 - 30 seconds adrift.
In other words, it's not simply the client working out that its own clock is slow.
Ralph Mitchell On Sep 25, 2013 4:22 PM, "Novosielski, Ryan" <novosirj at ca.rutgers.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 04:16 PM, Japheth Cleaver wrote:
On Wed, September 25, 2013 12:35 pm, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I suspect I know the answer to this but want to check:
I'm running Xymon 4.3.12. My manager has recently brought up the need to have the clock drift monitored (it caused problems with a DB server when there was massive drift once for some reason). I looked into how to do this and it looks like the highest level that clock drift can cause Xymon to alert at is yellow. This means that if I wanted to be alerted, I'd have to also get alerted for yellow CPU on that machine, right? So far my only idea is to raise the yellow level for CPU. I don't really want to bother with an external test.
Any tips?
According to http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html you should be able to add a line like
CLOCK 15 red
... to an analysis.cfg file (or *.d/ entry) to have it go red if the clock delta exceeds that absolute value. I have to admit not having tested that ever though.
If that doesn't work, you might be able to simulate it (or assign the color to a different test entirely) with a DS entry; something like:
DS cpu clock.rrd:la <-15 COLOR=red "TEXT=System clock is &V seconds off" DS cpu clock.rrd:la >15 COLOR=red "TEXT=System clock is &V seconds off"
Wonderful! I must have been reading an old copy of that documentation (Google'd for it instead of using what was on the system). Thanks Japheth!
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJDRdAACgkQmb+gadEcsb61SQCaAgCrteviCwy+bUMIdDqsp0gd +N8AoL9Wy6srB22AS1kA9iWdus++2gJZ =d+Pi -----END PGP SIGNATURE-----
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 9/25/2013 2:05 PM, Ralph Mitchell wrote:
Just FYI, the clock drift is measured by comparing the date/time sent at the bottom of the client message against the Xymon server clock. I have some systems on slow network connections and sometimes it takes a couple of retries for the status report to get through, and by then the client time is often 10 - 30 seconds adrift.
In other words, it's not simply the client working out that its own clock is slow.
I know that Ryan specifically said he didn't want to go the route of an ext script. I mention this here for others who may search the archives for this topic.
I use an ext script which looks at the output of "/usr/sbin/xntpdc -sn" It sends a yellow if the clock has drifted more than a second or is synchronized at a stratum greater than 9. It sends a red if the clock has drifted more than five seconds.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
Mine always work very well, so at least in my environment, this isn't a concern. It is rare to see anything but 0s.
From: Ralph Mitchell [mailto:ralphmitchell at gmail.com] Sent: Wednesday, September 25, 2013 06:05 PM To: Novosielski, Ryan Cc: Japheth Cleaver <cleaver at terabithia.org>; xymon at xymon.com <xymon at xymon.com> Subject: Re: [Xymon] CLOCK and CPU test
Just FYI, the clock drift is measured by comparing the date/time sent at the bottom of the client message against the Xymon server clock. I have some systems on slow network connections and sometimes it takes a couple of retries for the status report to get through, and by then the client time is often 10 - 30 seconds adrift.
In other words, it's not simply the client working out that its own clock is slow.
Ralph Mitchell
On Sep 25, 2013 4:22 PM, "Novosielski, Ryan" <novosirj at ca.rutgers.edu<mailto:novosirj at ca.rutgers.edu>> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 04:16 PM, Japheth Cleaver wrote:
On Wed, September 25, 2013 12:35 pm, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I suspect I know the answer to this but want to check:
I'm running Xymon 4.3.12. My manager has recently brought up the need to have the clock drift monitored (it caused problems with a DB server when there was massive drift once for some reason). I looked into how to do this and it looks like the highest level that clock drift can cause Xymon to alert at is yellow. This means that if I wanted to be alerted, I'd have to also get alerted for yellow CPU on that machine, right? So far my only idea is to raise the yellow level for CPU. I don't really want to bother with an external test.
Any tips?
According to http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html you should be able to add a line like
CLOCK 15 red
... to an analysis.cfg file (or *.d/ entry) to have it go red if the clock delta exceeds that absolute value. I have to admit not having tested that ever though.
If that doesn't work, you might be able to simulate it (or assign the color to a different test entirely) with a DS entry; something like:
DS cpu clock.rrd:la <-15 COLOR=red "TEXT=System clock is &V seconds off" DS cpu clock.rrd:la >15 COLOR=red "TEXT=System clock is &V seconds off"
Wonderful! I must have been reading an old copy of that documentation (Google'd for it instead of using what was on the system). Thanks Japheth!
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu<mailto:novosirj at rutgers.edu> - 973/972.0922<tel:973%2F972.0922> (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJDRdAACgkQmb+gadEcsb61SQCaAgCrteviCwy+bUMIdDqsp0gd +N8AoL9Wy6srB22AS1kA9iWdus++2gJZ =d+Pi -----END PGP SIGNATURE-----
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 04:21 PM, Novosielski, Ryan wrote:
According to
http://www.xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html you should be able to add a line like
CLOCK 15 red
... to an analysis.cfg file (or *.d/ entry) to have it go red if the clock delta exceeds that absolute value. I have to admit not having tested that ever though.
If that doesn't work, you might be able to simulate it (or assign the color to a different test entirely) with a DS entry; something like:
DS cpu clock.rrd:la <-15 COLOR=red "TEXT=System clock is &V seconds off" DS cpu clock.rrd:la >15 COLOR=red "TEXT=System clock is &V seconds off" Wonderful! I must have been reading an old copy of that documentation (Google'd for it instead of using what was on the system). Thanks Japheth!
On a related note, is there a good way to make sure this is being picked up? CLOCK does not show up in the config report (and apparently no local tests do, according to the bugs on confreport.cgi).
I used a regex for the servers is is to apply to (obscured):
HOST=%.*(server|devmach).*.umdnj.edu
...which is supposed to pick up loc1serverA.umdnj.edu, loc2serverB.umdnj.edu, and loc1devmach.umdnj.edu. pcretest would seem to confrm that this works right, if I understand how THAT works.
However, I tried adding a FILE test that would turn files yellow if a file that doesn't exist doesn't exist and that didn't work, so I'm now questioning my regex.
____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJElQ4ACgkQmb+gadEcsb5n4QCghiyLmFlKT/iHOUfSRljltkI4 kmYAn0qaKu8wpi5pz/GlMwiZEMa0wB+D =jHTi -----END PGP SIGNATURE-----
participants (4)
-
cleaver＠terabithia.org
-
john.thurston＠alaska.gov
-
novosirj＠ca.rutgers.edu
-
ralphmitchell＠gmail.com