EventSentry Help v5.2

EventSentry monitors the event log when it is running. When the service is not running (such as when the system is being rebooted), it is unable monitor the event logs. Event log entries created while the service is stopped are not processed.

To avoid this problem you can configure EventSentry to look for events created after the service was last shut down by setting this feature to "most". Every time the service starts it scans the event log from the last checkpoint. This feature is also useful in determining if a server was rebooted.

Most: EventSentry will re-scan the event log and process events that occurred while the service was stopped.

Regular: EventSentry will monitor the event log right after the service was started, but will not process events that occurred while the service was stopped.

Least: EventSentry will ignore events that occurred for the first X seconds after the OS booted. For example, if EventSentry emails you a lot of events when a server is rebooted, then you can configure this feature to suppress events for a given amount of seconds. Click the "Settings" button to bring up the "Boot Delay Settings" dialog that lets you configure the interval and to which action types this feature applies to.

This option controls how hosts identify themselves in the web reports.

NetBIOS

By default, computer names will appear with their NetBIOS names (e.g. SERVER1) in alerts and the web reporting.

FQDN

Hosts will show up with their respective FQDN names instead (e.g. server1.yourdomain.local) of just the host name. Please note that you will have to restart the agent for this change to become effective.

Alias

Forces hosts to show up with the name defined in the management console instead of their actual host name. This setting requires that at least one active IP address matches the IP address configured for the host name in an EventSentry group. This setting is useful for environments where hosts with identical names but from different sub nets connect to the same EventSentry database. When configured, also supports the $HOSTNAMEALIAS variable.

Certain action types, including email, database and Syslog, have the ability to cache events when the configured server is temporarily unavailable. This setting allows you to configure the maximum amount of disk space that EventSentry will use in the system temp directory (%TEMP%) for caching events.

This setting also applies to the storage used for the summary actions.

Maximum number of alerts

Many features, including environment monitoring, disk space and service monitoring write alert messages to the event log when a certain problem (e.g. low disk space, high environment temperature, etc.) is detected. To avoid the event log from being flooded with the same event pertaining to the same problem you can set a maximum notification interval here.

For example, if you set a maximum notification interval of 24 hours then a low disk space warning regarding drive C will only be logged once every 24 hours until the low disk space problem is resolved.

Disk Space Alert Throttling

By default, disk space monitoring throttles alerts based on an internal algorithm. This is to avoid excessive events in situations where disk space frequently fluctuates between above and below a configured threshold. Enabling this option will disable throttling and always log all disk space alerts to the event log.

Event Severity

By default, performance & disk space monitoring features log events with the same event severity (as configured in the object) regardless of whether an issue has been detected or resolved. This is so that default event log filter rules process both alert & resolution identically.

Since this can both be confusing (an issue is resolved but logged as an "Error"), this setting overrides the default behavior and will log events that indicate that an issue has been resolved with the selected severity.

This setting only affects Performance Monitoring & Disk Space Monitoring.

Starting with version 3.0, EventSentry can write all time stamps in the UTC time zone to the database. This is helpful for networks spanning multiple timezones, since the web reports can display all data in the local time zone of the currently logged on user.

UTC support is enabled by default for new installations, and can also be switched on for users upgrading from earlier installations. Once enabled, UTC support cannot be turned off again.

UTC only affects the web reports, alerts generated by the agents for example still use the time stamp from the local time zone the agent is located in.

When maintenance schedules are created for a group or host, they only apply to heartbeat alerts generated by the Heartbeat Agent; any alerts (e.g. event log alert via email) are still sent out by an agent.

To suppress all email alerts during a maintenance schedule, check the "All email actions" check box; check the "All pager actions" check box to suppress all pager alerts.

Both check boxes are checked by default with new installations.