Forum Discussion

Mahlon_Greene's avatar
Mahlon_Greene
8 years ago

Syslog "Cleared" = MEANINGLESS

Syslog Issues:

#1.  The person who asked to have SYSLOG present a "cleared" message.....CLEARLY does not understand that a SYSLOG is NOT A tracked condition like an OID value is....it is a SINGLE SPOT in time....and event that "happened" and does NOT "clear" as you can't change the past.

 

#2.  The programmers HONORING that (deeply flawed) request frustrates me to no end.....team, I get the mantra "the customer is always right" .....except when they're wrong it is in EVERYONE's best interest if you retrain the un-skilled users in what a baseline understanding should be.  I have no tolerance for bad design making it into development when people should know better.

 

#3.   You should have provided those of us who know better, a way to OPT OUT of these bad design decisions.

 

 

syslog
  • Mahlon_Greene's avatar
    Mahlon_Greene
    8 years ago

    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.

     

  • Sarah_Terry's avatar
    Sarah_Terry
    Icon for Product Manager rankProduct Manager
    8 years ago

    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

  • thanh_rodke's avatar
    thanh_rodke
    8 years ago

    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.