Custom Alert-Groups for SDT
When we reboot a Server or a Application Set our NOC does not know all the Devices, Instances and/or services impacted so we get flooded with alerts for a known event. Example: I need to reboot device WebServer-xyz - TheServer, the Switch ports, Storage Sessions and HTTP/S Service are all monitoredin LM Like to be able to SDT just these items with one SDT, and not entire switches or devices. So be able to create an "Alert-Group"ie "WebServer-xyz" where you can then add Instances from multiple devices, entire device, Service, Instance Groups, Device Group aka any defined in LM. Then just Add one SDT to the Alert-Group aka one-stop-shopping.10Views0likes1Comment
Alert clustering based on matching datasource instances across grouped devices
I have a device group that has the same datasource applied. This datasource auto-discovers and will spin up matching instances across all devices in the group. I would like to have clustered alerts based on the matched instances across all devices in the group. For example, (pardon the ASCII-like visualization) ClusterGroup |__ Device1 | |__ DatasourceA | |_ Instance_ABC | |_ Datapoint_I | |_ Datapoint_II | |_ Instance_DEF | |_ Datapoint_I | |_ Datapoint_II | |_ Instance_GHI | |_ Datapoint_I | |_ Datapoint_II |__ Device2 | |__ DatasourceA | |_ Instance_ABC | |_ Datapoint_I | |_ Datapoint_II | |_ Instance_DEF | |_ Datapoint_I | |_ Datapoint_II | |_ Instance_GHI | |_ Datapoint_I | |_ Datapoint_II |__ Device3 |__ DatasourceA |_ Instance_ABC |_ Datapoint_I |_ Datapoint_II |_ Instance_DEF |_ Datapoint_I |_ Datapoint_II |_ Instance_GHI |_ Datapoint_I |_ Datapoint_II If Instance_ABC's Datapoint_I is alerting at the specified cluster threshold in my hypothetical group, I want to generate a cluster alert. If some time afterwards, the situation in my environment gets worse and Instance_GHI's Datapoint_II is alerting at the specified cluster threshold, I want another cluster alert for that instance-datapoint as well.10Views0likes1CommentManaging Alert visibility on a "per-group" level
Good Morning all, we are a multi-Team managed service providerwho, surprisingly, manages customers team-wise. We are in the process of switching to LogicMonitor right now and we have some issues regarding shared devices and theirDataSource Instances, that belongs to different teams. We created Devicegroups for our teams, but if we put shared devices like loadbalancer, firewalls, storages etc. in said groups, ALL teams will see ALL alarms, regardless of responsibility. If one team decides to turn off an alarm on a shared device, the alarm is obviously deactivated on all other teams, as well. I'm aware of the Datasourceinstance grouping mechanism, but afaik it cant help with the problems i mentioned. We would like to request a feature where you can somehow mask datasources,their instances and their respective alarms based on the group you are in while you're viewing the device, so alarms andinstances that don't belong to your team doesn't show up at all. It would be really convenient to somehow configure a "view" of a device based on the group you are in that doesn't interfere with the devicedatasources. Bonuspoints if you bring in alarm-tuning in this somehow. :)/emoticons/smile@2x.png 2x" title=":)" width="20"> Regards, Bastian5Views1like3Comments
Permissions for Datasource, Alert, and Escalation Chain Groups
As we move towards a DevOps model, we increasingly have a need for small teams to have full admin access to the tools they use to manage their IT services. When it comes to LogicMonitor, this has proven difficult with the existing role permission model. DevOps pods would like to be able to manage their own datasources, alerts, and escalation chains but this isn't possible unless we give them broad access rights to those areas, which could cause significant harm to other groups of monitoring users. For example, an inexperienced DevOps user could inadvertently modify a datasource that applies to all Windows devices or they could create an alert rule that causes alerts not to be delivered to other users. To solve this problem, I'd propose that LogicMonitor offer alert groups, escalation chain groups, along with the existing datasource groups. Then, LogicMonitor could provide the ability to restrict roles to manage these specific groups. DevOps pods could be given the ability to manage their own custom subset of datasources and set up their own alerts in a rule range after the main set of rules.4Views4likes1Comment
Enhance UI to control which Groups show in Alert widget
We have devices that need to be members of multiple groups to keep ournotifications simple. Currently, in the alert widget, all group memberships are shown in the Group column. We would like to be able to select which groups should be visible in the Group column. Usually it's the main business service group, and not the technical groups used only for alert rules. Also, we would like the groups in the Group column to be alphabetically sorted. Orderseems random at the moment. Readability would be improved also if each group in the Group column was on a new line.4Views1like1CommentCollector dynamic groups
Collector groups were added recently, and are detailed here:a href="https://communities.logicmonitor.com/topic/637-collectors" rel="">https://communities.logicmonitor.com/topic/637-collectors Now let's expand upon that functionality...What ifcollectors be grouped dynamically? Identically to how Devices dynamic groups work,could I assign properties to collectors, then build dynamic groups based from the properties? Ways thatenvision sorting collectors: Production/test, primary/backup,collector number (1-99, 100-199, 200-299, etc.),zip code, time zone, alphabetical. In each of these cases, this would give full flexibility on how collector upgrades are scheduled. Currently if we have a mass collector upgrade to a new General Release, it can be a little painful to manage so many upgrades running simultaneously (or at least in very short order). I am most interested in being able to split them up into primary, backup and single collector groups. This way, I know that it's pretty safe to upgrade the collectors that have backups after hours, since there is another collector to failover to. And I surely want to be available staff-wise if I am doingupgrades for those collectors that have no backup collector. Close behind sorting into primary/backup/singleis the need to sort them by customer (which currently works fine). The issue is that you can't put a collector into more than one group, which precludes from even setting up these to items manually.3Views1like1Comment
Gather and store more relevant WMI data for auto-grouping and category population
During the initial and periodic device auto-discovery tasks, there should be far more information stored about each device. This information should be easily accessible from the device information page and populated with data such as "Installed Programs", "Installed Features", "Running Services", "Domain Role", etc. This information could then be used to auto-group devices. For example, I should be able to create an auto-discover rule that automatically grabs all Domain Controllers based on the system.installedservices and system.installedfeatures categories. There is no reason I should have to manually movethis server that is clearly a Domain Controller into my group labeled "Domain Controllers". This approach would allow administrators to "set it and forget it" instead ofhaving to be hands-on every time a new device is added or discovered. This data can be easily populated from standard WMI classes: system.installedservices = win32_services.displayname system.serverfeatures = win32_serverfeature.Name Please help me organize my devices automatically. We have too many machines in too many environments to manually sort them allinto groups.2Views0likes3Comments"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.1View0likes0CommentsAlert Groups
Hi, We get quite a few alerts in our LM, about 90% of them are made up of a few problems, like Vmware storage luns. It would be useful to be able to group these, to get rid of the 'noise' calls so we can focus on the more urgent ones. What would be even better would be if you could assign permissions to these groups. For instance, the first line can see certain groups and third line can see other groups. Kris1View0likes0CommentsHidden device group memberships
Please add an option on group objects to hide the group from being vivisble in the Alert widget's Group column. Please see attached screen cap. I have some devices which are members of two device groups. One group (Interoute) is the business service, the other (Routers Primary) is usedpurely to gather all devices of a type together to run a report against. I don't want the Routers Primary group to be visible in the Alert widget Group column. A checkbox on the group object to hide from widgets would be ideal.0Views0likes2Comments