Recent Discussions
Enhanced Azure Subscription Monitoring API
We appreciate the robust monitoring capabilities provided by LogicMonitor. However, we've encountered challenges when managing Azure subscriptions. Specifically, enabling/disabling monitoring for new subscriptions requires manual intervention, leading to potential oversights. Our attempted solution involved using the REST API, but limitations with versioning (v3 vs. v4) hindered our progress. We noticed that adding subscriptions to the custom property `azure.subscriptionIDs` doesn't directly impact monitoring. We kindly request the following enhancements: 1. A dedicated API endpoint to enable/disable subscription monitoring. 2. Clarification on v4 API availability or a preview version. Such improvements would significantly streamline our workflow and enhance efficiency.13Views2likes0CommentsFeature request - Add suppression type to the alert list widget
I had a case with Logicmonitor support where I asked if it was possible to filter away alerts that fall under a cluster alert. Here I got the suggestion to use routing state but this does not give anyvalue on a cluster alert. The support engineer looked further into it. "I have tested this further and unfortunately using the routingstate filter is not going to work here as this relates to suppressed by Root Cause Analysis. I'm afraid I'm not seeing an alternative way to removed suppressed alerts from the alerts dashboard widget” So my suggestion is to add suppression type to the filter of the alert list widget.Getting specific datapoints using the REST API
In this post: https://community.logicmonitor.com/archive-13/getting-datapoint-data-via-rest-api-1249 … @Sarah Terry provides information on how to get data for just specific datapoints, reducing load on the API, minimizing network traffic and reducing deserialization load on the client. While this is VERY useful, it is not currently possible to do this for graph data. An example of such a call would be: {{logicmonitor_url}}/device/devicedatasourceinstances/229505122/graphs/-1/data?datapoints=sentpkts …which brings back the default graph data (all datapoints), though this would also work for a specific graph. The advantage of this approach to data fetch is that it permits the retrieval of virtual datapoints. In order to achieve the same benefits, we (Panoramic Data) request that the same datapoint filtering is added to the {{logicmonitor_url}}/device/devicedatasourceinstances/{instanceId}/graphs/{graphId}/data endpoint. Of lesser importance would be other graph API endpoints (e.g. the website graph API endpoint) Thanks in advance! David19Views15likes0CommentsSynthetics - add ability to set device/group properties to reference in the .side file
With synthetic transactions, currently the only way to pass a value into the .side file is within the Authentication step during the initial creation of the synthetic check. The values can be referenced withthe credential.username/password/token variables in the .side file. This is pretty limiting, especially since it can only be defined during the initial check creation. If the password changes for my websites test user, I need to delete/recreate the check to redefine the authentication. This causes a loss of historical data. It would be a huge improvement if we could set a property on the synthetic check in LogicMonitor and then reference that property within the .side file. That way if I want to change the username or password for a check which involves a login, I don’t need to delete/recreate the check.15Views10likes0CommentsSynthetics - add ability to update existing checks and download .side file via configsource
With synthetic transactions, currently you need to delete/recreate a check if we want to update it or change the username/password used for authentication. This causes loss of historical data and is difficult to manage. There are 2 things I would like to request that would make it easier for us to manage synthetic transactions. add ability to update an existing check. This includes updating the .side file or updating the authentication Add ability to download the .side file for an existing check via a companion Configsource. This would make it easier to resolve issues with a check and tweak it without impacting historical data.8Views10likes0Commentsimplement better data serialization for active discovery results
A few months ago after being told that SNMP_Network_Interfaces was the new preferred method for network interface data collection (despite it excluding SVI interfaces and using weird backward naming for the property to include all interfaces -- interface.filtering = true), we moved ahead with implementation. We found soon after that the module was corrupting interface descriptions, and a ticket raised with support resulted in the “too bad, sucks to be you” sort of response I often receive. The corruption involves stripping all hash signs from interface descriptions. This may sound harmless, but we have for years told our clients to prepend a # to an interface description to exclude it from alerting, which our automation detects and handles. The reason this happens is because the folks who came up with LM thought it would be a cool idea to use # as a field separator and this was embraced and extended by later developers. There was a solution we recommended (that was rejected) -- specify a transform string so the # becomes something else known we can match without breaking monitoring for thousands of interfaces. My request here is to work out a method to transition from the current field separator mechanism to an actual data serialization method like JSON.34Views5likes0CommentsLM Logs parser conditional formatting operator
Submitted to LM Feedback under the title “LM Logs parser colorization based on criteria” As an engineer who is trying to see how certain logs relate to other logs, it would be helpful if I could highlight specific logs in context with other logs by using an advanced search operator to colorize certain logs that meet a certain criterion. For example, I run this query often: "PagerDuty Ticket Creation" | parse /(.*) (SUMMARY|ERROR|INFO|DEBUG): (.*)/ as Script, Severity, Msg One of the fields I parse is the Severity, which as you can see can have values of SUMMARY, ERROR, INFO, or DEBUG. It would be nice if I could add an operator to the query that would let me colorize rows based on the value of the parsed Severity column (Severity just in this case; for the general case, any expression on any column). For example, I'd like to run the query: "PagerDuty Ticket Creation" | parse /(.*) (SUMMARY|ERROR|INFO|DEBUG): (.*)/ as Script, Severity, Msg | colorize Severity == "ERROR" as orange | colorize Severity ~ /SUMMARY|INFO/ as green The result would be that rows in the table that have a value of "ERROR" would have a background color of orange (a muted orange) and rows in the table that have a value of "SUMMARY" or "INFO" would be colored green. Since the DEBUG logs don't match any colorization operator, they would have the default color of white. It might be handy if one *or* two colors could be passed, allowing me to change the color of the text and the background, or just the background. It would be ok if I could only choose from a set list of colors, but it would be great if I could specify an RGBA color.16Views12likes0Comments