Forum Discussion

Clark_Kent's avatar
Clark_Kent
Icon for Neophyte rankNeophyte
2 months ago

How to handle unnecessary active alerts

Dear LM community,

I’m looking for the best practice to handle unnecessary active alerts in LogicMonitor.

As far as I understand, we can acknowledge, put into SDT, escalate, or adjust alert thresholds (Instance thresholds), or even group instances with custom alerting rules. However, it doesn’t seem possible to simply remove an active alert once it’s triggered- please correct me if I am mistaken.

Each of these approaches has some downsides — for example, grouping interfaces to suppress alerts may cause us to miss new alerts later if the port becomes active again.

What is the recommended way to deal with such unnecessary alerts - in this case - inactive network interfaces that are alerting but are expected to stay down?

Thank you in advance for your input!

3 Replies

  • For best practices, I assume the LM academy covers that (perhaps the new https://academy.logicmonitor.com/alerts-badge session).

    For the network interface alerts, my understanding (I'm not on the network team) is that LM will only add ports/interfaces the first time LM sees that it has been used. So if someone temporarily uses a port, it will get added in LM, then alert when they stop using it. If that is what is happening, you have some options. You can just disable alerting for that interface instance and manually turn it on if you need to alert on it later. Or you can delete the instance in LM so it will forget it until the next time it gets used. This sounds like what you want to do, but I just see that as a wack-a-mole of random interfaces getting added and manually deleted. I myself (again not a network guy) would just let LM add all the ports and disable all but the important ports. Like those for uplinks or to servers. Don't generally need to monitor client ports.

  • I would check out the KB Article, on setting up interface alerting.  We went the route of tagging interfaces (on the interface description) and then only alerting when we see that opt-in tag.

  • For interfaces we altered the LM data source to identify a critical interface based on the description of the interface having "MO-CRIT" and then only generating an error for these going down and left all other interfaces as warning, of course for all other interfaces you could simply just turn off alerting.

    I posted for help in the community to get help for this please see the link below it may help.

    https://community.logicmonitor.com/discussions/product-discussions/creating-a-complex-data-source-to-check-the-interface-description-and-then-the-s/9728