Understanding alarms
An Apex alarm monitors the thresholds of widgets in a dashboard. If any widget crosses a set threshold, the alarm is triggered. A triggered alarm sends notification messages to the server and recipients you specify.
If any widget within a chosen dashboard crosses a threshold, the alarm is triggered. Not every widget in a dashboard needs to be in an “alarmed” state for the alarm to trigger. One widget crossing a threshold is sufficient for the alarm to trigger. This means you might receive multiple alarm notifications depending on how many widgets are crossing thresholds in the dashboard. Also, because there are marginal and critical thresholds, you can choose if the alarm should trigger from crossing the marginal threshold or the critical threshold. This is configurable in the alarm.
A triggered alarm sends an alarm notification to specified servers and recipients. The servers and email recipients receive alarm notifications as soon as a specified threshold is measured to be crossed, such as a marginal threshold. A short delay may occur between when the network events occur and the alarms are sent. This is due to the nature of a data collection transfer interval. Mission critical alarms, where timing is most important, should be made directly in Observer.
The underlying trending data that can trip your alarm is selected by you. Alarms are set “against” a chosen business group or probe instance; it is a requirement for each alarm you create that you set which business group or probe instance could trigger the alarm. This means that data collected by the chosen business group or probe instance is the only data used to determine if your specific alarm will trigger or not. Simply, you should create an alarm for each business group or probe instance that matters to you. You will receive alerts for the business groups and probe instances that your alarms are monitoring, only.
An alarm can be filtered. Filtering can help narrow or broaden what actually triggers the alarm. For example, typing app http in the filter box of the alarm settings means HTTP metrics are all that may trigger an alarm because it is the only application of interest. This filtering is additional to any filtering done on the business group, dashboard, or widgets. Therefore, if a dashboard or all of its widgets are always filtered to show MySQL traffic, giving this dashboard an alarm for HTTP is not meaningful. Using narrowly-filtered alarms on broad, unfiltered dashboards and widgets may be a good method to follow unless you are comfortable managing filters at each level.
Your web browser can be closed and alarms will still operate. Alarms have no dependence on you actually being present in a web browser session for the alarm to trigger. Because alarm triggering and alarm actions, like sending an SNMP trap or email, are performed entirely server-side, you only need to create or edit the alarm from your web browser and that is all. Apex will do the rest.