LM Exchange

Unlock the full potential of your LogicMonitor platform with the LM Exchange forum. Discover a wealth of integrations, scripts, and customizations created by the community and LogicMonitor experts. Dive into discussions, share your own contributions, and collaborate with peers to extend the functionality of your monitoring environment. Explore, innovate, and elevate your monitoring experience with the LM Exchange forum today.151 Posts

Forum Widgets

Recent Discussions

Meraki Switch Stack vs Cisco Switch Stack
I apologize if this topic has already been addressed—I was unable to locate any relevant discussions. I'm encountering a challenge with how LogicMonitor Topology represents Meraki stacked switches, particularly in contrast to its handling of Cisco stacked switches. When LogicMonitor discovers Cisco switches configured in a stack, it identifies the stack as a single logical entity, aggregating multiple serial numbers and hardware components. This behavior aligns with Cisco IOS, which presents the stack as a unified system. As a result, LogicMonitor’s topology mapping treats the stack as a single node, simplifying both visualization and monitoring. Meraki, however, takes a different approach. The Meraki cloud platform recognizes individual switches as members of a stack, and because of this (I believe) LogicMonitor treats each switch as a distinct device. Consequently, topology maps generated by LogicMonitor show individual connections between each switch in a stack, rather than representing the stack as a cohesive unit. This leads to fragmented and often impractical topology views. Manual topology mapping is not a viable option in my environment. Has anyone found a method or workaround to reconcile this issue?
billbianco
Neophyte
15 hours ago
7Views
0likes
0Comments
Example scripts
Hi community, I'm running into a limitation with reporting on Scheduled Downtime (SDT) in LogicMonitor. Right now, i' m able to pull alerts that occurred during SDT' s but i cannot generate a single report that shows all historcal SDTs across all my resources/devices. is there any way to generate such a historical SDT report, does someone have a script or code to share to get that trough the API Thanks in advance!
Admine
Neophyte
22 days ago
46Views
0likes
3Comments
Alert Tsunami: Why the Huge Delay and Flood of Post-Resolution Power Alerts?
Subject: Alert Tsunami: Why the Huge Delay and Flood of Post-Resolution Power Alerts? Hello LM Exchange community and LogicMonitor team, We recently experienced an issue that's causing significant frustration and making our alerting system less reliable. We had a couple of anticipated power cable pull-outs (testing/maintenance), which were quickly resolved. However, we then received a massive backlog of LogicMonitor alerts for this event hours after the issue was fixed and the system logs were clear. The Problem Massive Alert Delay: The initial power loss events occurred and were resolved around 7:00 PM and 8:00 PM (based on the Lifecycle Log). However, we started getting a huge flood of critical alerts via email at 9:13 PM, 9:43 PM, 10:13 PM, and 10:43 PM—hours after the issue had been mitigated and redundancy was restored. Excessive Alert Volume: We received dozens of separate critical alerts (e.g., LME205086576, LME205086578, etc.) for a single, contained event, all arriving en masse hours later. Past "Fix" is a Concern: The last time this occurred, the only way I could stop the flood of delayed emails was to turn off alerting for the device and then turn it back on. This is not a scalable or sustainable solution for a reliable monitoring platform. Key Questions for the LogicMonitor Team What is causing this significant delay in alert processing and delivery? It appears the system is holding a large backlog of alerts and then releasing them all at once hours later. What is the recommended, official way to clear an alert backlog without having to resort to manually disabling and re-enabling alerting? Is there a known configuration or polling issue that would cause a single event (like a brief power loss) to generate dozens of unique critical alerts over a short period, and how can we consolidate these into a single, actionable notification? Data for Review LogicMonitor Email Log (Image 1): Shows critical alerts arriving long after the issue was resolved (9:13 PM to 10:43 PM). Device Lifecycle Log (Image 2): Shows the power events (PSU0003, RDU0012) occurring and being resolved between 8:01 PM and 9:22 PM. Any insight or official guidance on how to prevent this "alert tsunami" would be greatly appreciated. We rely on timely and accurate alerting, and this behavior significantly undermines that trust.
B1llw
Neophyte
29 days ago
idrac
46Views
0likes
4Comments
Need to monitor long running SQL transactions
Need to monitor long running SQL transactions we had one run long and take down tons.
Anonymous
2 months ago
176Views
0likes
2Comments
Adding Data sources to LMExchange
Hi All, Didn't think this particularly warranted a support call, have I missed something, I have tried looking up submitting a datasource to review in LMExchange and I can't seem to do it. I have org admin rights so its not a permissions thing and did double check and there is a button publish that is ticked so does this mean all data sources I write will be auto published or just they can be published. Thanks in advance
Solved
SteveBamford
Neophyte
2 months ago
90Views
0likes
4Comments
Linux Collector setup
HI fellow monitor champs I have a question regarding installing linux collectors. Our engineers are complaining that they cant detect the collector when installing and adding it to the portal. So the collector is visible in collectors but if we add the machine it does not work. Adding Collector - LogicMonitor Do we need additional steps? And if yes which exact ones? Thanks in advance!
Solved
Admine
Neophyte
2 months ago
87Views
0likes
3Comments
Arista Campus Switch Power Supply State
We recently discovered that Arista Campus switches are either just not populating the OID for Power Supply states, or are using a different one, so in my API first approach to monitoring I decided to utilize the Arista EOS API to grab the power supply data, below are the discovery and collection scripts along with some of the key field for a Data source. You will notice I am using the Model number to identify the Arista campus switches using an if not statement "if ( !(model.startsWith("CCS-")))" which will drop all the DC switches out of the script. As always appreciate any feedback and ways to improve on these things. Have a great day. Note: This is obviously shared on a best efforts basis, but we are using this across all of our campus switches and it works great (We found 3 on top of the one we knew had a failed PSU that had issues). Applies to: hasCategory("Arista") Description: This will check the state of the power supply and return the following. 1 = Ok 0 = Down This replaces the Arista SNMP PSU as this returns a null value for the campus switches. Discovery Script: /* Script Name: Campus Power Supply Discovery */ import com.santaba.agent.groovyapi.http.*; import com.santaba.agent.util.Settings import groovy.json.JsonOutput import groovy.json.JsonSlurper import java.util.concurrent.Executors import java.util.concurrent.TimeUnit // Gather host statistics username = hostProps.get("ssh.user"); password = hostProps.get("ssh.pass"); host = hostProps.get("auto.network.names"); model = hostProps.get("auto.endpoint.model") vendor = hostProps.get("auto.endpoint.manufacturer") //Only need to discove the devices if the vendor is Arista Networks if ( !(vendor = "Arista Networks")) { println "Do not need to discover as not an Arista Device" return(0) } //Now we need to check if the model is one of these specific models if it is then fine if ( !(model.startsWith("CCS-"))) { println "Not a Campus Switch" return(0) } //Build Authentication JSON to send to switch def authJson = JsonOutput.toJson([username:username,password:password]); //Build URL url = "https://"+host+"/login"; // Make the call httpClient = Client.open(host, 443); def response = httpClient.post(url, authJson,["Content-Type":"application/json"]); if ( !(httpClient.getStatusCode() =~ /200/)) { println "Failed to retrieve data "+httpClient.getStatusCode return(1) } //Get Session data so we can extract the session string String sessionData = httpClient.getHeader("Set-Cookie"); sessionData.substring(sessionData.lastIndexOf("Session=")+1,sessionData.length()); // Remove everything including the ; after the semiColon in session Data def firstPass = sessionData.split(';')[0]; // Remove everything before and including the = this will leave you with the session data. def session = firstPass.split('=')[1]; // Now we can gather the data to do this we need to build the command JSON output, URL and Header def GetStatus = JsonOutput.toJson([jsonrpc: "2.0",method: "runCmds",params: ["version": 1,cmds: [ "show environment power" ],format: "json"],"id": "1"]) def powerUrl = "https://"+host+"/command-api"; def powerHeader = ["Cookie":session,"Content-Type":"application/json"] // Now we can retrieve the data. //httpClient = Client.open (host,443) def powerData = httpClient.post(powerUrl, GetStatus ,powerHeader); if ( !(httpClient.getStatusCode() =~ /200/)) { println "Failed to retrieve data "+httpClient.getStatusCode return 1 } String powerContent = httpClient.getResponseBody() def powerTable = new JsonSlurper().parseText(powerContent) def encoded_instance_props_array = [] def wildvalue = "" def wildalias = "" def description = "" //println powerTable powerTable.result[0].powerSupplies.each { psuNo,powerSupply -> wildvalue = "Power_Supply_"+psuNo wildalias = "${wildvalue}:${powerSupply.modelName}" description = "${wildvalue}/${powerSupply.modelName}" def instance_props = [ "auto.power_suppLy": "Power Supply " + psuNo, "auto.power_model_name": powerSupply.modelName ] encoded_instance_props_array = instance_props.collect() { property, value -> URLEncoder.encode(property.toString()) + "=" + URLEncoder.encode(value.toString()) } println "${wildvalue}##${wildalias}##${description}####${encoded_instance_props_array.join("&")}" } return 0 Collection Script: /* Script Name: Campus Power Supply Collection */ import com.santaba.agent.groovyapi.http.*; import com.santaba.agent.util.Settings import groovy.json.JsonOutput import groovy.json.JsonSlurper import java.util.concurrent.Executors import java.util.concurrent.TimeUnit // Gather host statistics username = hostProps.get("ssh.user"); password = hostProps.get("ssh.pass"); host = hostProps.get("auto.network.names"); model = hostProps.get("auto.endpoint.model") vendor = hostProps.get("auto.endpoint.manufacturer") //Only need to discove the devices if the vendor is Arista Networks if ( !(vendor = "Arista Networks")) { println "Do not need to discover as not an Arista Device" return(0) } //Now we need to check if the model is one of these specific models if it is then fine if ( !(model.startsWith("CCS-"))) { println "Not a Campus Switch" return(0) } //Build Authentication JSON to send to switch def authJson = JsonOutput.toJson([username:username,password:password]); //Build URL url = "https://"+host+"/login"; // Make the call httpClient = Client.open(host, 443); def response = httpClient.post(url, authJson,["Content-Type":"application/json"]); if ( !(httpClient.getStatusCode() =~ /200/)) { println "Failed to retrieve data "+httpClient.getStatusCode return(1) } //Get Session data so we can extract the session string String sessionData = httpClient.getHeader("Set-Cookie"); sessionData.substring(sessionData.lastIndexOf("Session=")+1,sessionData.length()); // Remove everything including the ; after the semiColon in session Data def firstPass = sessionData.split(';')[0]; // Remove everything before and including the = this will leave you with the session data. def session = firstPass.split('=')[1]; // Now we can gather the data to do this we need to build the command JSON output, URL and Header def GetStatus = JsonOutput.toJson([jsonrpc: "2.0",method: "runCmds",params: ["version": 1,cmds: [ "show environment power" ],format: "json"],"id": "1"]) def powerUrl = "https://"+host+"/command-api"; def powerHeader = ["Cookie":session,"Content-Type":"application/json"] // Now we can retrieve the data. //httpClient = Client.open (host,443) def powerData = httpClient.post(powerUrl, GetStatus ,powerHeader); if ( !(httpClient.getStatusCode() =~ /200/)) { println "Failed to retrieve data "+httpClient.getStatusCode return 1 } String powerContent = httpClient.getResponseBody() def powerTable = new JsonSlurper().parseText(powerContent) def encoded_instance_props_array = [] def wildvalue = "" def wildalias = "" def description = "" powerTable.result[0].powerSupplies.each { psuNo,powerSupply -> wildvalue = "Power_Supply_"+psuNo wildalias = "Power_Supply_"+psuNo+":${powerSupply.modelName}" psuRawState = "${powerSupply.state}" if (psuRawState == "ok") { psuState = 1 } else { psuState = 0 } println "${wildvalue}.psuState=${psuState}" } return 0
Solved
SteveBamford
Neophyte
3 months ago
41Views
0likes
6Comments
HPE Alltera Storage
Hello community does anyone know if there is a module for monitoring HPE Alltera devices?
phakesley
Neophyte
3 months ago
35Views
0likes
1Comment
Duplicate Tickets Generated for Alert
We're getting duplicate tickets generated for each alert Host Status. Can't quite figure out what is causing it. Same Alert ID... When the alert closes... one ticket closes, the other doesn't. I've seen this in the past with having separate alert rules for error vs. critical... The association in ##EXTERNALTICKETID## only respects the most recent ticket created per integration. I've started at the dataSource's thresholds and made my way through the alert -> rule -> escalation -> integration... everything suggests it should only create one ticket per alert. We have thresholds defined at the /Clients group level in most cases to make sure we're not touching the DS itself to make those changes so updating is easier. I've verified that only Critical creates tickets there.
Solved
Cole_McDonald
Professor
3 months ago
51Views
0likes
5Comments
HP Aruba 6000 switch Support?
Good Afternoon, It seems that the newest switch chassis from Aruba/HP Isn't playing too nicely with LM at the moment. The same DataSources that were useful for the previous HP Switches don't appear to work for the newer 6000 series devices (we have a 6000 and a few 6500s) specifically, the Memory snmp query seems to poll no data - luckily the default CPU for SNMP does work. Has anyone run into this themselves?
Jordan-Eil
Neophyte
3 months ago
89Views
1like
2Comments

Tags

propertysource2