Documentation forSQL Sentry

SQL Sentry Actions & Alerts Overview

SQL Sentry Portal: This feature is available in SQL Sentry Portal. To learn more about configuring your environment to use the on-premises, browser-based option with your existing SQL Sentry database, see the SQL Sentry Portal article.

See the Alerts Log article for an example of how alerts appear in the SQL Sentry Portal

Alerting and Response System

SQL Sentry 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. SQL Sentry 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.

SQL Sentry Conditions pane

Open the Settings pane by selecting View > Settings.

SQL Sentry Settings pane

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 SQL Sentry alerting and response system. For detailed information concerning each concept, select the links to open the individual sub-topics.

Concepts

Concept Description
Contact Management The Contacts node is used to create and maintain Users and Groups within your sqlsentry 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 SQL Sentry.

Response Rulesets

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 ObjectGroups exist outside of the normal sqlsentry 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 SQL Sentry environment.

Alerting and Response System Hierarchy

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.

SQL Sentry SQL Sentry Hierarchy Example