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.5Views4likes1Comment
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.4Views1like1Comment
Managing 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, Bastian6Views1like3CommentsCollector 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.4Views1like1Comment