Event Monitoring Improvement (v2)
I posted a year ago about some improvements to the Windows event monitoring that is available when setting up a threshold in Atera
(https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/44256255-event-monitoring-improvement).
But there are more issues with it that should be addressed...
When creating/modifying a threshold in Atera to monitor Windows Events, there are 5 options. Selecting "Events Applications", "Events Security", "Events Setup", and "Events System" is mostly useless because the only filter is to exclude specific events. It would be far more useful if we could opt to instead only include specific events so it isn't so noisy.
The fifth option is "Events by Source". This is probably where most people will try to setup some event log monitors. The problem here is that while the option says "events by source", it isn't actually "by source". There are 3 primary elements to a Windows event when it is recorded - 1.) the log it's recorded to, 2.) the source of the event, and 3.) the event ID. Atera treats the log as the event source (ie: Application, Security, Setup, and System - sorry no forwarded events). This is confusing because the actual source of an event is something other than the log. An actual Windows event source will be something like WMI, VSS, Application Error, .NET Runtime, Outlook, Service Control Manager, etc. These sources will write the event to a specified log (ie: Application, Security, Setup, System, or the source's own custom log).
Here's why this is a problem...
I want to monitor for application hangs/crashes and for my backup app, so naturally I want to monitor the Application log for event ID 1002. The actual source of this event ID is from "Application Hang" and it can be found in the Application log. In Atera you can configure this by monitoring "Events by Source" and selecting the "Application" folder, then monitoring for event ID 1002. But my backup app also writes to the Application log. When the backup fails it writes a message to the log with event ID 1002 but from a different source (the actual source, not what Atera is calling a source). I would like to attach a script to the threshold when my backup fails, but not when an app hangs or crashes. Right now with Atera I cannot do this at all because it will register the same event from both sources as the same - both record the event to the Application log and both use event ID 1002, so for Atera these different events are the same.
Here's how I think Atera can remove some of the confusion and allow us to monitor for the things we actually need:
1.) Change the term "Source Folder" to "Log" in the UI. The log selected here is just a log, it isn't the source of an event.
2.) Allow us to specify the source of events in addition to the log and event ID. This way I can have one threshold set to monitor the Application log for event ID 1002 coming from the "Application Hang" source, and also have it monitor the Application log for event ID 1002 coming from the "My Backup App" source.
I'd also like to add that I wish to monitor many more logs than what Atera provides access to. Open the Event Viewer in Windows and expand "Applications and Services Logs", then expand "Microsoft", then expand "Windows" - there are several logs in here that I want to monitor. They're off by default, but it's trivial to enable them. But since I've turned them on, I'd like to be able to monitor them and setup automatic actions/scripts to run when certain events are recorded.
I really hope this gains traction, because event log monitoring is pretty elementary in Windows and is something other major RMM providers give lots of control over out-of-the-box.
There are also many other applications and services that are registered with the Windows Event Viewer that I would like to monitor as well, some of which include Microsoft Office, Hardware Events, Intel, Splashtop, Powershell, etc. Being able to monitor these logs and setup automatic actions for detected event IDs in these logs would be so beneficial!
-
David Yoder commented
Here's a great example of why this in important, and many of you have probably see this in your own environments...
I recently turned on Atera's prebuilt Event Log monitors to watch for the event IDs associated with installing and uninstalling applications. I quickly found out that without being able to filter what actually triggers the alert, these were far too noisy. But more importantly, Atera is gathering the wrong information sometimes.
Event ID 1033 is one of the IDs for installing new software when the event source is "MsiInstaller". But because Atera is blindly looking for event IDs alone, it's also getting event ID 1033 from the "Security-SPP" event source which has nothing to do with installing software. So if you've created or tried to create tickets from these notifications, you'll need to weed out the ones that are irrelevant. This isn't just inconvenient, it's actually supplying you with incorrect data.