CI Status Alerts

Administration > Service Health > CI Status Alerts

Alternatively, click CI Status Alerts.

You can configure a Simple Network Management Protocol (SNMP) trap and attach it to an alert. The SNMP trap includes Object Identifiers (OIDs) and their values based on the alert's data.

The SNMP trap is sent when the alert criteria is met and the alert is triggered.

The MIB file, located at <OMi_HOME directory on the Data_processing Server>\SNMP_MIBS\CIAlerts.mib, contains the mapping of Object Identifiers (OIDs) to alert-related data.

The alert type is CI Status Alert, and the SNMP-specific code for a CI Status alert is 1.

To configure SNMP traps, see How to configure a notification SNMP trap. The SNMP trap is sent when the alert criteria is met and the alert is triggered. You can view the alert notice with any SNMP management console in your organization.

When you configure a CI status alert scheme, downtime can affect the CIs and skew the CI's data. You can configure downtime so that a CI status alert is triggered or not when the CI attached to the alert is in downtime.

For details on how to edit or create a downtime, see Downtime Management.

The event template maps an event triggering condition (for example, the triggering condition of a CI status alert scheme) to an event attribute. The attributes are specific to the application (for example, the CI status alert attributes).

CI status alerts have a default event template. You can create a template by modifying the default event template. For details, see How to configure a CI status alert event template.

When the event trigger condition is met (meaning that the CI status alert is triggered), and if you have configured the CI status alert to send an event, the event attributes are populated by the relevant triggered CI status alert conditions, and create an event corresponding to the alert. The event is then sent to OMi.

The following table lists the attributes you can use for CI status alerts:

You can create new CI status alerts and attach them to any CI. You can attach more than one CI status alert to a CI. You can also attach the same CI status alert to more than one CI.

An alert attached to a CI in a specific view is also attached to the CI in any view where the CI is included.

1. Select a view.

   Note The drop-down list with the views may not display all views in the RTSM because it includes:

   • Only the views for which you have the necessary permissions. To set permissions, open the Users, Groups, and Roles page:

     Administration > Users > Users, Groups, and Roles

     Alternatively, click Users, Groups, and Roles.

     Select a user or a group and select Permissions.

   • Only the views that are assigned to the application.

   • Inactive views that cannot be selected.

2. In the CI Status Alerts pane, click New to create a new CI status alert, or select the CI status alert and click Edit. The Create CI Status Alerts or Edit CI Status Alerts panel opens.

   Note You can also select the CI status alert and click  Duplicate to create a new CI status alert by using the selected one as a template. Rename and edit the CI status alert as required.

3. In the General section, enter the name of the CI status alert and, optionally, its description.

4. In the Conditions section, provide the following information:

   1. Add CIs. You can do this by clicking and selecting the CIs from the drop-down list, or by clicking and selecting the check boxes next to the CIs in the Choose CIs side panel.
   2. Select KPIs. You can select all KPIs if you want the alert to be triggered by the specified status change in any of the KPIs attached to any of the selected CIs, or the specific ones if you want the alert to be triggered by the specified status change in the selected KPIs attached to any of the selected CIs. Click the Open the KPI Selector link, and in the KPI Selector side panel that opens, select the KPIs to be forwarded.

   3. Select one of the following options for sending an alert:

      • Status is equal to or better than/is equal to or worse than<status> for <value> <time unit> to trigger the alert when the status of the CI is equal to or better/worse than the selected status (Critical, Major, Minor, Warning, or OK) for the specified time period (minutes, hours, or days).

      • Status worsens to trigger the alert when the current status of the KPIs is worse than the previous status. For example, the alert is triggered when the status changes from Warning to Minor.

      • Status improves to trigger the alert when the current status of the KPIs is better than the previous status. For example, the alert is triggered when the status changes from Warning to OK.

      • Status changed from <status> to <status> to set the appropriate conditions for sending an alert. Select the appropriate status from the drop-down lists. The available statuses are: Any Status (only available in the first drop-down list), Critical, Major, Minor, Warning, OK, No Data, Downtime, Stop, Info, and Uninitialized. If you select Any Status, the alert is triggered when the CI status changes from any status to the target status.

      Examples of Status is equal to or worse than <status> for <value> <time unit>:

      • You specify the following condition: Send alert if status is equal to or worse than Major for 15 minutes. The following scenarios occur:

      CI's KPI	Status changes to	What happens
      Availability	Major for 15 minutes	The alert is sent.
      Availability	Critical for 20 minutes	The alert is not sent (status is still worse than Major for over 15 minutes). Note Before the alert is triggered again, the alert must be reset. To reset the alert, the status must return to a value within the status threshold (better than Major). After the alert is reset, it can be triggered as before (when the status changes to worse or equal to Major for 15 minutes).
      Performance	Critical for 20 minutes	The alert is sent (another KPI status becomes worse than Major for over 15 minutes).
      Availability	Minor	The alert is not sent (status is better than Major and counter is reset).
      Availability	Critical for 20 minutes	Another alert is sent after 15 minutes.

      • You specify the following condition: Send alert if status is equal to or better than Minor for 30 minutes and Limit alerts to one alert every 60 minutes. The following scenarios occur:

      CI's KPI	Status changes to	What happens
      Availability	OK for 45 minutes	The alert is sent.
      Performance	OK for 30 minutes	The alert is not sent (it was already sent 15 minutes ago).
      Availability	Minor for 15 minutes	The alert is not sent (it was already sent for the Availability KPI 15 minutes ago).
      Availability	OK for 20 minutes	The alert is not sent.
      Availability	No Data for 15 minutes	The status of the alert is reset.
      Availability	OK for 10 minutes	The status of the alert is not sent as the time interval condition is not met (30 minutes).

   4. Select the Limit alerts to one alert every check box, and specify the time unit and period to send an alert notification. If you want to send an alert notification every time an alert is triggered, leave this check box clear.

5. In the Actions section, click Add Action to define the user-defined alert actions that are triggered by the alert, and select one of the following:

   • Create event

     Select an event template that is used to generate an event when an alert is triggered.

   • Notify recipients

     Define the CI status alert recipients and templates:

     Click to add recipients, and then click , and in the Notification Templates side panel, provide the following information:

     1. Email. Select one of the following:

        • Long text email template.
        • Long HTML email template.
        • Short HTML email template.
        • Short text email template.

     2. SMS. Select one of the following:

        • Long SMS template.
        • Short SMS template.

     3. Pager. Select one of the following:

        • Long pager template.
        • Short pager template.

   • Run command

     Important Only users with administrative privileges can run a command. The command is run when the attached alert is triggered. The command writes information in special logs or inserts information into external databases.

     To set the appropriate administrative privileges to a role:

     1. Open the Users, Groups, and Roles page:

        Administration > Users > Users, Groups, and Roles

        Alternatively, click Users, Groups, and Roles.

     2. Select Manage Roles.

     3. Select the appropriate role in the left column, and click Edit Role.

     4. In the Permissions tab, open Service Health > Alerts > Executable File.

     5. Select the Change option.

     6. Click Save Role.

     Example: Run a command:

     To include the name of the CI in the command, in the Action field, perform the following steps:

     1. Enter the following string: \\servername\myfolder\run.exe -name.

     2. Select CI Name.

        The string is now: \\servername\myfolder\run.exe -name ${CI Name}.

   • Send request to URL

     The notification URL is sent when the alert criteria is met and the alert is triggered.

     Important Consider the following:

     • The notification URL is used to pass alert information to external systems, such as a customer Web application.

     • You can embed predefined alert parameters in the notification URL. The parameters are used as placeholders when the message is formatted and are replaced by real values when the alert is triggered.

     • You can modify the default URL that appears in the notifications. This URL represents the URL of the Data Processing Server.

     Example: Create a notification URL

     To include the name of the CI and the current status of the CI in the URL, in the Action field, perform the following steps:

     1. Enter the following string: http://dogbert.com/myjsp.

     2. At the end of the string, enter: entityname=.

     3. From the drop-down list, select the CI Name.

        The string is now: http://dogbert.com/myjsp entityname=${CI Name}.

     4. At the end of the string, enter: severity=.

     5. Select Current Status Name.

        The string is now: http://dogbert.com/myjsp entityname=${CI Name} severity=${Current Status Name}.

   • Send SNMP trap

     Configure a SNMP trap that is sent when the alert criteria is met. The alert notice can be viewed with any SNMP management console in the organization. Choose one of the following:

     • Destination host IP in infrastructure settings. Use the globally defined SNMP target address. This setting is defined in the Infrastructure Settings.

       Administration > Setup and Maintenance > Infrastructure Settings

       Alternatively, click Infrastructure Settings.

       Select Foundations > Alerting > Alerting - Triggered Alerts > Default SNMP target address.

     • Custom destination host IP. Use a different SNMP target address for this trap. Specify the IP in this field.

     Important OMi uses the CI alerts MIB by default and supports SNMP V1.

     To enable alerts through SNMP trap, it is recommended that you configure your SNMP management console to read the alerts MIB. This enables you to see names, rather than Object IDs (OIDs), when working in the management console.

     The MIB file is located in <OMi_HOME directory on Data Processing Server>\SNMP_MIBS\CIAlerts.mib.

     For more information, see How to configure a notification SNMP trap.

   Click Apply.

6. Click Create.

This task describes how to configure an event template so that events are created when CI status alerts are triggered.

1. Click Manage event templates. In the Manage Event Templates side panel, you can manage a user notification or an event based on a defined alert triggering condition. When the alert is triggered, the event template is used to map the alert information to the event information.

   Note If you want to set the selected template as the default template, click Make template default.

2. Click New to create a new template, or select an event template and click Edit to modify it. The Create Event Template or Edit Event Template side panel opens.

   Note You can also select an existing event template and click  Duplicate to create a new event template by using the selected one as a template. Rename and edit the event template as required.

3. Enter the name of the active template.

4. In the Event Properties section, complete the following information:

   1. Enter the title that describes the occurrence represented by the event. The title should include information about what threshold has been crossed (or other trigger conditions), and the current values. Add the attributes using the following format for CI status alerts:

      $(Alert Name)
Triggered on CI: $(Entity Name)
Trigger condition

      Note Because the text is typically shown within a single line in the event browser, it is recommended that the most relevant information is at the beginning of the text.

   2. Enter the detailed information describing the event. Add the attributes using the following format:

      Alert Name:$(Alert Name)
CI Name: $(Entity Name)
$(Alert User Description)

   3. Enter the severity of the event. It represents the translation of the alert CI status into the event severity. The severity levels can be: Unknown, Normal, Warning, Minor, Major, and Critical. This information enables you to map the triggering event status to the event severity level. Add the attributes using the following format:

      $(Event Severity)

   4. Enter the category to organize or group events. Out-of-the-box categories are provided.

      Note Depending on your permissions, you can define your own categories. Permissions are configured in the Users, Groups, and Roles page:

      Administration > Users > Users, Groups, and Roles

      Alternatively, click Users, Groups, and Roles.

   5. Enter the subcategory for more detailed organization of events that have the same category. Use it for event standards and external event sources that are using subcategories. Add the attributes using the following format:

      $(CI Type)

   6. Enter the event type indicator that links between the event and the HI or KPI so that information about the HI or KPI can be updated as a result of submitting the event. The default is CIAlert:$(Current Status Key). Add the attributes using the following format:

      $(ETI/HI Name)[:$(ETI/HI State)[:ETI Numeric Value]]]

      Example:

      • Health indicator with state High and numeric value for a Database CI: ConnectionPoolUtilization:High:0.88

      • Health indicator with state for a Node CI: MemoryBottleneck:Active

   7. Select the Send as closed event check box if you want to send the event to the history event browser as a closed event. Such an event goes through the complete event processing, but has its Life Cycle State set to closed. Typical examples are events that result in resetting an HI to a normal or good state, or an event signaling that a previous problem no longer exists (where the problem was reported in another event).

5. In the Resolution Hints section, provide the following information:

   1. Enter the CI hint information (information about the CI that is related to the event). This attribute is used for providing hints to enable the event processing to find the correct related CI (RTSM ID of the related CI). Add the attributes using the following format:

      UCMDB: $(CI ID):*

      Example:

      • UCMDB as hint "UCMDB:3bcbb67a6233cfdd0e400e7c1e637db5"

      • A set of natural identifiers: "oracle:database:987"

   2. In the Host hint field, enter the information about the CI of type Node that is hosting the CI related to the event. The host can be identified by RTSM Id, DNS name, IPv4 Address, IPv6 Address, MAC Address, L-Core Core ID.

      Example:

      IPV4:15.15.12.13, DNS:h1.mercury.il; CoreId: 0c9da6d8-3e08-45cd-9b12-b49a1ca5de20

   3. In the Generating source hint field, enter the information about the monitoring application and the corresponding probe or agent that is responsible for creating the event. Add the attributes using the following format:

      $(BSM DNS)

      Example:

      BSM:BSMserver1.example.com, OM:omserver32.example.example.com:agentId0c9da6d8-3e08-45cd-9b12-b49a1ca4de20

6. In the Correlation section, complete the following information:

   1. Enter a key (a unique string representing the type of event that occurred). Two events have the same key if the two events represent the same situation in the managed environment. Events with the same key are treated as duplicates. Add the attributes using the following format:

      $(Alert Name):$(Entity):$(Event Severity)

      Example:

      host1:example.com:DB_ess1:ConnectionPoolUtilitzation:High

   2. In the Close events with pattern field, enter the information to enable the event that is sent to close all the events whose Key attribute matches the Close Key Pattern expression. You can use the asterisk (*) wildcard in your string. Add the attributes using the following format:

      $(Alert Name): $(Entity ID):*

      Example:

      host1.example.com:DB_ess1:ConnectionPoolUtilization:* closes all the events whose key starts with host1.example.com:DB_ess1:ConnectionPoolUtilization.

7. In the Custom Attributes section, click New Item to add a custom attribute. Enter or select a custom attribute that you want to add, and click Apply.

   A custom attribute consists of a name and a value (both are strings). The value can be any string and is used by the event template mapping as any other value. For a list of the attributes that you can use for CI status alerts, see CI status alert attributes.

   Important Consider the following limitations:

   • Make sure that the name of the custom attribute you are defining is unique and does not already exist in the list of factory attributes.

   • If you add to a template a custom attribute with a name similar to a constant attribute's name, the custom attribute is ignored. The constant attribute's keys are:

     • Category

     • RelatedCiHint

     • CloseKeyPattern

     • TimeCreated

     • Description

     • EtiHint

     • NodeHint

     • Key

     • LogOnly

     • OriginalData

     • Severity

     • SubmitCloseKey

     • SourceCiHint

     • SubCategory

     • Title

   • Duplicate names are not allowed. You cannot create a name that already exists or you cannot use an existing name more than once in the same template.

   • Event template attributes are changed into the value of the relevant attribute of the triggered alert. When the attribute does not correspond to existing alert attributes (when it is a custom attribute), the value specified in the In the Custom Attributes section for the relevant attribute is used.

8. Click Save.

1. Set up the appropriate administrative privileges

   You can set the appropriate administrative privileges to create a command that can be attached to a CI status alert and run when the alert it is attached to is triggered.

   To set the appropriate administrative privileges:

   1. Open the Users, Groups, and Roles page:

      Administration > Users > Users, Groups, and Roles

      Alternatively, click Users, Groups, and Roles.

   2. Select Manage Roles.

   3. Select the appropriate role in the left column, and click Edit Role.

   4. In the Permissions tab, open Service Health > CI Status Alerts > Send SNMP trap.

   5. Select the Change option.

   6. Click Save Role.

2. Specify the host address of the SNMP trap

   You specify the default host address of the SNMP trap in the For details, see Send SNMP trap.

3. Check the mapping of the OIDs to the alert data and configure the alerts MIB – optional

   If you enabled alerts through SNMP traps in your CI status alerts, it is recommended that you configure your SNMP management console to read the alerts MIB. This configuration enables you to see a name, rather than an Object ID (OID), when working in the management console.

   Note OMi uses the AM alerts MIB 5.0 by default.

   To configure the alerts MIB in your SNMP management console:

   1. Copy the <OMi_HOME directory on the Data Processing Server>\SNMP_MIBS\CIAlerts.mib file from the HPE Operations Manager i Documentation and Utilities DVD to your SNMP management console.

   2. View the alerts varbinds by using your SNMP management console's MIB browser.

      The following tables lists the varbinds used in the alerts MIB:

      Object Identifier	MIB Label	Description
      1.3.6.1.4.1.5233	HP	Company name.
      1.3.6.1.4.1.5233.6	ciAlerts	Subject.
      1.3.6.1.4.1.5233.6.1	alerted	Unique alert ID.
      1.3.6.1.4.1.5233.6.2	alertName	Alert name.
      1.3.6.1.4.1.5233.6.3	alertDescription	Alert description.
      1.3.6.1.4.1.5233.6.4	alertEventTime	Time when the event occurred. This is the event that triggered the alert.
      1.3.6.1.4.1.5233.6.5	alertCIId	ID of the CI whose status change triggered the alert.
      1.3.6.1.4.1.5233.6.6	alertCIName	Name of the CI whose status change triggered the alert.
      1.3.6.1.4.1.5233.6.7	alertKPIId	ID of the KPI whose status change triggered the alert. The KPI is attached to the CI related to the alert.
      1.3.6.1.4.1.5233.6.8	alertKPIName	Name of the KPI whose status change triggered the alert. The KPI is attached to the CI related to the alert.
      1.3.6.1.4.1.5233.6.9	detailedDescription	Detailed description of the alert.
      1.3.6.1.4.1.5233.6.10	alertPrevious Severity	Previous severity of the CI.
      1.3.6.1.4.1.5233.6.11	alertNextSeverity	Current severity of the CI (the change from previous severity to current severity is what triggered the alert).
      1.3.6.1.4.1.5233.6.12	alertBACURL	URL of the OMi Gateway server.
      1.3.6.1.4.1.5233.6.13	actualTime	When the triggering condition is related to time, this is the actual time when the CI has breached the condition. For other condition types, this value is N/A.
      1.3.6.1.4.1.5233.6.14	conditionConfiguration	Description of the condition that triggered the alert.

   3. Using your SNMP management console's event configuration utility, configure the notification content and method for the various alert types. The SNMP-specific code for a CI status alert is 1, and its type is CI Status Alert.

Each change you make to a CI status alert is logged into the CI Status Alert Administration log.

To access that information, open the Audit Log page:

Administration > Setup and Maintenance > Audit Log

Alternatively, click Audit Log.

Select CI Status Alert Administration in the Context list. For details, see Audit Log.

The audit log provides information about the date the alert definition was modified, the user who made the modification, and the type of action.