stuart_vassey
Joined 8 years ago
User Profile
User Widgets
Contributions
Re: Ability to apply retroative SDT-like windows to adjust SLA numbers
Forrest, when SLAs are reported as un-met, but it wasn't the service owner's fault, there needs to be a way to not penalize them. For example: 1) When the LogicMonitor platform has an outage (I've seen this happen and created tickets) 2) When a new EA collector crashes or has a bug with script execution (I've seen this happen and created tickets) 3) When the monitoring team accidentally breaks a datasource, which mistakenly marks a service down (this is not uncommon) In all of these cases, SLAs would be inaccurate and if the monitoring team has no way of applying retroactive adjustments, we'll have to explain to the business that "this month's numbers aren't valid and can't be used for business purposes." That's not the story we want to tell about LogicMonitor since it hurts the credibility of the platform. I hope you see that this is different than just forgetting to schedule a maintenance window. If LogicMonitor wants to become more business-facing, this is a necessary feature. Thanks, Stuart7Views0likes0CommentsRe: Audit Log Enhancement for API Activity
I think that would help, @Sarah Terry. The main issue I'm trying to avoid is this: we recently went through and removed users with no recorded activity. Some of them ended up being API users that were heavily used, but "Last Action" date from the users screen was blank and there was no activity in the audit log.8Views0likes0CommentsAudit Log Enhancement for API Activity
Today, the audit log captures any changes that an API user makes, but doesn't record any activity if you are just making queries. It would be valuable to log all types of API calls to comprehensively monitor API user behavior. This could be done with one of the following: 1) A separate API-only audit log 2) Bundled with the existing audit log 3) The existing audit log could have an easy filter to hide API calls and reduce noise18Views1like4CommentsPermissions 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.28Views4likes1CommentAbility to apply retroative SDT-like windows to adjust SLA numbers
When a monitor malfunctions (e.g. service test fails because the monitored site HTML was updated) the uptime for that test will not reflect the site's actual uptime. We'd like to be able to apply retroactive SDT-like windows that would prevent an alert period from counting against a test's uptime. I thought this ability was already available by applying retroactive SDT's, but apparently this isn't actually working. Without this feature, a dashboard SLA widget might report a service/device being up 70%, but it was really up 90% while 20% of that time it had a faulty test/datasource. We should be able to apply an SDT to keep that 20% from negatively impacting the uptime.25Views1like8CommentsAutomatically Update AWS Instance Display Name
Today, the system.displayname property for an AWS device is not automatically updated when the "Name" property in AWS is changed. It would make it easier to see which devices we are actually monitoring if the display names in LogicMonitor were synced with the current "Name" property in AWS.9Views1like1Comment