Passing Metric Severity/Policy Information

Passing metric severity attributes (severity level, type, notification rule, or rule owner, etc.)  to PL/SQL procedures or OS commands/scripts allows you to customize automated responses to alerts. For example, if an OS script opens a trouble ticket for an in-house support trouble ticket system, you will want to pass severity levels (critical, warning, etc.) to the script to open a trouble ticket and escalate the problem. Information on policy violations such as violation level,  notification rule, or rule owner can also be passed to PL/SQL procedures using the same mechanism as for metric severities.

Passing Information to a PLSQL Procedure

The notification system passes severity information to a PL/SQL procedure via the MGMT_NOTIFY_SEVERITY object. An instance of this object is created for every alert. When an alert occurs, the notification system calls the PL/SQL procedure associated with the notification rule and passes the populated object to the procedure. The procedure is then able to access the fields of the MGMT_NOTIFY_SEVERITY object that has been passed to it.

The following table lists all metric severity attributes that can be passed:

When a severity occurs for the target, the notification system creates an instance of the MGMT_NOTIFY_SEVERITY object and populates it with values from the severity. The following severity codes have been defined as constants in the MGMT_GLOBAL package and can be used to determine the type of severity in the severity_code field of the MGMT_NOTIFY_SEVERITY object.

Severity Codes

Example: PL/SQL Procedure Using a Severity Code

CREATE TABLE alert_log (target_name VARCHAR2(64),
alert_msg VARCHAR2(4000),
occured DATE);

PL/SQL Procedure

CREATE OR REPLACE PROCEDURE LOG_CRITICAL_ALERTS(severity IN MGMT_NOTIFY_SEVERITY)
IS
BEGIN
-- Log all critical severities
IF severity.severity_code = MGMT_GLOBAL.G_SEVERITY_CRITICAL
THEN
BEGIN
INSERT INTO alert_log (target_name, alert_msg, occured)
VALUES (severity.target_name, severity.message,
severity.collection_timestamp);
EXCEPTION
WHEN OTHERS
THEN
-- If there are any problems then get the notification retried
RAISE_APPLICATION_ERROR(-20000, 'Please retry');
END;
COMMIT;
END IF;
END LOG_CRITICAL_ALERTS;

Using a PL/SQL Procedure:

1. Create the PL/SQL procedure on the repository database using the following procedure specification:

   PROCEDURE p(severity IN MGMT_NOTIFY_SEVERITY)

   If an error is encountered during the running of the procedure, the Notification System can be instructed to retry the sending of the notification to the procedure by raising a user defined exception that uses the error code -20000. See the example above. The procedure initially retried after one minute, then two minutes, then three minutes and so on, until the notification is a day old, at which point it will be purged.

2. Add this PLSQL procedure as a notification method that can be called in Notification Rules. See Adding a PLSQL Procedure.

   Make sure to use a fully qualified name that includes the schema owner, package name and procedure name. The procedure will be executed by the repository owner and so the repository owner must have EXECUTE permission on the procedure.

3. Associate the PL/SQL procedure with a notification rule.

Passing Information to an OS Script or Executable

The notification system passes severity information to an OS script or executable via system environment variables. Conventions used to access environmental variables vary depending on the operating system:

• UNIX: $ENV_VARIABLE

• MS Windows: %ENV_VARIABLE%

The notification system sets the following environment variables before calling the script.

Your script may reference some or all of these variables.

Using an OS Script or Executable

• Create an OS command on the repository host machine.

  Create an OS Command on each Management Service machine that connects to the Management Repository. The OS Command should be an absolute pathname and must be the same on each Management Service host machine e.g. /u1/bin/logSeverity.sh. The command is run by the user who started the Management Service. If an error is encountered during the running of the OS Command, the Notification System can be instructed to retry the sending of the notification to the OS Command by returning an exit code of 100. The procedure is initially retried after one minute, then two minutes, then three minutes and so on, until the notification is a day old, at which point it will be purged.

  The following parameter in emoms.properties controls how long the OS Command can execute without being killed by the Management Service. This is to prevent OS Commands from running for an inordinate length of time and blocking the delivery of other notifications. By default the command is allowed to run for 30 seconds before it is killed. See (add a pointer to the other doc that discusses all these parameters)

  # The amount of time in seconds after which an OS Command started by the

  # Notification System will be killed if it has not exited

  # em.notification.os_cmd_timeout=30

• Add this OS command as a notification method that can be called in Notification Rules. See Adding an OS Command.

• Define a notification rule (choose the targets and conditions for which you want to be notified), and associate the OS command with the rule. See Defining Notification Rules.

Related Topics

Enterprise Manager Information Roadmap

Copyright © 1996, 2007, Oracle. All rights reserved.