[Xymon] suppress log contents from 'msgs' column ?

[John Thurston]

On 5/13/2015 9:20 AM, J.C. Cleaver wrote:
>
>
> On Wed, May 13, 2015 10:07 am, John Thurston wrote:
>> On 5/13/2015 8:48 AM, Mark Felder wrote:
>>
>>> On Wed, May 13, 2015, at 11:43, John Thurston wrote:
>>>> In testing 4.3.20, I've noticed that the 'msgs' column (for hosts
>>>> running the xymon solaris client) contain lines from my logs even when
>>>> they are reporting 'green'. I don't really want the contents of
>>>> /var/adm/messages leaked to every viewer of my Xymon web interface.
>> - snip -
>>> Is your Xymon server open to the public internet? :-)
>>
>> No, but my xymon server is available to anyone on my network and handles
>> messages from clients in several departments. I don't see any reason or
>> value in publishing my /var/adm/messages (or spilling my process list)
>> for everyone to read.
. . .

> I think it really comes down to your audience. xymon/hobbit/Big Brother
> were all designed around making life easier for sysadmins, so it tends to
> default showing more technical data and placing it within easy reach.

To me, xymon/hobbit/BB are alerting tools. Their purpose is to tell me 
"A threshold you defined has been exceeded. You'd better go figure out 
if there is a problem brewing!" When Xymon has done this, it's job is 
done. I don't expect it to do much more.

It's silly (to me, anyway) to think I can predict all the information I 
will need to diagnose or correct future host problems and pre-populate 
Xymon with that information. To know what information I might need, I'd 
need to know what problem I am going to have. If I know what problem I'm 
going to have, I should take preemptive steps to avoid having the problem.


> For precedence, we do have the following options to xymond_client currently:
> --no-ps-listing
...
> --no-port-listing
...

Thank you for pointing these out. This is just the sort of thing I was 
hoping to find. It helps clean up some of the leaked information. It 
still leaves me 'cpu' and 'msgs', but this is a start.

> I could see one of two paths here:
>
> a) adding individual flags for each of the remaining test results
> xymond_client generates, controlling the raw data on the status page, or
>
> b) a single master "raw data on status" flag used for all at once

(a) would mean any new client capabilities would need to be tightly 
coupled to the server so they weren't left out. It is flexible, but it 
could be a hassle.

(b) would probably meet my needs nicely. I just want the status. It's 
nice to have an indication of what breached the threshold, but tailing 
/var/adm/messages into the HTML page for every green update seems 
pointless.  Maybe "IncludeRawData=color[,color]" so it could be included 
with red and yellow but not with green.

Seen below for an idea for (c).

> One thing to keep in mind is that if you're doing server-side
> configuration with dynamic status message . . . .

Only three of my clients are in "central" mode, and those are only in 
that mode because they are running on my Xymon servers and come out of 
the build-process configured that way. All of my other clients are 
running older BB or BBPe clients. Which means in my case, I should 
probably pursue option:

(c) I suppress the columns I don't want on the three clients that 
display them. I suspect that my desire to suppress this information is a 
fringe-case and not worth the effort to incorporate.


-- 
    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