Cisco Switch ErrDisabled Status on Port

Should be fixed now.  I still would like to redo this as a datasource with per-port instances.  Event sources are not very useful without inter-event correlation, but better than not knowing what is going on :).

This is doing exactly what we want but with one problem.  How do you stop a scripted event source from creating duplicate alerts every time it connects and runs?  Hmmm I wonder if I can do something with my Escalation Chain.

It would be awesome to be able to suppress these IF it detected the same port was disabled and an existing alert was already active based on message matching or something.  I need a checkbox similar to the checkbox on the Windows Event Logging type Event Source.

2 minutes ago, Shack said:

This is doing exactly what we want but with one problem.  How do you stop a scripted event source from creating duplicate alerts every time it connects and runs?  Hmmm I wonder if I can do something with my Escalation Chain.

It would be awesome to be able to suppress these IF it detected the same port was disabled and an existing alert was already active based on message matching or something.  I need a checkbox similar to the checkbox on the Windows Event Logging type Event Source.

Event sources are a poor solution for generate alerts, though it is very desirable that they can.  I have requested for a long time there be a way to correlate events via a key extracted from the event so you know it is the same event (this is trivial with many event solutions, including the incredibly awesome FOSS SEC tool).  Among other things, you cannot even ACK an event effectively since the next run is a brand new result, but the email instructions still list ACK as an option and our clients believe it works.

I think the only reasonable solution is to redo the code into a datasource, like originally discussed in this thread.

2 hours ago, mnagel said:

I think the only reasonable solution is to redo the code into a datasource, like originally discussed in this thread.

Agreed, a DataSource would fix the multiple alerts that results from an EventSource running.

Although i think the larger question of alert correlation (multiple alerts being statically or dynamically grouped into incidents) is something you should be requesting from your CSM. Even something like occurrence counts on alerts would be good. The same problem happens with SNMP traps; traps can come in every minute and be about the same thing still in an unwanted state. Each one should just increment a counter on the alert. Counter thresholds should be something we can add to alert rules.  Even regular datapoints could benefit from this, counting the number of poll cycles/minutes that a particular metric has been over threshold. 

1 minute ago, Stuart Weenig said:

Agreed, a DataSource would fix the multiple alerts that results from an EventSource running.

Although i think the larger question of alert correlation (multiple alerts being statically or dynamically grouped into incidents) is something you should be requesting from your CSM. Even something like occurrence counts on alerts would be good. The same problem happens with SNMP traps; traps can come in every minute and be about the same thing still in an unwanted state. Each one should just increment a counter on the alert. Counter thresholds should be something we can add to alert rules.  Even regular datapoints could benefit from this, counting the number of poll cycles/minutes that a particular metric has been over threshold. 

Sounds like submitting to CSM should work, but here is usually what happens. "You should submit a feature request or feedback item."  To me, those have a pretty small chance of success, so I have stopped trying except in a few cases. I once was able to peer into the feedback tickets via export and discuss with our CSM, but those are normally complete blackholes.  Feature requests rarely result in any constructive activity and they lack basic support for escalation, voting, etc.  Really we need one ticket system to be able to track all of these things with suitable categories (which I have also suggested that multiple times).

And yes, every event source should have the ability to correlate new events with open events. I have been pushing for this for a long time, but I suspect now the answer is "get LMLogs" and this will never get any traction.

Being able to get data averages datapoints over time has also been a long-time open request.  This is important to look for issues where the status might oscillate, but overall levels are high (e.g., resource usage like CPU, bandwidth, etc.).

57 minutes ago, mnagel said:

Feature requests rarely result in any constructive activity and they lack basic support for escalation, voting, etc.

We are working on this and should have some news to share next quarter. Hint hint, the communities are finally getting official attention/sponsorship from LM.