Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
Before you take steps to resolve and respond to an alert, you must first identify the issue causing the alert. Alerts don’t always provide the whole picture. They should be used as an indication that further investigation is needed into the component that generated the alert.
A great place to start investigating alerts are dashboards. Assuming dashboards are strategically set up, they can help you quickly pinpoint root cause.
As discussed in the following section, there are several places from which you can respond to an alert. While the response method is subject to personal preference, there are guidelines for the type of response you should provide, depending upon whether you can resolve the issue at hand.
LogicMonitor supports three response types. Guidelines for the appropriate use of each are discussed in the following sections:
Alert acknowledgment suppresses further notification routing of that particular alert. You should acknowledge an alert when you believe that you can resolve the problem. Resolving the problem includes fixing whatever is causing the problem and then taking action to ensure that the alert does not recur, if necessary. Actions to suppress further alerts can include:
Note: Acknowledgement of alerts applies to the same event if the severity drops but does not clear. For example, if you acknowledge a disk usage alert of level error and free up some space so that the alert level drops to warning, the warning alert will already be considered acknowledged. However, acknowledgements of alerts at a lower level do not affect the escalation of alerts if severity increases. For example, acknowledging a disk usage error alert will not affect the escalation of the critical alert if the drive continues to fill.
When you schedule downtime, you are suppressing all alert notification routing for the designated instance, DataSource, device, or Website for the duration of the configured SDT period. This is in contrast to acknowledging an alert, which only suppresses further notifications of that particular alert.
You should place a resource in SDT if:
For more information on scheduling downtime for instances, DataSources or devices, see SDT Tab; for scheduling downtime for Websites, see Website SDTs; for scheduling downtime for Collectors, see Collector SDT.
Note: When responding with SDT to an EventSource alert, the entire EventSource is placed into SDT, not just the individual event ID associated with the alert condition.
You should escalate an alert to the next step in the escalation chain if an SDT isn’t appropriate and you either don’t know what the issue is, don’t have time to identify and/or resolve the issue, or don’t know how to resolve the issue.
Note: Even if the escalation interval for the matching alert rule is set to zero, the alert will still escalate.
Note: You cannot escalate an alert whose notifications have been suppressed due to dynamic threshold or root cause analysis evaluation.
There are several places from which you can acknowledge, SDT, or escalate an alert:
In This Article