Sarah Terry

LogicMonitor Staff
  • Content Count

    232
  • Joined

  • Last visited

Community Reputation

20 Excellent

3 Followers

About Sarah Terry

  • Rank
    Legend

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. So you have to specify the externalTicketId custom column in the API request, like this: GET /alert/alerts?customColumns=%2523%2523externalticketid%2523%2523
  2. 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!
  3. @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 value that you can ensure that triggered alerts catch the uncommon issues and not routine events.
  4. 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)
  5. @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"'.
  6. 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!
  7. 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?
  8. @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.
  9. Apologies @Mosh - the issue should be resolved now: https://status.logicmonitor.com/incidents/79scd0n8xgms
  10. @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.
  11. 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!
  12. 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 provide more detail on the shortcomings of that option for your use case (e.g. unhappy with having to make two requests, takes too long, etc.)? I think there is room for improvement on our end, perhaps we could add a convenience clone function into the SDK or implement the clone RESTfully directly in the API (e.g. adding a query parameter to the POST option for dashboards to clone from an existing dashboard). Can you also comment on whether you'd want the ability to change configuration during the clone, or whether you're looking for an exact clone & will edit / customize afterwards? I want to make sure we understand your full workflow. Thanks! Sarah
  13. @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.
  14. @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 instead request /device/devices/ID/devicedatasources, you should see Ping in that list with the deviceDataSource id, which can be used in the get data request.
  15. 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