SentryOne Portal: This feature is available in SentryOne Portal, which shares the UI experience of SentryOne Monitor. To learn more about configuring your environment to use the on-premises, browser-based option with your existing SentryOne database, see the SentryOne Portal article.
See the Monitor Alerts article for an example of how alerts appear in the SentryOne Portal.
Note: The configuration option shown for SentryOne Monitor does not exist in SentryOne Portal as that is all done through the SentryOne client.
Alerting and Response System
SentryOne employs a comprehensive alerting and response system. The alerting and response system uses the concept of Conditions and Actions. Conditions describe the various states of monitored objects. SentryOne allows you to define criteria for when Conditions are met using various Settings like Condition Settings. As a response to Conditions taking place, Actions can be configured. You can refine how often Actions are carried out using Response Rulesets. To control the time frame of when an Action is processed you may apply a Window directly to any configured Action.
Conditions and Settings are all hierarchical, working through the principle of inheritance. Conditions and Settings applied at the global level (All Targets node), are automatically inherited by all objects below that node. Any inherited Conditions or Settings can then be overridden at each lower level as needed. Open the Conditions pane by selecting View > Conditions; open the Settings pane by selecting View > Settings.
Note: You can design your alerts and responses at a high level (global / All Targets) and then fine tune them as necessary at the lower levels (sites, targets, target groups, instances, objects). For a visual representation of these different levels, see the Alerting and Response System Hierarchy diagram.
The following table contains a brief description of the different concepts within the SentryOne alerting and response system. For detailed information concerning each concept, select the links to open the individual sub-topics.
|Contact Management||The Contacts node is used to create and maintain Users and Groups within your SentryOne environment. Once a User or Group is created they can be chosen as a target for the Send Email /Send Page action.|
|Conditions||Conditions describe the various states of monitored Event Objects or associated Performance Counters. You define Actions to take when Conditions are met.|
|Condition Settings||Condition Settings allow you to define rules that a Condition must meet for the Condition to be fully satisfied. Condition Settings are applicable to most General Conditions and all Audit and Failsafe conditions and are configured using a visual Filter Editor.|
|Actions||Actions determine what happens when a Condition is met, including sending notifications, executing a process, etc.|
|Settings||Settings define criteria for when a Condition is considered to be met, including runtime thresholds for events that are captured. Source Settings define what events are collected by SentryOne.|
|Response Rulesets control how often Actions are taken in response to Conditions being met. Response Rulesets assign additional criteria on top of the Condition itself that must be met before an Action takes place. The default setting is Notify EveryTime.|
|Windows||Windows may be applied directly to any configured Action to control the time frame of when that Action is processed. Windows may also be applied to Users or Groups.|
|Object Groups||Object Groups exist outside of the normal SentryOne Hierarchy. An Action or Setting configured for an Object Group is applied last, after any inherited or explicitly defined Action or Setting. Object Groups are useful when you need to apply like policies to a set of objects that don't exist within the same hierarchical groups in your SentryOne environment.|
Actions and Settings have a hierarchical configuration, meaning that Settings applied at the global level (All Targets) are automatically inherited by all objects below that node. Inherited Conditions and Settings can then be overridden at each level as needed. These new Conditions and Settings are then inherited by each object below that level. The following diagram shows the flow of inherited Conditions and Settings. It also shows those levels at which the Conditions and Settings panes are available for configuration.