The alerts module assists in the prevention of errors and allows the creation of alerts on multiple levels. It allows us to automatically detect unanticipated outliers, anomalies, and errors and create watchdogs that alert a user or a group of users in multiple ways.
The alerts are split into two general types of alerts, and each server needs to be monitored for both types. For a full list of supported alerts, please review Appendix A – list of supported alerts.
OS Alerts – any operating system information-related alerts. The following are alerts that are based on OS-related information. The categories in OS Alerts are Health Check, Logical Drives, Memory, Monitor, Process Performance G Processor/CPU. For example, alert “CPU above threshold.”
SQL Alerts – all alerts that are directly related to SQL Server. The categories in SQL-related alerts are Always on, Backups G Recovery, Database Properties, Database Files, Database Monitoring, Database Properties, Health Check, Monitor, Scheduled Operations, and Server Diagnostics. Inside SQL Alerts, some alerts relate directly to the level of the database, while others are at the level of the whole server. For example, alert “Database has no backup”.
Understanding alert attributes
Active alert – an alert may be active until it automatically becomes inactive or is deleted by the user. For example, if we have the alert “CPU above threshold” set to be raised on the CPU at 20% and the CPU is at 25%, the alert will be raised and activated. However, if the CPU is reduced to 15%, the alert will still be displayed, but not as active.
Dismissed alert – You may choose to mark an alert as “automatically dismissible.” In that case, if the alert conditions are no longer met, the system will automatically dismiss the alert. It will remain in your history, but not active. The user may manually dismiss an alert as well.
Alert Templates
When using the alert module, we highly recommend using alert templates and attach/affiliate the template to each server. The attached template will immediately associate all template alerts with the attached server and will save you a lot of time.
The defined alert configurations percolate from the template level to the server level and to the database level.
An alert can then be customized for a database or server. By customizing an alert on the server or database level, we actively “detach” the alert from the template. To understand more about alert customization, see the next section.
Alert Dashboard View
The alerts display is always accessible from the top right corner when you are staying on a server in the server tree. Press the triangle icon to open the alert drawer.
Alert Drawer Display
 |
| Legend |
| 1 |
Opens the alert, full view to view the alerts in a table with more information. |
| 2 |
Toggle between seeing only the active alerts view and all alerts. |
| 3 |
Toggle between seeing only the active alerts view and all alerts. |
| 4 |
Sorting options: default is by date. You can also sort by severity. |
| 5 |
The alert details (title, date and description). |
|
Alert full view
| Legend |
| 1 |
Toggle between seeing all alerts and active alerts. |
| 2 |
Close alert view |
| 3 |
Severity total counter control |
| 4 |
| Global search inside the alerts by entity and text and
alert filters, allowing filter by alert category, status and read status.
|
|
| 5 |
Alert table
| Name |
The alert name (full alert list can be found in Appendix A) |
| Status |
The alert may be active, inactive or dismissed. If the alert is active, it means that it is ongoing, and the conditions for it to be raised are still enabled. The alert can be dismissed by the system if the alert configuration is marked as allowed to dismiss the alert when the conditions for the alert occurrence stop occurring.
means that it is ongoing, and the conditions for it to be raised are still enabled. The alert can be dismissed by the system if the alert configuration is marked as allowed to dismiss the alert when the conditions for the alert occurrence stop occurring. |
| Date created |
The date the alert was first raised. |
| Date closed |
The date of the time the alert was dismissed – in case the alert was dismissed. |
| Dismissed by |
The user that dismissed the alert (for auditing purposes). |
| Category |
The alert category. |
| Server |
The server that raised the alert. |
| Database |
In case of a database-level alert – the database name. |
| Description |
Additional information about the alert. |
|
Configuring alerts
How to get to the alerts configuration
From your selected company, select the “settings item” icon from the top left menu. Then, choose “Alerts” from the left menu.
Alert Configuration Views
Alert Configuration general view
| Legend |
| 1 |
A selection between the “Template View” (Default) and the Custom Servers View. |
| 2 |
Create a new template button. |
| 3 |
Change tabs between the SQL/Host view, which displays all the alert configurations, to the Affiliated servers/hosts view. |
| 4 |
Navigation to a specific category.
|
| 5 |
Total alert configuration counter + search for specific alert configurations |
| 6 |
Alert configuration row view
| Legend |
| 1 |
Alert name + sum of total included/excluded entities. |
| 2 |
Short description of the alert for all severity levels. |
| 3 |
Enable/Disable alert. |
| 4 |
Press to configure the alert |
|
| 7 |
Enable/Disable an alert configuration. Notice that if you choose to enable an alert configuration from the row, it will automatically receive the default options. To further configure, you need to use the 8 to see all options. |
| 8 |
Enable/Disable an alert configuration. Notice that if you choose to enable an alert configuration from the row, it will automatically receive the default options. To further configure, you need to use the 8 to see all options. |
Affiliated Server View
From the affiliated server view, we affiliate or detach a server from a template. This immediately associates all of the template’s alert configurations with the attached servers.
If the server had previously been attached to another template of the same type (Host/SQL), all linked alert configurations will automatically be removed. All unlinked/custom alert configurations will stay untouched as they are considered to be specifically altered to serve the purpose of the user.
Note: when we detach a server from a template all unlinked or customized alert configurations are not removed.
| Legend |
| 1 |
The affiliates server tab. Press “Affiliated Server” to get to the affiliated server view |
| 2 |
Action to open the “Add remove dialog.” Select the servers you wish to “detach” or “add” to the tem- plate from this dialog and press “Add servers.”
|
| 3 |
A quick list to see the existing attached servers. You can easily detach a server from a template by pressing the “X” next to its name. |
Alert Configuration view
 |
| Legend |
| 1 |
Alert Configuration Name.
Action “Reset to default” -> will reset the configuration values to the original recommended default values. For example, Critical value will change to 20%.
Action “Unlinked” -> Pressing the X will restore the alert with its
parent’s configuration.
Action “Enabled” – pressing  will enable or disable the alert. |
| 2 |
Rule Details
- For some alerts, there are no additional parameter configurations. Alerts like “Database has no backup,” for example, has to “escalation.” They are boolean alerts, and in that case, a single drodown list with the severity level will be displayed
In other, more complex alerts, three severity levels will be visible, each one completely customizable to allow maximum flexibility.
- At least one severity level needs to be selected.
- Once an alert has become active, it will stay active as long as it is still at a defined severity level. For example, if an alert on CPU that is defined on information level above 20% and critical above 50% goes under 20%, it will remain unread but inactive.
- Persist over option will determine if the alert is checked for persistance. For example, if by default in the rule shown on the left CPU goes over 30%, the alert will automatically be raised.
- However, if the value of 120 seconds is selected in the “presist over” selection, the rule will not be immediately raised but will wait until the CPU is over 30% for a consecutive time of 120 seconds. The sampling is done every 60 seconds by default.
- Automatically Dismissed – use this option to automatically dismiss alerts that have “fixed themselves” and are no longer important. In our example, if this option is selected and there is an active alert for the CPU, and the next CPU value is under 20% (minimum “information” severity level), the alert will automatically dismiss itself.
|
| 3 |
Notification/Messaging Options Panel
Use this panel to select the action that occurs after an alert is raised for the first time.
By default, you may see the alert from the alert dashboard. However, you may also receive an SMS alert and/or an email alert.
Use this panel to choose your email/SMS recipients and the severity level. You may choose a single contact or contact groups to allow maximum flexibility. |
|
How to create a new alert template
There are two ways to create a new template:
- Press the [+] Create Template button to open the new alert template Fill in the new template name and select its type (OS = machine-level alerts, SQL = SQL service-level alerts). Then press the “Create template” button.
- You can stay on an existing template and duplicate This is recommended if you wish to make minor changes to an existing template instead of creating a new one.
Alert Customization – Understanding “Linked” And “Unlinked” Alerts
The proper usage of the alert module is by creating alert templates and affiliating them with your servers at the Host and SQL levels.
However, there are times when we wish for an alert to either be defined differently or customized for a specific machine/server/database.
When we use the custom options, we “unlink” the alert from the template by choosing separate alert parameters or messaging configurations. This alert will now not be affected when we change its corresponding alert configuration in the template itself. The alert at the database level may be unlinked from the server level, and the alert from the server level may be unlinked from the template level.
Any change in the custom options of the alert will unlink it from its parent. For example, adding an email to the notification, changing its severity level or setting a specific alert parameter value.
For example. Server A is associated with Template A, which has the “CPU Above” alert set to alert when the CPU level rises above 50%. If we customize the alert in template A to a value of 60%, as long as server A is linked to the template, the alert value will change for Server A as well to 60%. However,
if we customize the alert value specifically for Server A to 70%, the alert will then be unlinked from the server, and any changes to it on the template level will not affect it but will affect all other associated servers to the template.
The alert will then be visible as “unlinked” at the custom server level. Example:
How to return an unlinked alert to be linked to its parent.
Any customized alert will automatically be marked as unlinked if the entity has a linked affiliated parent. To return the customized alert to the template, we can press the X on the unlinked mark from the view or from within the alert details themselves.
We can also “re-link” an alert from the main view by pressing the “X” next to the unlinked alert.
Alert Customization – understanding “includes” and “excludes”
The alert module uses a hierarchy of templates-> servers-> databases. As servers may be excluded/included from a template and databases may be excluded/included from a server – we will use the word “entities” to generally describe either a server or a database with its respective association with its parent.
We will sometimes wish to exclude certain alerts from being checked on certain entities. For example, if my main template, Template A, is affiliated with 20 different servers, and I want a specific server not to be included for a particular alert – I will exclude that server from that alert. The same logic works between a custom server and its affiliated databases.
Excluding certain servers from a template allows for any other new servers that are added to have the same logic as the template and will not affect the excluded servers. When adding a new database, for example, the server’s alerts will automatically be inherited by the new database, as the assumption is that all monitored databases should be monitored in the same way unless customized or excluded.
However, including has a different logic. When a user chooses to include a certain server, all other servers will automatically be excluded, even new servers that are added. The same logic works for databases. When the user chooses to include a specific entity, the assumption is that the alert is then “tailored” for that entity, and no other entities should be associated with it. That also means that any newly added entities will not be automatically affiliated with the template/server unless specifically added to the list of included entities.
Examples:
- My template “Default SQL” has the following alert defined: “Always On – Database Not ” However, two of my servers are not defined as “Always On,” I will want to exclude all “Always On” alerts for those two servers.
- My server has many databases that are not active, and I don’t back them up. In this case, I will exclude all inactive databases from the test “Database No Backup Exists.”
- My server has 50 databases, but only 3 of those databases are priority databases that I’d like to also check for index I will choose the “Database Fragmented Index” alert from my server (custom level) and include only those 3 databases.
How to exclude a server from an alert configuration (template level)
- Select your template and open the configuration for the selected
- Inside the alert dialog, select “Exclude,” and from the dropdown options, select “Exclude”
- Select the “Choose” dropdown menu to open a new dialog to select the servers from a Choose the servers you wish to exclude from the template and press “Add Servers.” From this dialog, you may remove or add the excluded server.
How to exclude a database from an alert configuration (custom server level)
- Select your server from the custom servers and open the configuration for the selected alert.
- Inside the alert dialog, select “Exclude,” and from the dropdown options, select “Exclude”
- Press the left textbox to display the list of available databases Choose the databases you wish to exclude from the template and press “Save.” From this dialog, you may remove or add the excluded databases later on.
How to include a database from an alert configuration (custom server level)
- Select your server from the custom servers and open the configuration for the selected alert.
- Inside the alert dialog, select “Exclude,” and from the dropdown options, select “Include.” Remember that the included database logic works differently from the excluded logic. See “Alert Customization – understanding includes and excludes” to understand more.
- Press the left textbox to display the list of available databases. Choose the databases you wish to include and press “Save.” From this dialog, you may remove or add the excluded databases later on.
Alert Customization – specific database type selection from template level
For alerts that are directly affiliated with a database, there is another automatic filtering option that is derived directly from their template. As you cannot exclude “databases” directly from a template, this feature allows you to associate a database to template alerts via their properties from the template level.
Remember that this rule will apply to all affiliated servers and their corresponding databases.
Examples:
- We wish to run the alert “No backup found” on all databases except for the system databases.
- We wish to have “Database No Backup Exists” for Log-type backups to all databases that have a full recovery
Note: Only database-appropriate alerts will have this feature enabled at the template level. Examples of database level alerts: “Database Old Restore”, “Database No Backup Exists”, “Database Object Lock”, “Database Status”
| Name |
Description |
| All DBs |
All databases (default) |
| System DB |
Only system databases: Master, Experda, Model, MSDB, TempDB |
| Full DB |
All databases that have a full recovery model. |
| Simple DB |
All databases that have a simple recovery model |
| All Without System |
All databases except for the system databases |
How to set the database type from the template level
- Goto your SQL type template and open your database level alert
- Press the “Excludes” tab, and from the first dropdown list, select the database grouping you wish to affiliate with the alert. After selection, press “Save.”
Finding your way around the alert configuration module
List Of Alerts (Appendix A)
Alert statistics
Alert Viewing/Indicators
