Sarah Terry

LogicMonitor Staff
  • Content Count

    234
  • Joined

  • Last visited

Everything posted by Sarah Terry

  1. Hi @mnagel thats a great idea, thanks for the feedback! We'll see if we can get that on the roadmap
  2. It's possible if the usage is slowly & steadily increasing that the band will adjust to that usage. You can avoid suppression by having static & dynamic thresholds at separate severities (eg static threshold for critical severity & dynamic for warn | error). Sometimes these metrics where you generally know that certain good and bad ranges always hold true (e.g. above 90% is always bad, below 90% is always good) are a better fit for static thresholds. Dynamic Thresholds are most useful when it is not possible or difficult to identify a range generally/globally across all instances (
  3. So you have to specify the externalTicketId custom column in the API request, like this: GET /alert/alerts?customColumns=%2523%2523externalticketid%2523%2523
  4. Hi @Ravi, Yes - The AWS Neptune DataSource was published already & should apply to RDS instances with the neptune db engine property in your LM account. Let us know if you have any questions about this!
  5. @Gary Dewrell @mnagel thanks for bringing this up! The second phase of Dynamic Thresholds (which we are currently working on) will use a combination of duration and percentage of values that exceed a given proximity from "normal", as calculated by anomaly detection, to set severity for alerts that are triggered. I think this will help with what you are asking for, and I can add you to the beta test list if you'd like to receive an invite to participate in beta testing. In the meantime, your best bet is to set the Alert Trigger Interval (within the DataSource definition) to a large enough
  6. Hey @Brandon thanks for posting! We can definitely get an official cloud AD method into the queue (and we'll make sure AD filters are included so discovery can be limited to specific stages)
  7. @BCO assuming you have a website in LM with the exact name 'sitename.com', you should be on the right track. Though, in v2 of the API you should enclose filter values in double quotes (per https://www.logicmonitor.com/support/rest-api-developers-guide/), so try '/website/websites?filter=name:"sitename.com"'.
  8. Hi @Joe Tran - Thanks for the request! I agree that this would be beneficial to see in LM alongside other metrics, and probably not be too difficult for us to collect out of the box (we should be able to add a new cloud collector-based collection method that pulls in the enhanced monitoring). We'll look into adding this into an upcoming release and let you know once we've made progress!
  9. Hi @Mosh - The total number of resources (including those in sub-groups) should be returned in the group object information - i.e. GET /device/groups/ID. This is actually what the tooltip in the UI is pulling from. Have you tried this yet?
  10. @Mosh That is a great point, and one our team uses as part of our follow-up tasks when conducting a Root Cause Analysis (RCA). As much as we strive to monitor everything, gaps may be discovered. To resolve those gaps we have a two-pronged approach. We identify application logic to see if they can be modified to self-recover from a failure. Secondly, we identify ways to have DataSources monitor and alert upon these issues in the future. This cycle is performed consistently with all Service Disruptions. Apologies for the inconvenience as experienced.
  11. Apologies @Mosh - the issue should be resolved now: https://status.logicmonitor.com/incidents/79scd0n8xgms
  12. @daniel Briseno this is possible today with the API & a DataSource, but I do understand the desire to have this out of the box. Can you expand on the end goal here? It sounds like you want to identify the most noisy groups, devices & instances - will you then tune alert thresholds? Our roadmap includes several initiatives geared towards reducing noise & making alerts + thresholds more automated/intelligent, so I'd like to ensure that the root issue is addressed with these roadmap initiatives as well.
  13. Hi @starboy9 - There should be more than 3 TopologySources at this point, and our team is frequently releasing new TopologySources with additional coverage. To get started, you just have to make sure you have the most up to date modules in your account - this page provides getting started instructions: https://www.logicmonitor.com/support/topology-mapping/topology-mapping-overview/. Let us know if you have trouble getting started or additional questions!
  14. Hi @Joe Williams , Thanks for posting! The historical difficulty here lies in the fact that there is no HTTP clone verb. That being said, we recognize the importance of being able to quickly reproduce dashboards & the widgets included (and making the GET / POST requests individually here can be cumbersome). The best current option is to GET the template for the dashboard and then POST a new dashboard using that template (which allows you to reproduce a dashboard and all widgets in 2 requests). Have you tried doing a GET + POST using dashboard templates via API, and if so can you
  15. @gwengrafana the resource path should be: $resourcePath = '/device/devices/465103/devicedatasources/8252658/data to get data for all instances of the Ping DataSource. The Ping deviceDataSourceId in this case is the 8252658.
  16. @gwengrafana there is an example on this page that shows how to get raw data via the API: https://www.logicmonitor.com/support/rest-api-developers-guide/v1/data/get-data/ Getting data for Ping is the same as getting data for any other DataSource, so that example does apply. Your approach looks correct, but make sure you're using the correct Id - you need the deviceDataSource Id, *not* the DataSource Id. /settings/datasources endpoint will only return the Ids of the DataSources in your account, but what you want is the Id of the instantiated Ping DataSource for a given device. If you inste
  17. Yes @Cole McDonald - you can just update that field with a PATCH request & data collection tasks should immediately start being scheduled with the new collector
  18. @Cole McDonald just update the preferredCollectorId for the device (not the system property, but the actual preferredCollectorId field)
  19. @Cole McDonald all system properties are read only, except system.categories (idea being they are set by the "system" - LM). But many of those system properties are set based on the device attributes that you can configure directly, e.g. displayName, preferredCollectorId, etc.
  20. Hi @Cole McDonald - For the query parameters, it should be "?filter=preferredCollectorId:$($fromHost.id)". It's explained here: https://www.logicmonitor.com/support/rest-api-developers-guide/v1/devices/get-devices/. Are you looking at the Swagger docs for v2 of the API? Thanks, Sarah
  21. @Cole McDonald got it - you can change displayname via REST API, but you have to edit the 'displayName' attribute of the device, not the 'system.displayname' property for the device. The system property should update to reflect whats in the displayName field for the device (which can be populated both via UI or REST API).
  22. Hi @starboy9 , The edges are discovered by TopologySources. The TopologySources are usually using some discovery logic (e.g. SNMP, API) to discover edges for monitored resources with ERIs (external resource Ids). The ERI properties are typically populated by PropertySources or DataSource AD scripts. So to ensure edges are discovered (and therefore available for display in maps), you need to ensure you have: 1. imported TopologySources into your account (Settings | LogicModules | TopologySources | Add | From LogicMonitor Repository) 2. imported PropertySources into your account
  23. @Cole McDonald can you clarify your question / what you're trying to do? In general, system properties cannot be directly modified. You can change system.displayname by editing the displayName for the device (via API or UI) & system.displayname will update automatically.
  24. @Cole McDonald @Joe Tran we will improve the documentation for this endpoint - thanks!
  25. Thanks for the request @Joe Tran! The id for the group the property was inherited from is returned if you hit the properties endpoint directly - e.g. /device/devices/ID/properties (there is an object in the response called 'inheritList'). We can look into including this information in the list response as well if you think that'd be helpful.