Everything is correct except the alerts

Sometimes you may think an SLC is not working because you are not seeing expected alerts in the Active Alerts Monitor.

Remember, alerts are nothing more than IBM® Sterling Control Center Monitor events with an additional element named Alert, along with an alert value (0, 1, 2, or 3). An alert element is added to an event by the rule service only if an enabled IBM Sterling Control Center Monitor rule matches the event and specifies an action with an alert severity of 0, 1, 2, or 3. The Active Alerts Monitor displays all unhandled events that contain an alert element with a value greater than 0.

If you are not seeing expected alerts in the Active Alerts monitor, check to see if your situation resembles one of the following scenarios:

  • Make sure that the rule that should be triggering the expected alerts has been properly defined by:
    • Specifying the appropriate SLC message ID
    • Associating an appropriate schedule and action with it
    • Enabling the rule
  • The Active Alerts Monitor has the ability to overlay existing alerts with new correlated alerts. All SLC events contain an SLC instance identifier unique to each active SLC. The Active Alerts Monitor uses the SLC instance identifier to know when alerts it receives are correlated, and instead of displaying multiple alerts for the same SLC instance, displays only the latest.

    For example, an SLC with a Normal Start Range (NSR) specified will generate an SLC notification with a message ID of CSLC047E if the NSRs time transpires without an appropriate starting event being seen, and another SLC notification with a message ID of CSLC034E if the NSRe time also transpires without an appropriate starting event being seen. In this case, the Active Alerts Monitor may first display the SLC event with the CSLC047E message, and then overlay that event with the SLC event containing the CSLC034E message, because their SLC_INSTANCE_ID values will be the same, which means they're correlated.

    In fact, if the latest correlated event is an alert of severity 0, instead of displaying the newest alert in the view, the existing correlated alert (if one exists) is removed from the Active Alerts Monitor. For example, an SLC with a duration schedule generates an SLC notification with a message ID of CSLC049E because the dMin time passes without seeing an appropriate ending Process type event, and another SLC notification with a message ID of CSLC042I because an appropriate ending Process type event is seen before the dMax time occurs. If the rule triggered when an SLC notification with message ID CSLC042I occurs specifies an action with an alert severity of 0, then the alert with the message ID of CSLC049E is removed from the Active Alerts Monitor when the CSLC042I event occurs, instead of being replaced.

  • The engine may not be collecting and processing events from monitored servers in a timely fashion. As a result, IBM Sterling Control Center Monitor may issue contradictory messages. If you see out-of-compliance events for a process or process step, followed by an in-compliance event, this is typically caused by a lag between the time statistics that are generated by monitored servers and the time statistics are collected and processed by IBM Sterling Control Center Monitor.

    For example, if an SLC-type event with a CSLC027E message (Process did not start by NERe) is followed by an SLC-type event with a CSLC037I message (Process ended within NERe) for the same SLC instance, it is almost certainly caused by the engine not receiving and processing the Process end or Process step end statistic prior to the NERe even though the Process ended within the NERe.

  • The concurrence count for the SLC may not be set properly. For example, you may see more alerts than expected if the concurrence count is set too high for SLCs with calendar schedules, or you may see fewer alerts than expected if the concurrence count is set too low for SLCs with duration schedules.
  • Make sure the alerts are associated with the server, servers, or server group for which you opened the Active Alerts monitor. Some SLC events, in particular the ones for events that did not occur, may not be associated with any servers and, in that case, the only way to see them is by opening an Active Alerts monitor for all of IBM Sterling Control Center Monitor.