Auto-Closing Incidents Triggered by Logic Monitor Integration

lvenna
Tera Contributor

Hello All,

 

We are experiencing an issue with Incidents created through the Logic Monitor integration. These incidents are generated for collector failovers, and the failover details are included in the Incident description.

When the failover is restored, Logic Monitor sends a notification, which is added as a work note to the Incident (e.g., indicating that the failover is back online for the collector). However, the Incident is not automatically closing based on this update.

Currently, users are manually closing these incidents, and when the same collector goes down again, the Incident is reopening as expected. If I implement an auto-close mechanism, it should not interfere with this expected reopen behavior, even if the Incident is in a closed state.

Is there a recommended approach to configure these Incidents to auto-close when a specific work note is added by the Logic Monitor integration (for example, when the work notes states that the failover has been resolved and the collector is back online)?

Any guidance or best practices would be greatly appreciated. Thank you!

 

2 ACCEPTED SOLUTIONS

@lvenna 

 

Please see below for LogicMonitor documentation that explains how collectors are monitored and alerts are generated & cleared. I am not sure why your LM team are saying alerts will not be auto-cleared when that should be the case. You can request them to check with LogicMonitor support team to clarify on this if needed.

Bhuvan_0-1757518676518.png

There are multiple scenarios when it comes to collector failover, failback and related alerting configuration. I have extensively worked on Monitoring & Event Management tools and integration with ITSM Systems for different vendors. Collectors are remote agents that collects data from underlying Infra components on scheduled interval [5 minutes, 15 minutes etc.,] and collected data would be compared against thresholds defined for the monitored attributes. When threshold is breached, alert will be generated in the system and can be integrated with ITSM system for automated incidents and acted upon to restore the services & monitored components.

 

In Production environment, collectors would be configured in High Availability and sometimes HA + DR setup. When a Primary collector goes down, Secondary collector automatically picks up data collection jobs and starts collecting the data. In this example, typically there will be 2 alerts, one for Primary Collector going down and another for data Collection being impacted. Based on failover configuration, Secondary collector will start picking up data collection jobs and data collection will resume. By this time, data collection impacted alert should be auto-cleared and Primary collector down alert would remain open. When Primary collector is back online, related alert would be cleared and depending on your failback configuration, data collection will be either from Primary or Secondary collector. At a high level, this is the same mechanism for all the vendors for Monitoring and Event/Alert Management.

 

LogicMonitor - ServiceNow integration uses import set and transform map for the integration. 

 

https://store.servicenow.com/store/app/acdbabea1b246a50a85b16db234bcb15

 

Bhuvan_1-1757519808865.png

If LogicMonitor Product team confirms this is the expected behavior and your team has configured collector failover alerts correctly, you can try below approach

 

Identify the Transform Event Script that carries out incident updates and add a condition to check for the alert category or unique filter condition for collector failover alerts and work note contains collector is back online [these fields will be part of import set table] and update incident state as per your requirements. This will make sure you are not introducing additional script or Flow Designer Action outside your integration and will be handled as part of existing configurations.

 

I hope you appreciate the efforts to provide you with detailed information. As per community guidelines, you can accept more than one answer as accepted solution. If my responses helped to guide you or answer your query, please mark it helpful & accept the solution.

 

Thanks,

Bhuvan

View solution in original post

@lvenna 

 

If you do not want to customize transform event script, you can either create Business Rule or Flow. Since this is a simple requirement, I would recommend Business Rule.

 

Create an after BR on incident with filter conditions specific to Collector Failover alert from LM [category or any field that can uniquely identify the incident created for failover] and work notes changes and caller is LogicMonitor. Check for latest work notes for the record from journal entry and if it contains 'Collector is back online' [change it with actual expected text], update state of the incident. 

 

I would recommend you to submit a Support case with LogicMonitor and ServiceNow and request them to create known problem and enhance the integration on either LM or ServiceNow end. BR is more of a workaround and incident closure for Collector Failover should be handled automatically. If it not available now, they can enhance this for future app updates.

 

I hope you appreciate the efforts to provide you with detailed information. As per community guidelines, you can accept more than one answer as accepted solution. If my responses helped to guide you or answer your query, please mark it helpful & accept the solution.

 

Thanks,

Bhuvan

View solution in original post

21 REPLIES 21

lvenna
Tera Contributor

@Bhuvan  

 

Thank you for the detailed explanation and guidance.

When the primary collector goes down, we indeed see two alerts being generated in LogicMonitor. Once the primary collector comes back online, one of the alerts is cleared properly, and ServiceNow receives the cleared notification, which results in the related incident closing as expected.

However, for the other alert, we do not receive a cleared notification. Instead, we only get a message such as “failed back.” The LogicMonitor team has suggested that we use this message as a trigger to close the incident.

If this is the expected behavior and the alert is considered “cleared” with the “failed back” message, what would be the best approach to implement this in ServiceNow? You mentioned handling it in the Event Transform Script—can you please confirm if this is an out-of-the-box (OOB) script? If so, could you share the specific script name or help me navigate to it? I tried locating it but wasn’t able to find it.

Appreciate your continued support.

Laxma.

@lvenna 

 

Unfortunately 'LogicMonitor Incident Management Integration' plugin cannot be installed in PDI to provide more information on the mapping at ServiceNow end.

 

https://store.servicenow.com/store/app/acdbabea1b246a50a85b16db234bcb15

 

Refer LogicMonitor documentation, look for import set table 'x_lomo_lmint_logicmonitor_inbound_webser' in ServiceNow and identify transform map definition for the import set table.

 

You can check if import set table name is correct from your LM integration HTTP delivery section which will be pointed to ServiceNow import set table 

 

I am not providing direct links for LM documentation as sometimes the post gets moderated when adding external URLs, you can easily locate the section from shared screenshots

Bhuvan_0-1757525115789.png

Bhuvan_1-1757525604431.png

I hope you appreciate the efforts to provide you with detailed information. As per community guidelines, you can accept more than one answer as accepted solution. If my responses helped to answer your query, please mark it helpful & accept the solution.

 

Thanks,

Bhuvan

lvenna
Tera Contributor

@Bhuvan  

 

Thank you again for taking the time to provide such detailed guidance. Everything looks correct from the scripting side.

If the Logic Monitor ask me to use the “failed back” message to close incidents, can this be achieved by customizing the existing Logic Monitor integration? To be transparent, I would prefer not to modify the current integration.

If this customization is unavoidable, what would be the best way to implement it without directly altering the existing integration flow? For example, would it be better to handle this through a Business Rule or Flow, rather than updating the integration scripts?

Appreciate your continuous help and insights.

Thank you,
Laxma

@lvenna 

 

If you do not want to customize transform event script, you can either create Business Rule or Flow. Since this is a simple requirement, I would recommend Business Rule.

 

Create an after BR on incident with filter conditions specific to Collector Failover alert from LM [category or any field that can uniquely identify the incident created for failover] and work notes changes and caller is LogicMonitor. Check for latest work notes for the record from journal entry and if it contains 'Collector is back online' [change it with actual expected text], update state of the incident. 

 

I would recommend you to submit a Support case with LogicMonitor and ServiceNow and request them to create known problem and enhance the integration on either LM or ServiceNow end. BR is more of a workaround and incident closure for Collector Failover should be handled automatically. If it not available now, they can enhance this for future app updates.

 

I hope you appreciate the efforts to provide you with detailed information. As per community guidelines, you can accept more than one answer as accepted solution. If my responses helped to guide you or answer your query, please mark it helpful & accept the solution.

 

Thanks,

Bhuvan

lvenna
Tera Contributor

@Bhuvan  

 

Thank you so much for guidance,

 

Laxma.