On Mon, August 24, 2015 10:15 am, Sean MacGuire wrote:
> OK, I'll chime in... I wrote Big Brother so know something about
> purple alerts.
>
> The purple alert was something no other monitoring system did, and
> it took care of the problem of a BB (and Xymon) client dropping dead
> and/or machines being in a zombie state (i.e. responding to pings but
> otherwise hung).
>
> They're useful as a indication of something being wrong, vs a red or
> yellow alert which provide a clear and actionable problem ststus.
>
> So purple alerts are awesome, unless your server has lost contact
> with the clients reporting in and everyone goes purple at the same
> time resulting in the "Massive Purple Explosion".
>
> Background explanation - the idea was to timestamp reports into the
> future, and if a client doesn't report in by then, the validity of
> the last report is in question - it's works the exact same way as
> the expiration date on a carton of milk - the milk might not have
> gone bad, yet, but you might want to check it before drinking it.
>
>
> Matt Vander Werf wrote:
>> This is primarily for Henrik and J.C., but anyone else is free to chime
>> in their thoughts on this as well!
>>
>> *Background:
>> We have a Xymon server (the latest Terabithia RPM on RHEL 7) in
>> production that monitors around 1950 hosts (and consistently growing).
>> About a week ago, we experienced some pretty bad purple alert storms in
>> the middle of the night that were all false-positive alerts (over 300
>> alerts one night). For most of the tests that went purple, they went
>> back to green at the next update interval. At this point, we've been
>> unable to figure out a root cause behind this issue, but it hasn't
>> happened again since early last week (all the easy, understandable
>> possible causes has been ruled out: network load/bandwidth, CPU load of
>> Xymon server and of Xymon clients affected, etc.).
>>
>> We have been using purple alerts for some time now, find them fairly
>> reliable for the most part, and think they are useful, as machines hang
>> or something similar (causing the Xymon client on the machine to stop
>> being able to report to the Xymon server) and we don't get any red or
>> yellow alerts for any other tests (sometimes a machine can hang but
>> still have a network connection that can be successfully pinged by
>> Xymon, we have found). We haven't had any major issues with
>> false-positive purple alerts (for the most part), or any purple alert
>> storms, since we started using them consistently for all our machines a
>> couple years ago.
>>
>> I understand that when Xymon was first forked from Big Brother a long
>> while back, it may have been noted that one big change from Big Brother
>> was that you didn't need to do purple alerts (or something like that)
>> and that it was discouraged to use purple alerts, as they were seen as
>> widely unreliable. (I'm hearing this from a coworker of mine, who set up
>> our original Xymon server some 5 years ago, but have been unable to find
>> what he's referring to.) But from what I can see from the current
>> documentation and the mailing list archives, I'm not seeing any place
>> where the use of purple alerts is discouraged due to them being
>> unreliable.
>>
>> *Question(s):
>> So, I wanted to see what the current thinking/view regarding purple
>> alerts and the use of purple alerts was by both the original main
>> maintainer, Henrik, and the more current main maintainer, J.C. (at least
>> of the current release). Are purple alerts still considered wholly
>> unreliable, or even somewhat unreliable (or were they ever)? Are they
>> discouraged in any way or fashion from being used? Have they caused
>> issues for any of you on this list? Or vice versa: Have they worked well
>> for you? I'm fully aware that this purple alert storm issue we had is
>> just a one-off occurrence and we could have not more additional issues
>> in the future with purple alerts.
>>
>> I understand that purple alerts are different than other alerts, like
>> red and yellow alerts, in that it is an indication that the Xymon client
>> has stopped working/reporting (on a per-test basis) to the Xymon server
>> for some reason, rather than an issue from a specific test (e.g. with
>> the CPU load, memory, etc.).
>>
>> *(Possible) Feature Request:
>> In addition, I'd be interested if there was a way that you could only
>> get one alert for a machine if say all the tests for that machine go
>> purple, instead of an alert for each purple test. I don't believe this
>> is possible currently, correct? Is this something that could possibly be
>> implemented in the future? I understand if it's not or if it wouldn't be
>> very easy.
>>
>>
>> I appreciate your time in answering my questions and look forward to
>> your input! (And apologies for the long-winded e-mail!)
>>
>>
>> Thanks very much in advance!!
>>
>> --
>> Matt Vander Werf
Matt,
Generally speaking, a purple alert should be seen first and foremost as an
indication of a failure in the monitoring *system*... where "system"
includes the client pushing data up from the various servers you're paying
attention to.
By having a calculation made on each message's receipt of how long that
message is good for (receipt time + [default, or specified]), we have a
"fail safe" for an unknown issue occurring that requires attention. The
proximate cause of the purple is the failure to receive a message. Whether
that's caused by a hang or death of the usual originator, a bug in a
xymonproxy, a cut network cable, or xymond being unable to handle all of
the traffic sent to it before it times out, is left somewhat as an
exercise for the administrator.
Because purple alerts are generated from xymond's own view of its internal
state (calculated once a minute) and are never sent IN to xymond, purple
alerts should be a reliable indicator that... some other type of
unreliability is going on :)
Because of the wide possibility of different configurations, it's a little
dangerous to create a one-size-fits-all strategy for purples. In a typical
xymon installation with xymonnet and xymond_client running locally on the
same machine, with no proxies or network segments in the middle, and with
clients reporting directly in as well, you really shouldn't see any purple
alerts outside of clients dying... And if the client is dying because the
box is dying, by default you'll only get the 'conn' test red alert instead
of the various xymond_client and xymonnet-generated ones (unless you're
using the 'noclear' line in hosts.cfg).
Your suggestion to have only a single 'purple' come through would
*typically* work, but you'd have to ask yourself which test would be the
representative one. In our case, we found it easiest to nominate a
specific xymond_client test -- "memory" -- and only send purple
notifications for that out to our alert team. That takes care of
xymond_client, while leaving esoteric situations caused by the failure of
different sharded xymonnet's, xymonproxy's, or custom independent tests
free to fail in their own way.
Again, it's the non-typical cases where it gets tricky. What about custom
tests that aren't being generated by xymond_client that are still
functioning? Perhaps you have xymonnet running on a different machine
that's reporting back to xymond (or to a xymonproxy that's reporting back
to xymond!) that has failed in some way. And of course, it could be that
xymond is under heavy load and is unable to keep up with incoming messages
generally (something we experienced in both the TCP and BFQ configs as we
were scaling out).
Sort of along these lines, however, I'd been considering having a more
"host-wide" way of defining certain failure states directly within xymond,
which would allow some of this override logic to happen centrally (and
more reliably). Imagine a 'conn' being red optionally causing *all* tests
to fail-to-clear, removing the need for this calculation from the
remainder of xymonnet tests. Or a true host-wide "disable" that gets
applied to all tests, even new ones, as a xymond flag. A host-wide
"purple-state" could be conceptualized as well.
That's just a thought, though, and it kind of depends on whether people
would find such a feature useful.
Anyway, I hope that's answered some of your questions!
Regards,
-jc