Forum Discussion

mnagel's avatar
mnagel
Icon for Professor rankProfessor
7 years ago

eventsource uniqueness

As it stands, eventsources are impossible to use with alert policies because a single real-life event generates an unending stream of new alerts.  You can ACK one, but it doesn't matter since the next one is a different ID. We need to have a way to map ongoing conditions into existing alerts, preferably with a counter of some sort to show how many of them have been registered.  An example of why this is a problem is the (unpublished but documented) Cisco_Interface_ErrDisabled eventsource.  It is necessary to make it an event source as there is really no other way to get this information from Cisco switches.  But if a port is disabled, and you want to hear about it, you will get a new alert (and clear) repeatedly with no way to stop the alerts, except to fix the problem.  Fixing is of course the best result, but it is not always possible to do quickly.  We have found similar problems trying to push eventsource alerts into a ticketing system.  Since each has a new ID, each is a new ticket.

Thanks,
Mark

 

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    7 years ago

    Let me add a simple idea that matches (in a limited way) how tools like SEC operate.  Allow extraction of a key within the eventsource definition (this is the "desc" field in SEC, the thing that correlates different events).  With this, we can then place linked/correlated events into a single bucket so that each new one is not considered new unless the bucket has aged out.  Keeping a counter of those hits would also be handy.  Ultimately, the right solution involves much more complexity, but as it stands getting alerts on eventsources is a giant PITA, yet there are times you really want to get them as alerts.

    Thanks,
    Mark

  • Mosh's avatar
    Mosh
    Icon for Professor rankProfessor
    7 years ago

    I agree, I try to avoid using event sources because of the reasons you've stated.  Your keying suggestion is similar to Netcool does it with its AlertKey field which can be configured as part of configuring the event collector in Netcool. Everytime an alert comes in with the same exact key, they are de-duplicated and the counter increased on the first occurrence alert.  Alerts should have a last occurrence time stamp to show when the alert with the same key was last received, i.e. when the count last increased.