The user-defined alerts are created as part of the monitor definition. The Sentinel server always sends alert events in real-time to the appropriate connected Sentinel clients and stores these events in the AlertLog table in the repository database so that clients could review generated alerts in the Alert Viewer next time they connect to the server. In addition to it, the server can issue alert event notifications via email, mobile phone or pager text messages if the user chooses them as part of the alert notification condition. All messages are delivered via SMTP protocol, using SMTP server definition provided by the user as part of the monitor definition. This SMTP server should be accessible from the host on which Sentinel server is running. The difference between email, pager and mobile-phone messages is in the amount of text characters in the message (unlimited for an email message and up to 256 characters for a mobile-phone text message).
Each user-defined alert has its own severity, a list of notification methods and optional action or a job that should be automatically executed when this alert event is triggered. The notification methods include visual notifications, and email, pager or mobile phone messages. Visual notifications always place an exclamation mark indicator on the corresponding monitor node in the Server Studio JE. You can also specify to shortcut a dialog box in the UI when a particular alert event occurs and optionally specify for each alert individually a list of email addresses, mobile phones and/or pagers where to send the alert notification. A custom text message can be defined for each alert event that can contain short reminders or instruction on what should be done when a particular event occurs.
Multiple alerts can be created for the same parameter to differentiate between different severity levels. For example, you can create a visual warning alert when dbspace is 80% full and critical alert with an email notification when a dbspace is 95% full. When an alert event is generated, it always includes the information about the alert's severity level, database instance where the alert event occurred, parameter value that exceeded the defined threshold, the actual threshold level and additional information about objects related to the alert event, such as list of tables, space names, user session ids, chunks ids, etc.
You create alert definitions at the time when you create a new monitor or by editing an existing monitor definition. The alert definitions are constrained by a monitor's selected list of parameters and objects' set.
The alert mechanism allows you to issue notifications when the value of a monitored parameter exceeds user-defined threshold level. You can define conditions to alert you about practically any operational condition of your IDS server that requires attention (i.e., dbspace is almost full or a large number of deadlocks, etc.). Each alert condition has:
You can define multiple alert conditions for each monitor parameter with different actions to take when different threshold levels are exceeded. For example, you can configure to send visual alert with the severity level Warning when dbspace is 80% filled and send email and pager notification with a severity level Critical and automatically execute script that adds a chunk when dbspace is 99% filled.
To create an alert:
1. Press Add button to add the new record in the Alerts list.
2. Choose the monitor parameter, for which you want to define an alert condition, from the dropdown list in the grid.
3. Choose an operation, such as > or <, and enter the threshold value.
4. Choose the severity level from the dropdown in the grid.
5. In the Alert Action panel located at the right of the Alerts grid, check the Shortcut checkbox if you want to see the shortcut dialog box in the Server Studio JE GUI when this alert event occurs. Otherwise the alert event will be displayed in the Alert Viewer panel and also indicated by the exclamation mark on this monitor node icon under Monitors folder in the SSJE Object Explorer.
6. Choose the value for the Notification Delay parameter. This parameter determines the period of time before server notifies about the same event that happens with the same object. For example, if BUFFREADS parameter for a particular table exceeds an alert threshold the first notification event will be issued. After that if the value for this parameter is still high during the next checking cycle that is defined at 20 minutes refresh interval and you set the Notification Delay parameter to 1 hour, the alert event will not be issued. You will be notified about the high BUFFREADS event for this table only if stays high after one hour. If you choose <NO DELAY> option, you will be notified every time the value for this parameter for this table exceeds the threshold level so that if the table has a long period of high activity, you will receive 3 notifications during one hour for above example with 20 minutes refresh rate interval.
7. Choose the value for the Notify After Event Occurs (n) Time(s). If this parameter is set to 1 (default), you will be notified every time the monitored value exceeds the specified threshold. Set this parameter to a higher number, if you want to be notified only when the same alert event happens several time sequentially. For example, if this value is set to 2 for TABLE-BUFFREADS parameters and the threshold condition is "TABLE-BUFFREADS > 5000000" at 10 minutes refresh interval, you will be notified only when the value of the TABLE-BUFFREADS for some table stays greater than 5000000 during two sequential refresh intervals (20 minutes). It allows you avoid being notified when random high peak events occur and to bring attention only to situations when the high activity condition persists over time.
8. Choose the email, pager or mobile-phone notification method for this alert if required. You can specify multiple emails, phones and pagers to send a message to in case of this event.
9. Enter the user-message which will be part of this alert event. This message, for example, might contain instructions on what to do in case of this event occurs.
10. Optionally choose a job, which should be executed on the target IDS host when this event occurs. The job can be a user-defined script, OS command, SQL script or stored procedure call. The job should be created and tested using the Jobs folder before you can use it in the alert definition panel. See Jobs help topic for additional information on job creation, testing and execution.
For "OS Command" jobs, you can provide an optional argument string that will be appended to the job's command line when alert is triggered. This mechanism provides you with the ability to provide alert-specific parameters for your script. For example, if you have an external logging utility that takes the text of the message as a command line argument, you can enter the following text in the Job Arguments field:
'read cache < 80%'
The argument text is appended to the command line "as is" - therefore, you should provide all proper quote characters to separate text arguments containing spaces.
If you define an alert condition for a table/index, chunk, dbspace or session-level parameter, you will be able to specify in the Filters page of the Monitor Wizard the list of objects to which the alert applies.