On Mon, 2012-09-17 at 07:59 -0400, Ralph Mitchell wrote:

I think white typically show up for tests that are dependent on some other test. For example, the network tests do that. I've recently had some ping failures, so ssh came up white, but the client tests (cpu, memory,disk, ports, procs) all came through OK.

Okay. But as far as I remember the 'procs' and 'files' tests default to white. When the server is first installed there are no defined processes or files to monitor so the tests go white.

For these tests the data comes from the client via the large status text file sent to the server. Since we got an 'oversize' message, not all the data was available. So I assume none of the 'procs' stuff was there, so the test went purple because it hadn't seen anything for a while. The 'files' test, I assume, had some data, but not enough to give a result of the test. So the test went white. (Note, I *assume* that is how it works :-))

Anyway, my point is that I would like to know if a test goes white regardless of the reason. It is an indication that 'something is not right', yet because we tend to keep an eye on the 'non-green' page we were unaware, in this case, that the 'files' test had gone white.

John.

-- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 09/17/2012 10:56 AM, Ryan Novosielski wrote:

On 09/17/2012 08:30 AM, John Horne wrote:

...

On Mon, 2012-09-17 at 07:59 -0400, Ralph Mitchell wrote:

...

I think white typically show up for tests that are dependent on some other test. For example, the network tests do that. I've recently had some ping failures, so ssh came up white, but the client tests (cpu, memory,disk, ports, procs) all came through OK.

Okay. But as far as I remember the 'procs' and 'files' tests default to white. When the server is first installed there are no defined processes or files to monitor so the tests go white.

...

For these tests the data comes from the client via the large status text file sent to the server. Since we got an 'oversize' message, not all the data was available. So I assume none of the 'procs' stuff was there, so the test went purple because it hadn't seen anything for a while. The 'files' test, I assume, had some data, but not enough to give a result of the test. So the test went white. (Note, I *assume* that is how it works :-))

...

Anyway, my point is that I would like to know if a test goes white regardless of the reason. It is an indication that 'something is not right', yet because we tend to keep an eye on the 'non-green' page we were unaware, in this case, that the 'files' test had gone white.

While likely not what you're looking for, the test is called "clear" and you can search for it under "Reports / Event log report" if you want to see all events involving clear (though at least in my version, 4.2.3, it shows both coming FROM clear and going TO clear).

You can at least use this to see if the issue is widespread.

Excuse me, that should have said the COLOR is called "clear".

• ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBXOnUACgkQmb+gadEcsb4n8ACfUar+uMwpzCKnHFUi+FMjnkfz LRQAn2/9kOsCNh6JvZzrHWbcEmAiahB5 =ftb4 -----END PGP SIGNATURE-----

On Tue, 2012-09-18 at 08:34 +0200, Thomas Kähn wrote:

Hi John,

On Mon, Sep 17, 2012 at 11:41:07AM +0100, John Horne wrote:

...

Is there a way to report a test as purple if it changes from a colour to white?

I'm not sure why it reported white and not purple. The status report from the client was truncated, and I assume the 'files' test, therefore, received no status.

according to the documentation it is possible to tweak the behaviour a little bit:

http://xymon.sourceforge.net/xymon/help/manpages/man8/xymond_client.8.html

So if you set --no-clear-files the column probably would have switched to purple instead of clear.

Hello,

Thanks for this. However, the man page says:

=========== If there are no file checks, the "files" column will show a "clear" status. If you would rather avoid having a "files" column, this option causes xymond_client to not send in a clear "files" status.

which is a little confusing. We have files to check, and the 'files' column already exists (from previous results). So does this option prevent a *subsequent* status for 'files' from showing white/clear but will default to purple as with other tests. If so, then yes this seems like what we want.

I think I need to experiment a little with it.

John.

-- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

On Tue, 2012-09-18 at 08:34 +0200, Thomas Kähn wrote:

Hi John,

On Mon, Sep 17, 2012 at 11:41:07AM +0100, John Horne wrote:

...

Is there a way to report a test as purple if it changes from a colour to white?

I'm not sure why it reported white and not purple. The status report from the client was truncated, and I assume the 'files' test, therefore, received no status.

according to the documentation it is possible to tweak the behaviour a little bit:

http://xymon.sourceforge.net/xymon/help/manpages/man8/xymond_client.8.html

So if you set --no-clear-files the column probably would have switched to purple instead of clear.

Hello,

Yes, the above option does cause the test to show purple instead of clear/white (and hence appears on the 'non-green' page). Many thanks for that.

There is also the option '--clear-color', which could be set to red or yellow. Setting it to purple is accepted, but xymond then ignores receiving 'purple' as a status colour. In my test case, the colour seemed to remain at its previous value (which was red).

John.

-- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001