Forum Discussion

Vitor_Santos's avatar
5 years ago

Schedule SDT for specific events within a EventSource??

Hello everyone,

We've multiple Event Sources setup (each one of them covers multiple events (different sources & event IDs). They're kinda in the same category but they cover different events (example Backup Related Events - within those there's multiple applications, event IDs, etc...).

Our question here comes if we need to filter a specific event (within one of those Event Sources) on a specific period of the day.
For example, ServerA is returning some events at 2AM EST but those are related with a scheduled job that occurs daily, one of our clients requested us to filter those events (daily from 2AM to 2:20 AM EST). 

Is there any way to do an SDT (but with a specific criteria)? Without filtering the whole Event Source (that contains more events that shouldn't be suppressed at that time).

The reason we've multiple events within a event source is to don't create a lot of Event Sources (thinking on the WMI usage here). We have multiple events on the same Event Source, that way we don't do so many WMI queries.

Just asking because in our old monitoring tool we were able to specify specific criteria on the suppression rule(s) & this is really important for us (since we have a lot of those requests).

Appreciate the help!

  • Hi Stu,

    Yeah this is an area in which I see LogicMonitor really falls flat on. Falls behind in what our current tool (CA UIM) allows us to do. Full Alert management.

    With UIM we had full control over all the alerts that were generated and can create rules, exclusions, schedules on all alerts so we could manage all alerts much better. With LogicMonitor its really here deal with all these alerts and there is no fine tuning after the fact. 

    LM really needs this essential functionality added to the product road map ASAP.

     

    But anyway is there no way to do this from LM? 

  • Anonymous's avatar
    Anonymous

    Yeah, it can be done, but the logic has to be built in somewhere. 

    Just to make sure I understand the ask: you have an event source that catches, for example, 20 different events. You want alerts on 19 of those events any time they happen. On the 20th event, you want alerts all the time, except from 2-2:30am daily.

    So, you want to turn off the EventSource, but only for one event within all the events caught by that ES, and you only want to SDT it during a certain time of the day.

    So, you can't build this on the EventSource level, otherwise, you'd ignore all 20 event types during that time. You can't just ignore that one event because if it occurs outside that time, you want it to generate an alert. 

    Your only option is to ignore it in the fetching of alerts. If the ES is not Groovy based, it will need to be converted to Groovy in order to build the logic into the script to ignore that one event during that one time window.

    What if you split out that one event from the 19 other events and had 2 ESs? That would be better than 20 ESs, but would allow you to leave most of the stuff handled normally. Then you'd have just the one ES to handle that one event and you could build logic into it to ignore the event during that daily timeframe.

  • 3 minutes ago, Stuart Weenig said:

    Yeah, it can be done, but the logic has to be built in somewhere. 

    Just to make sure I understand the ask: you have an event source that catches, for example, 20 different events. You want alerts on 19 of those events any time they happen. On the 20th event, you want alerts all the time, except from 2-2:30am daily.

    So, you want to turn off the EventSource, but only for one event within all the events caught by that ES, and you only want to SDT it during a certain time of the day.

    So, you can't build this on the EventSource level, otherwise, you'd ignore all 20 event types during that time. You can't just ignore that one event because if it occurs outside that time, you want it to generate an alert. 

    Your only option is to ignore it in the fetching of alerts. If the ES is not Groovy based, it will need to be converted to Groovy in order to build the logic into the script to ignore that one event during that one time window.

    What if you split out that one event from the 19 other events and had 2 ESs? That would be better than 20 ESs, but would allow you to leave most of the stuff handled normally. Then you'd have just the one ES to handle that one event and you could build logic into it to ignore the event during that daily timeframe.

     

    Your logic is exactly what we want. To sum, exclude just one event (for a certain period only) & don't affect the others on the same ES.

    We could do that (creating 1 ES just for that event), however, this is something that we do really often (for our diverse clients). That's not an optimal solution for us in terms of monitoring management, otherwise, we'll need to be creating separate ES all the time (whenever a client requests it for a certain event - which happens often).

    We actually can do this in our Alert Console (since our LM is sending all the alarms to our SNOW instance), however, it would be easier & standard if we could do this in LM.

    Should this be a feature request perhaps?

    Regards,

  • Anonymous's avatar
    Anonymous

    Yeah, the ability to add time based conditions to filter criteria in an EventSource would be a good feature reuquest.

  • Do I need to submit a feature request? Or what's the proper action here (since I already have this post)?

  • Anonymous's avatar
    Anonymous

    Best to reach out to your CSM and make them aware that you want this to happen. Probably good to start a thread in the feature requests forum linking to this thread so the product managers see it there as well.

  • 19 hours ago, Stuart Weenig said:

    Best to reach out to your CSM and make them aware that you want this to happen. Probably good to start a thread in the feature requests forum linking to this thread so the product managers see it there as well.

     

    Thank you Stuart. I'll share this post with our CSM.

    Regards,