Bryan_Fehl
Joined 8 years ago
User Profile
User Widgets
Contributions
Re: Dependencies or Parent/Child Relationships
This is great! I'm testing this now in our environment. One thing that would be useful for us is allowing us to suppress alerts when DNS resolution is failing to a particular device. For example, we have a tunnel between two locations, and several monitors on the other side of the DNS server. If DNS resolution breaks, all monitors using hostnames are going to break. It would be nice to only be alerted once for the DNS problem, not the individual devices that are having DNS problems. Edit: Oh shoot i just noticed this doesn't support services currently. That is mostly what we'd use this for. Our use-case is that we have a large number of URL monitors that are monitoring from the location of users, to systems running the cloud. When we have a DNS problem, we get hundreds of alerts all at once for the same issue, which is obviously not ideal. We would definitely need this to support service monitors.6Views0likes0Comments"Sticky" Device Group handling for dashboards and alerts
One of the biggest frustrations for us with LogicMonitor is breaking a bunch of dashboards and alerts if we move device groups to another location in the overall device group tree. For example: Say we have a nested device group called "Infrastructure/Hosts". Now our environment has changed a bit, and we want to add better organization to support the new changes to our environment. We move the hosts group to the following location "Infrastructure/PhysicalDevices/Hosts". All alert rules and dashboards that were filtering on "Infrastructure/Hosts" have now been broken, even though the devices in the group need the same alerting and dashboards. Now we have to go through and fix each Alert Rule and Dashboard Widget that used "Infrastructure/Hosts" to now point to "Infrastructure/PhysicalDevices/Hosts". As you can imagine, as environments scale up and evolve, subgroups are going to be moved around all the time. Redoing dashboards and alerts every time this happens adds a tremendous amount of labor, and can lead to people missing changes, leaving behind broken alerts or dashboards that you may not find out about until an emergency has already happened. What we're proposing: "Sticky" device group handling - If a group or subgroup used in an Alert Rule or Dashboard changes location, this location should automatically be updated and reflected in the dashboard. This is how most modern applications handle this sort of thing anyway, and it's a huge time saver. Given the critical nature of this tool's function, this would go along way towards preventing accidentally breaking monitoring that companies rely on to keep their environments running.1View0likes0CommentsRe: Ability to apply retroative SDT-like windows to adjust SLA numbers
This would also be useful for scenarios where the data collection malfunctioned, but it was an issue on the Collector side rather than the device side. Being able to correct SLA's for these devices by applying the retroactive SDT would help keep those SLA numbers accurate.2Views0likes0CommentsVMware vSphere log monitoring
The Windows EventSources monitoring has been very useful for us, and we were hoping to be able to replicate the same with vSphere's logging (vCenter, vpxd, etc). Right now our only alternative is leveraging VMware's "Log Insight" tool, but we were hoping to have this integrated into LogicMonitor so we're not duplicating monitoring across separate monitoring tools.6Views0likes0CommentsRe: Make Instance Groups searchable/filterable
I agree with this. Being able to filter alerts on instance groups would be particularly valuable to us, because we have some instances grouped by Production/Non-Production, and the ability to separate these two groups into separate emails (Production would generate a page through PagerDuty, for example, while Non-Production would just send an email notification).4Views0likes0Comments