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:
- snip -
Is your Xymon server open to the public internet? :-)
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.
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