alerts.status table

Controls ObjectServer deduplication. The Identifier field controls the deduplication feature of the ObjectServer, and also supports compatibility with the GenericClear automation by ensuring resolution events are properly inserted into the ObjectServer and not deduplicated with their respective problem events.

The following identifier correctly identifies repeated events in a typical environment:

@Identifier=@Node+" "+@AlertKey+" 
"+@AlertGroup+" "+@Type+" "+@Agent+" 
"+@Manager

Additional information might need to be appended to the Identifier field to ensure correct deduplication and compatibility with the GenericClear automation. For example, if an SNMP specific trap contains a status enumeration value in one of its variable bindings, the specific trap number and the value of the relevant varbind must be appended to the Identifier field as follows:

@Identifier=@Node +“ “+ @AlertKey+“ 
“+@AlertGroup+“ “+@Type+“ “+@Agent+“ 
“+@Manager+“ “+$specific-trap+“ 
“+$2

For IP network devices or hosts, the Node column contains the resolved name of the device or host. In cases where the name cannot be resolved, the Node column must contain the IP address of the device or host.

For non-IP network devices or hosts, alarms must contain similar information to the IP device or host. That is, the Node column must contain the name of the device or host which allows direct communication, or can be resolved to allow direct communication, with the device or host.

For non-IP devices or hosts, there are several addressing schemes that could be used. When selecting a value for the NodeAlias field, the value should allow for direct communication with the device or host. For example, a device managed by TL-1. The NodeAlias field may be populated by a lookup table or Netcool/Impact policy, with the IP address and port number of the terminal server through which the TL-1 device can be reached.

The descriptive name of the probe that collected and forwarded the alarm to the ObjectServer. This can also be used to indicate the host on which the probe is running. Ideally this is set in the properties file of the probe, however the rules file should check to ensure it is set correctly, and modify if necessary.

For example, the following syntax can be used to define the Manager field:

@Manager="MTTrapd Probe on" + hostname()

The descriptive name of the sub-manager that generated the alert.

Probes which process SNMP traps must set the Agent field to either the name of the vendor or the standards body which defined the trap, and provide a description of the MIB, or MIB Definition Name, where the trap is defined. It must be presented in the following format: vendor-MIB description

Cisco-Accounting Control, Cisco-Health Monitor,
IETFBRIDGEMIB, ATMF-ATM-FORUM-MIB

Optionally, vendor-specific information, such as device model numbers, can be appended to the Agent field for vendor-specifc implementations of standard traps.

The Syslog probe should set the Agent field to the name of the vendor which defined the received message, and provide any logical description for the family of messages to which the received message belongs.

For example, Cisco defines messages received from IOS-based devices in separate documentation from messages received from the PIX Firewall. The format of the messages is also slightly different. Therefore the Syslog messages received from Cisco will have the Agent field set to either Cisco-IOS or Cisco- PIX Firewall.

The TL-1 TSM should set the Agent field to the name of the vendor which defined the received message, and provide any logical description for the family of messages to which the received message belongs.

The descriptive name of the failure type indicated by the alert. For example:

Interface Status or CPU Utilization).

The AlertGroup field must contain the same value for related problem and resolution events.

For example, SNMP trap 2 (linkDown) and trap 3 (linkUp) must both contain the same AlertGroup value of Link Status.

The AlertGroup field for a TL-1 message will be set to the value of the message's alarm type.

The descriptive key that indicates the managed object instance referenced by the alert. For example, the disk partition indicated by a file system full alert or the switch port indicated by a utilization alert.

The Syslog Probe should set the AlertKey to a textual description of the instance derived from the log message text. Ideally this is a textual name of the same managed entity. For example:

Nov 20 13:12:57 device.customer.net 
195.180.208.193 19986: 37w0d: %LINK-3-UPDOWN: 
Interface FastEthernet0/13, changed state to down

In this example, the AlertKey would be set to FastEthernet0/13 using the following syntax:

@AlertKey = extract($Details, “Interface 
(.*), changed”)

0: Clear. The Clear severity level indicates that one or more previously reported alarms has been cleared. The alarms have either been cleared manually by a network operator, or automatically by a process which has determined the fault condition no longer exists. Automatic processes, for example the GenericClear Automation process, typically clear all alarms for a managed object (the AlertKey) that have the same Alarm Type and/or probable cause (the Alert Group).

1: Indeterminate. The Indeterminate severity level indicates that the severity level cannot be determined. Additionally, all problem resolving alarms are initially defined as indeterminate until they have been correlated with problem indicating alarms (for example by the GenericClear Automation), when all correlated alarms are set to Clear.

2: Warning. The Warning severity level indicates the detection of potential or impending service affecting faults. If necessary, a further investigation of the fault should be made to prevent it from becoming more serious.

3: Minor. The Minor severity level indicates the existence of a non-service affecting fault condition. Corrective action should be taken to prevent it from becoming a more serious fault. This severity level may be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object.

4: Major. The Major severity level indicates that a service affecting condition has developed and corrective action is urgently required. This severity level may be reported, for example, when there is a severe degradation in the capability of the managed object, and its full capability must be restored.

5: Critical. The Critical severity level indicates that a service affecting condition has occurred, and corrective action is immediately required. This severity level may be reported, for example, when a managed object is out of service, and its capability must be restored.

Contains text which describes the alarm condition and the affected managed object instance.

The time when this alert was last inserted or re-inserted into the ObjectServer. It is not updated during the processing of an update statement.

The type of alarm, where type refers to the problem or resolution state of the Alarm. This field is important for the correct correlation of events by the GenericClear Automation. The following values are valid for the Type field:

0: Type not set

1: Problem

2: Resolution

3: Netcool/Visionary problem

4: Netcool/Visionary resolution

7: Netcool/ISMs new alarm

8: Netcool/ISMs old alarm

11: More Severe

12: Less Severe

13: Information

Some scenarios cannot be categorized as either a Problem or Resolution. For example, events which are increasingly becoming an issue but do not currently represent a failure, and events which are becoming less of an issue but do not currently indicate the failure has been completely resolved. In which case, the Type field must be set to Problem, More Severe or Less Severe to maintain compatibility with the GenericClear Automation.

For example, the following rule file logic is used for handling traps associated with BGP Peer Connection Status:

switch ($bgpPeerState)
{
case "1": ### idle
@Severity = 4
@Type = 1
case "2": ### connect
@Severity = 2
@Type = 12
case "3": ### active
@Severity = 2
@Type = 12
case "4": ### opensent
@Severity = 2

@Type = 12
case "5": ### openconfirm
@Severity = 2
@Type = 12
case "6": ### established
@Severity = 1
@Type = 2
default:
@Severity = 2
@Type = 1
}

Used internally by many triggers and extensions, such as mail_on_critical trigger, self-monitoring triggers, the Device Counter extension, and the Scope-Based Event Grouping extension. Indicates whether an alert has been processed.

The default is 0, which is the identifier for the public group.

0: No

1: Yes

Alerts can be acknowledged manually by a network operator or automatically by a correlation or workflow process.

The event ID (for example, SNMPTRAP-link down). Multiple events can have the same event ID.

The event ID is populated by the probe rules file and used by IBM Tivoli Network Manager IP Edition.

The number of seconds from the time this alert was last received by the ObjectServer (LastOccurence) until it is cleared automatically. Used by the Expire automation.

0: Normal

1: Escalated

2: Escalated-Level 2

3: Escalated-Level 3

4: Suppressed

5: Hidden

6: Maintenance

The suppression level is manually selected by operators from the event list.

0: No

1: Yes

Operators can add alerts to the Task List from the event list.

• 0: Unknown
• 1: Root cause
• 2: Symptom

By default, this column is populated only for events that are generated by IBM Tivoli Network Manager IP Edition polls. To populate this column for other event sources such as probes, you must modify the rules files.

This column is similar to the NmosObjInst column, but is more granular. For example, the NmosEntityId value can represent the ID of an interface within a device.

You can use this column to filter out events from interfaces that are not considered relevant.

0: Not defined

1: Communications

2: Quality of Service

3: Processing error

4: Equipment

5: Environmental

6: Integrity violation

7: Operational violation

8: Physical violation

9: Security service violation

10: Time domain violation

Use this column only through the nvp_get, nvp_set, and nvp_exists SQL functions.

Region="EMEA";host="sf01392w";Error="errno=32: ""Broken pipe"""

In this example, the Region attribute has a value of EMEA, the host attribute has a value of sf01392w, and the Error attribute has a value of errno=32: "Broken pipe".

Notice that quotation marks are escaped by doubling them, as shown with the Error attribute value.

In name-value pairs, the value is always enclosed in quotation marks (" ") and embedded quotation marks are escaped by doubling them. The separator between name-value pairs is a semicolon (;). No whitespace is allowed around the equal sign (=) or semicolon.

The value of OldRow is changed to 1 in the destination ObjectServer for the duration of resynchronization if the Gate.ResyncType property of the gateway is set to Minimal.

The default is 0.

This column is added when you run the database initialization utility nco_dbinit with the -desktopserver option.

Also required for the Event Analytics component to work. The ParentIdentifier column is used to correlate events in parent-child relationships, which can be viewed in the Event Viewer. For more information, see the Netcool Operations Insight documentation at http://www-01.ibm.com/support/knowledgecenter/SSTPTP_1.3.0/com.ibm.netcool_ops.doc_1.3.0/soc/event_analytics/concept/soc_eventanalytics.html.