Skip to content

Settings and activity

3 results found

  1. 30 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Nice! The feature you requested is being reviewed by our product team. We’ll keep an eye on the number of votes, and let you know if a decision is reached to implement. Thank you for being a partner in our process!

    An error occurred while saving the comment
    Brad Shaffer commented  · 

    There is great inconsistency with the way Windows Event log monitoring is currently handled.

    Before February 2022, monitoring custom event logs (such as the Windows Server Backup operational log) automatically created Critical alerts if an Error event appeared in the Windows event log. This allowed monitoring of the entire log without having to define individual event IDs that should trigger critical alerts.

    Then in February 2022, the behavior changed such that ALL events in a custom monitored log generated Atera Critical alerts -- even informational log events. This yielded a flood of erroneous alerts in Atera.

    On/about February 22, the behavior reverted back to the old way...which was the more logical way.

    Then on February 26, the new behavior returned and the log monitoring is now treating ALL operational log entries according to the threshold level defined. That is, even informational items are creating critical Atera alerts.

    The only work around seems to be to create a tedious, lengthy list of ALL possible Error events for a particular log and define them in a Critical threshold rule. Then, PRAY that you've actually accounted for all possible error events so the monitoring rule can properly notify you when an error occurs.

    This definitely needs some more polish.

    There needs to be an option to monitor ANY windows log for a defined Windows event level.

    Here are examples of how the threshold monitoring rules should work:
    If Windows Error Event of any kind is encountered, create an Atera Critical Alert.

    If a Windows Warning Event of any kind is encountered, create an Atera Warning Alert.

    If a Windows Event ID of XXXX is encountered, create an Atera YYYYY alert.

    Brad Shaffer supported this idea  · 
  2. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Brad Shaffer supported this idea  · 
  3. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Brad Shaffer commented  · 

    There seems to be some inconsistency in how Atera Event monitoring is handling these events now. Typical System, Application and Security monitoring rules seem to handle thresholds based on the Windows Event level. However, custom event monitoring for other logs (such as the Windows Server Backup Operational log) creates Atera alerts at whatever level you define. This is creates a mess if you are just intending to monitor the log for all Warnings and Errors.