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

[J.C. Cleaver]

On Wed, May 13, 2015 1:32 pm, John Thurston wrote:
> On 5/13/2015 9:20 AM, J.C. Cleaver wrote:

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

I actually probably should have clarified these as xymond_client command
line options rather than flags per se. Although it does bring up an issue
in that the command line is hard-coded for local-configuration mode users.
The only way to modify that is to edit the xymonclient.sh script.

Although an environment flag (cf. (c)) could be useful, a
"LOCALCLIENTOPTS=" variable in clientlaunch.cfg would allow arbitrary
options to be passed to xymond_client in these case.


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


This is correct. If the BB clients are creating status messages rather
than transmitting the raw client messages, then you'd need to
edit/configure things there. It's morally equivalent to Xymon's local
mode.


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


On Wed, May 13, 2015 12:42 pm, Andy Smith wrote:

> What about
> per-host flags similar to HIDEHTTP which performs a similar function for
>   sensitive web page checks?
> --


I think there's a use case for for both types of control here. A set of
xymond_client --options (+a generic option) for not including anything
beyond threshold evaluations in the status messages generated. This helps
the --local config use case as well as provides easy global server
control(*). Secondly, a 'HIDECLIENTDATA' flag in hosts.cfg read in by
xymond_client could give the same effect on a per-host basis for specific
exceptions.



*svcstatus.cgi could be altered to inhibit CLIENTLOG display for a host
with this setting in hosts.cfg too, but given that the data was still
present in the client channel to begin with, that's only a surface level
of security. The "best" solution will be to use --local mode and never
send that raw data to begin with.



I don't think either of these types of options are ready for 4.3.20, but
it's probably something that can be put into the next release pretty
easily.


Regards,

-jc