[Xymon] server-side message pre-processor?

Root, Paul T Paul.Root at CenturyLink.com
Tue Nov 3 21:19:39 CET 2015


We are still trying to fix a HR issue with technology.

Your clients are misusing your system, and don't care. Go over their heads and make their management care.

-----Original Message-----
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of John Thurston
Sent: Tuesday, November 03, 2015 1:11 PM
To: xymon at xymon.com
Subject: Re: [Xymon] server-side message pre-processor?

On 11/3/2015 9:22 AM, Japheth Cleaver wrote:
- snip -
> I guess one question would be whether these are being caused by poorly
> configured local settings, or by people coming up with new tests they're
> reporting in that you don't want to hear about?

These are poorly managed hosts whose owners see none of the cost of
flooding the server with garbage. "What? Your stupid server can't handle
my 1,000 events per host per day?! What kind of crappy system is that?!"

They are treating my Xymon server like it was an instance of Splunk. I
keep trying to tell them it is an _alerting_ system, not a _logging_
system. If there is yellow on the page, they should be looking to see if
there really is a problem. If there is a red on the page, they should be
scrambling to fix the problem. Some of the owners are just ignoring all
colors on the page until a customer calls with a problem. Then they are
using the 'msgs' test result to see the most recent contents of the
event-log.

> Are you running in local config mode? If so, I might suggest using this
> as justification for migrating to central configuration. Put the
> thresholding control back into your hands unless the users are willing
> to accept responsibility for the types of things they're sending in.

But I don't know their business requirements ('course, it seems like
they don't either). Nor do I have the time to personally handle
configuration of 600+ hosts. Nor do I want to have access to those
systems through the client distribution and management system.

Local-config mode works fine for us, except for the client's implicit
ability to flood me with garbage. Its the "all or none" acceptance model
which is painful.

- snip -
> Is the problem more along the lines of "I don't want to receive test
> 'xyz' on any host", or more "Here's a list of 38 different tests I want
> to reject on 18 / 400 servers".

It's more the latter. "The owner of host=foo can't configure its client
correctly. This has been going on for months. Fine. I will only accept
disk and cpu from them."

I don't see the former condition as being realistic. Since any client
can send a message containing any possible string as their test-name, it
would impossible filter noise. Further, 90% of my system owners are
politely handling their 'msgs' test. I don't want to punish those folks.

- snip -
> As an initial step, I think adding hard-coded ignore-test records at
> xymond startup (by command option or by xymonserver.cfg) would probably
> be a pretty simple stop gap to create in the next rev.

I don't think this would be of any value to me. In general, I _want_ to
accept messages of the name 'msgs'. There are just 10% of my hosts from
which I want silence on messages of that type. The option of defining a
per-host white-list is what I need.

But it is probably a very fringe need. I'll try getting my bat out
again. Maybe I can beat some sense into the 10%.

--
    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
_______________________________________________
Xymon mailing list
Xymon at xymon.com
http://lists.xymon.com/mailman/listinfo/xymon
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.


More information about the Xymon mailing list