Popular Content

Showing content with the highest reputation since 11/05/2019 in all areas

  1. 2 points
    Right now, ACK and SDT work, but miss important functionality. Please consider addressing all of these: * ACK should be able to expire (critical issues that should not be lost forever, or to set a maximum expected recovery time period -- not possible with SDT). * ACK should be able to clear if a worse condition occurs (in Nagios, this is a non-sticky ACK) * ACK and SDT notices should be shipped to custom email integrations (this one is a bug as far as I am concerned)
  2. 2 points
    ACK should be removable if determined it was checked incorrectly by a user.
  3. 1 point
    Assuming you leverage and consume custom alert messaging, you can define the KB article at the datasource template level. Taking your CPU utilization example, go to your CPU datasource LogicModule, and add the URL to the custom alert messaging for the desired datapoint triggering alerts. If the KB is different for different subset of resources, then the alert messaging should be updated to reference a custom property that would be assigned to or inherited by the resource. Example ##CPU_KB_URL##, then you would assign/inherit the cpu_kb_url property to your different subsets of resources. This does mean you will have to maintain these properties in LM.
  4. 1 point
    Thinking about this, I would find useful if an acknowledgeded alert that is place into SDT could also become automatically unacked at the end of the SDT. (I'd also like the ability to limit SDTs to no later than n days from timenow.)
  5. 1 point
    Oh it is, but it is definitely a non-obvious side-effect of disabling alerts and re-enabling. I frequently get the feeling different aspects of LM were written by summer interns :).
  6. 1 point
    I'm currently working on building out common dashboards for a large number of subgroups of server resources in our environment (we're a multi-tenant managed hosting company - so one for each of our customer's environments). it's a simple dashboard with 5 widgets. I have each of them driving device selection through a token with our internal unique customer id number. The problem will come if I ever need to change anything in the dashboard... while I built a single dashboard initially, then cloned it 50 times... making any incremental change 50 times sounds like I'm guaranteed a day of annoyance in the future. I'd like to see a way to make a template dashboard that can be linked to so you can change a single master dash and have an entire set of child dashboards change. In our example, the server status dashboards for each of our clients.
  7. 1 point
    Have you looked at the data APIs? I haven't used them myself but seems to fit the request. https://www.logicmonitor.com/support/rest-api-developers-guide/v1/data/get-graph-data/#Get-widget-data https://www.logicmonitor.com/swagger-ui-master/dist/#/Data/
  8. 1 point
    Yeah about new ui, please dont move forward with that thing, is pretty uncomfortable to the eyes, current UI is WAY MUCH better and comfortable and simple...
  9. 1 point
    The use of screen real estate is horrible too. On my 15" Macbook Pro I can only see a handful of alarms at one time and clicking into the alarms is very tough to use since it uses that same small area for the alarm details. Need to find a way to hide the filter and move more of that stuff up on the screen.
  10. 1 point
    One day we might get a dark theme... 😀
  11. 1 point
    We continue to do battle with LM when alerts trigger due to dependent resource outages. I know the topology mapping team is working on alert suppression, but I am not convinced that will solve all problems regardless of how well they succeed. We really need a way to setup dependencies within logic modules and it should not need dozens of lines of API code each time (most of which should be made available as a library function IMO). One fresh specific example -- site with multiple firewalls in a VPN mesh running BGP. One firewall goes down, then all other firewalls report BGP is down. We care about BGP down, so we have alerts trigger escalation chains. It should be possible to define a dependency in the datapoint that suppresses the alert if the remote peer IP is in a down state. There is no way to express this in LM right now and that leads to many alerts in a batches, and that leads to numb customers who ignore ALL alerts.