The Events and Notifications app logs all types system events on the server. Alerts could be informational, as in User xyz logged in at hh:mm or of a more critical nature - Disk space exceeded 95%.
Alerts are generated in real-time using a daemon that tracks log files or are generated with the ClearOS API.
If you did not select this module to be included during the installation process, you must first install the module from the Marketplace. Use any of the Marketplace tags in the next section to help you find the app.
LOG LOGGING EVENTS ALERTS COMPLIANCE VIEW SYSTEM STATUS HEALTH
Once installed, you can find this feature in the menu system at the following location:
<navigation>Reports|Performance and Resources|Events and Notifications</navigation>
Events are classified into three categories - Informational, Warnings and Critical.
Informational events are those that do not pose any risk to the normal operation of your server. An example would be a validated user logging on to the server over a VPN tunnel.
Warnings are those that may pose a risk to the normal operation of your server if left unattended. An example would be a disk partition that has exceeded 90% capacity.
Critical events are those that have already caused some level of degradation (service, security, performance etc.) in the operation of your server. An example would be a kernel OOM event that has shutdown the proxy server.
Events can be acknowledged by the administrator by clicking on the “Acknowledge All” button located in the title summary of the event list table.
Acknowledging all events will, in most cases, clear the alert notification counter in the navigation bar.
Acknowledging events does not delete them from the table list. Use the Delete option (outlined below) if you would like to delete all records of events that have occurred on the server.
There are occasions when acknowledging alerts will not clear the alerts from the navigation bar…This is part of the design of the alerts system and is not a bug.
Alerts that are generated on the system can have a flag that allows them to be 'acknowledged' or not. Some events cannot be cleared just by acknowledging them. Two examples are:
In the above case, the acknowledge action can only happen when the issue is resolved and detected by a closed-loop mechanism. For the two examples above, removing the firewall rule that caused the firewall to panic or renewing a subscription and re-registering the system would close the loop and automatically resolve the events causing the alarm.