This is a maintenance release, with new features introduced, and bugs fixed.
- Syslog messages monitor has been added. It listens to incoming messages in both old RFC 3164 and new RFC 5424 format (detected automatically). You can fine tune your monitor to listen to specific messages, and react with an event. Syslog monitor behaves similarly to SNMP Generic Trap monitor; they share the “Event timeout” feature that sets monitor to Down when there was no relevant messages within a certain period of time.
- Windows Event Log has been added. Monitor calculates number of events added to the specified event log channel for specified timeframe, using Windows API. Monitor is available for operating systems starting from Windows Vista and Windows Server 2008. Event Log monitoring isn’t available for Windows XP and Windows Server 2003 systems.
- FTP monitor now supports 3 more options to secure the connection:
- “FTPS” – implicit FTP over TLS which usually uses 990 port
- “FTPES” – explicit FTP over TLS that requires encryption support
- “FTPES, if available” – explicit FTP connection with non-obligatory TLS support
- Starting from this release the “Current” column of “Summary” and “Trends” reports contains exact the same value representation as in Monitor tree. For example, for SNMP Custom monitor with the “Value Change” counter type the “Current” column displays both current state and current value.
Client Application and Monitoring Service
- When you rename or create a host or a host group, all trailing spaces and line feeds (“\n” characters) in its name are stripped out for the sake of convenience and naming consistency.
- Standard host groups can now be deleted
- Added option to select multiple SNMP versions in SNMP MIB Browser Configuration. The SNMP MIB Browser will attempt to connect using each of these versions until the connection is successful or all versions are tried.
Alerting and Actions
- Support for “Send AOL message” and “Send ICQ message” simple actions has been removed due to their end of support and lack of up-to-date documentation. Note: make sure you migrate to other means of notification as these actions will be completely removed by the new installation.
Spike filter now ignores “Unknown” monitor state and checks last “Active” state of a monitor when deciding whether to skip polls. Thus short spikes in performance taking place immediately upon Monitoring Service startup are filtered out and state changes do not occur. For example, “Apache Web Server used by IPHost” application monitors do not change their state to “Down” for a short period right after the Monitoring Service startup and alerts are not executed.
On the other hand, if last active state of a monitor before the Monitoring Service restart was already a problem state, then spike filtering is not applied. Monitor enters the same problem state immediately.
This approach minimizes amount of false state transitions and alerts and avoids needless spike filtering at the same time.