Syslog "Cleared" = MEANINGLESS

Treating all events equally is a very bad policy.

A dropped ping, is very different from a syslog message about parity failure in a RAID or DBReplication failure alert.

Note in MOST (if not all) situations where we use Syslog....the effects reported would NEVER clear....at all without a tech going in and doing work.

the software sending a "cleared" email is the opposite of crying-wolf.....it's crying "all clear" when the wolf is right there chewing on your leg.

I'm very frustrated that I have to explain this twice....the customer that suggested it doesn't understand what syslog "is".

The engineers that honored the flawed request did that customer...and the rest of us...a grave disservice.

 

You've forced me to train my people to ignore certain messages.

The work around we have now is to filter all your Cleared messages:

Still, not sure why you didn't lead with that advisement.

 

You can't convince me to change my opinion on this topic : it was a poor design decision you've made here.

 

In time, I am very certain you will see why I am right.

 

Hi Mahlon,

We send clears for Syslog events because we treat all events equally (e.g. IPMI, Windows, Syslog, UDP traps, etc.).  Our philosophy is to only alert on alertable events, where alertable events usually have an underlying condition that can clear, or be resolved, or expire.  However, I understand that Syslog-based events aren't the same as all other events, and that getting cleared messages may not always be desirable.  You can actually configure your LogicMonitor Alert Rules to not send cleared alerts for Syslog events - there is an option for all Alert Rules to 'Send notification when alerts clear'.  So if you dedicate a rule to routing Syslog events, unchecking this option gives you the flexibility to only have active and acknowledged notifications sent.  

Thanks,

Sarah

I am not sure there is a design problem to be solved here. In my opinion, the decision was brilliant to have consistent design, alert handling and escalation rules at the expense of having to edit an escalation rule to stop syslog clears (or other clears you may not want).

It allows all users of all skills to both navigate and configure the LogicMonitor web portal easily. You don't have to be an SME, but it's as usable for someone who is.

Let's also not forget that syslog alerting is not a core strength for LogicMonitor. If a particular organization's troubleshooting methodology is primarily via syslog events, then I would propose that a dedicated syslog application is merited. LogicMonitor's strength is in performance metrics and discovery of new items that now should be monitored.

My team's primary troubleshooting method is not syslog, but for those events that we don't want clears on, we simply disable them.