Incident Form

[This is the Context-Sensitive Help topic for the Incident form.]

See Interpret Root Cause Incidents for additional information about troubleshooting an incident.

The Incident form provides details for troubleshooting purposes. From this form you can access more details about the node involved, and the Source Object attribute provides more information about the interface, IP Address, connection, or SNMP Agent that is contributing to the problem. This form includes:

If your role permits, you can use this form to update the priority and Lifecycle State of the incident, assign a team member to investigate the problem, or add notes to communicate solutions or workaround information.

Basic Attributes
Attribute Description

Message

A description of the problem that you want NNMi to display.

Severity

Seriousness that NNMi calculates for the incident. Possible values are:

No Status

 Normal

 Warning

  Minor

  Major

  Critical

Disabled

Unknown

See About Status Colors for more information about severity values.

The icons are displayed only in table views.

Priority

Used to communicate the urgency of resolving the selected incident. You control this value. NNMi sets this value to null by default. The lower the number the higher the priority. Possible values are:

  None

  Low

  Medium

  High

  Top

The icons are displayed only in table views.

Lifecycle State

Identifies where the incident is in the incident lifecycle. You control this value.

  Registered – Indicates that an incident arrived in the queue stored in the NNMi database.  

  In Progress – State selected by someone on your team to indicate that they are taking responsibility for investigating the problem.

  Completed – State selected by someone on your team to indicate completion of the incident investigation and implementation of a solution.

  Closed – Indicates that NNMi determined the problem reported by this Incident is no longer a problem. For example, when you remove an interface from a device, all incidents related to the interface are automatically Closed.

NNMi does not automatically Close incidents whose Correlation Nature is  Info. These incidents are meant to provide information regarding changes in your network that might be of interest. You will need to Close these incidents if you do not want them to remain in your incident queue.

  Dampened – Indicates that, within the configured acceptable time period, NNMi determined the problem reported by this Incident is no longer a problem. NNMi does not submit the incident to the queue until after the time period (configured by the NNMi administrator).

In some cases, NNMi updates an incident's Lifecycle State for you.

The icons are displayed only in table views.

Source Node

The Name attribute value of the node associated with the incident. Click the  Lookup icon and select  Show Analysis or  Open to display the Node Form for more information about the node.

If the NNMi database does not contain any Node object for this device, the source node value is <none>.

Source Object

Name used to indicate the configuration item that is malfunctioning on the source node. Click the  Lookup icon and select  Show Analysis or  Open to display more information about the interface, IP address, connection, or SNMP agent.

Assigned To

Name of the user to which this incident is assigned. This value must be a valid user name (determined by the NNMi administrator). See Manage Incident Assignments for more information.

Notes

(NNMi Advanced - Global Network Management feature) The text you enter here is not sent from a Regional Manager (NNMi management server) to the Global Manager. NNMi administrators for the Global Manager can add notes that are stored in the NNMi database on the Global Manager.

Provided for communication among your team (for example, explanations or workarounds). Information might include reasons why the status was changed, what has been done to troubleshoot the problem, or who worked on resolving the incident.

Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+ -) are permitted.

You can sort your incident table views based on this value. Therefore, you might want to include keywords for this attribute value.

General Tab

[This is the Context-Sensitive Help topic for the Incident form, General tab.]

This form provides details for troubleshooting purposes.

General Attributes
Attribute Description
Name Name of the rule used to configure the incident. This name is initially created by NNMi.
Category

Generated by NNMi to indicate the problem category. Possible values include:

  Accounting - Used to indicate problems related to usage statistics and allocation of costs associated with the billing of time and services provided by devices. This category is not used by NNMi with default configurations, but it is available for incidents you define.

  Application Status - Indicates there is a problem with the health of the NNMi software. Examples of these kinds of events include license expiration or that a certain NNMi process lost connection to the Process Status Manager.

  Configuration - Indicates there is a problem with the configuration of a managed device. For example, there is a physical address mismatch.

  Fault – Indicates a problem with the network; for example, Node Down.

  Performance – Indicates an exceeded threshold. For example, a utility exceeds 90 percent.

  Security – Indicates there is a problem related to authentication; for example, an SNMP authentication failure.

  Status - Often indicates some status change occurred on a device. For example, when a Cisco device powers up or powers down.

The icons are only in table views.

Family

Used to further categorize the types of incidents that might be generated. Possible values are:

  Address – Indicates the incident is related to an address problem.

  Aggregated Port – Indicates the incident is related to a Link AggregationProtocols used on Switches to configure multiple Interfaces (Aggregation Member Interfaces) to function as if they were one (an Aggregator Interface). When two Aggregator Interfaces establish a connection, that connection is an Aggregator Layer 2 Connection. The Aggregator Layer 2 Connection appears on Layer 2 Neighbor View maps as a thick line with an Interface icon at each end (representing the Aggregator Interface). or Split Link AggregationLink Aggregation with more than two endpoints. Some vendors refer to this as Multi-Chassis Link Aggregation, SLAG, MLAG, or MC-LAG.problem. See Interface Form: Link Aggregation Tab (NNMi Advanced).

  BGP - Indicates the incident is related to a problem with BGP (Border Gateway Protocol). This family is not used by NNMi with default configurations, but it is available for incidents you define.

  Card – Indicates the incident is related to an card problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  Chassis – Indicates the incident is related to an chassis problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  Component Health – Indicates the incident is related to Node Sensor or Physical Sensor data collected by NNMi.

  Connection – Indicates the incident is related to a problem with one or more connections.

  Correlation – Indicates the incident has additional incidents correlated beneath it. These incidents are associated with a duplicate count so that you can determine the number of correlated incidents associated with it.

  Custom Poller – Indicates the incident is related to the NNMi Custom Poller feature. See About Custom Poller.

  DLCI – Indicates the incident is related to a problem with one or more DLCI connections.

  HSRP – (NNMi Advanced) Indicates the incident is related to a Hot Standby Router Protocol (HSRPHot Standby Router Protocol) problem.

  IP Subnet – Indicates the incident is related to a subnet problem.

  Interface – Indicates the incident is related to a problem with one or more interfaces.

  License - Indicates the incident is related to a licensing problem.

  NNMi Health – Indicates the incident is related to NNMi Health. See the Check NNMi Health for more information.

  Node – Indicates the incident is related to a node problem.

  OSPF – Indicates the incident is related to an OSPF problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  RAMS – (Route Analytics Management System (RAMS) for MPLS WAN) Indicates the incident is related to a Router Analytics Management System problem. If you are an NNMi administrator, see  RAMS MPLS WAN Configuration (NNMi Advanced) for information about configuring RAMS.

  RMON – Indicates the incident is related to a Remote Monitor (IETF standard, RFC 1757) problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  RRP – (NNMi Advanced) Indicates the incident is related to a Router Redundancy Protocol configuration problem.

  STP – Indicates the incident is related to Spanning-Tree Protocol problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  Stack – Indicates the incident is related to an stack problem. This family is not used by NNMi with default configurations, but it is available for incidents you define.

  Syslog – NNMi does not use this Family with default configurations. It is available for incidents you define.

  System and Applications – Indicates the incident is related to a problem with one or more systems or applications.

  Trap Analysis – (Network Node Manager iSPI Network Engineering Toolset Software) Indicates the incident is related to an SNMP trap storm.

  VLAN – Indicates the incident is related to a problem with a virtual local area network.

  VRRP – (NNMi Advanced) Indicates the incident is related to a Virtual Router Redundancy Protocol (VRRPVirtual Router Redundancy Protocol) problem.

Origin

Identifies how the incident was generated. Possible values are:

  NNMi – Indicates the incident was generated by NNMi processes.

  Manually Created – NNMi does not use this Origin with default configurations. It is available for incidents you define.

  SNMP Trap – Indicates the incident was forwarded from an SNMP Agent.

  Syslog – NNMi does not use this Origin with default configurations. It is available for incidents you define.

  Other – Indicates the incident was generated by a source other than the Origin categories provided.

Correlation Nature

This incident's contribution to a root-cause calculation, if any. Possible values are:

  Root Cause – Indicates the Incident is determined by NNMi's Causal Engine to be the source of a problem (for example, Node Down).

  User Root Cause – Indicates the Incident is configured by your NNMi administrator to make NNMi always treats this Incident as Correlation Nature: Root Cause.

  Secondary Root Cause – Indicates the Incident is related to Root Cause but is not the primary problem.

Secondary Root Cause Incidents are the Child Incidents of Parent Incidents and often begin as primary Root Cause incidents. Whenever a primary Root Cause Incident is correlated under another Incident, its Correlation Nature becomes Secondary Root Cause.

For example, if an Interface Down incident is followed by a Node Down Incident on a neighboring device, the Interface Down Incident becomes a Child Incident to the Parent Node Down incident. Its Correlation Nature becomes Secondary Root Cause.

Use the All Incidents view to examine both Secondary Root Cause and primary Root Cause Incidents. Use the Root Cause view to see only the primary Root Cause Incidents. In the Root Cause Incidents view, any Secondary Root Cause Incident is correlated under its associated primary Root Cause Incident.

  Symptom – Indicates any incidents that were generated from a trap notification related to the root cause incident. For example, a Link Down incident generated from a Link Down trap notification might appear as a Symptom to an Interface Down incident in the root cause incidents view.

  Service Impact - Indicates a relationship between incidents in which a network service is affected by other incidents. For example, an Interface Down incident can affect a Router Redundancy Group that is part of an HSRP service. This Correlation Nature is available for use by Network Node Manager i Software Smart Plug-ins (iSPIs). See "Help for Administrators" for more information about NNM iSPIs.

  None – Indicates there is no incident correlation for the incident.

  Info – Indicates the incident is informational only.

  Dedup Stream Correlation – Stream correlations are created as NNMi analyzes events and traps to determine the root cause incident for a problem.

Dedup Stream Correlation indicates the Incident is a Deduplication Incident.

Deduplication Incident configurations determine what values NNMi should match to detect when an Incident is a duplicate. Duplicate Incidents are listed under a Duplicate Correlation Incident. NNMi tracks the number of duplicates generated. This value is captured as the Duplicate Count attribute and is incremented on the Duplicate Correlation Incident.

   Rate Stream Correlation – Stream correlations are created as NNMi analyzes events and traps to determine the root cause incident for a problem. Rate Stream Correlation indicates the Incident is a Rate Incident.

Rate Incidents track incident patterns based on the number of incident reoccurrences within a specified time period. After the count within the specified time period is reached, NNMi emits a Rate Correlation Incident and continues to update the Correlation Notes with the number of occurrences within that rate.

Duplicate Count

Lists the number of duplicate incidents that NNMi encountered for the selected incident. This number increments in the associated deduplication incident that NNMi generates to inform the operator of incidents needing attention. The incidents are reoccurring according to the deduplication criteria specified in the incident's deduplication configuration.

For example, by default, incidents generated from SNMP traps will not have their deduplication count incremented. If the NNMi administrator defines a deduplication criteria for the SNMP trap, NNMi generates an incident specifying that the SNMP trap is reoccurring according to the criteria specified in the incident's associated deduplication configuration. This incident is the one that increments and displays the Duplicate Count value.

Note the following:

  • By default, NNMi updates the Duplicate Count every 30 seconds. This interval cannot be changed.
  • NNMi continues to update the duplicate count regardless of an incident's Lifecycle State. For example, if an incident's Lifecycle State is set to   Closed, the duplicate count continues to be incremented. This behavior helps you identify situations in which the incident is not yet fixed. Take note if the Duplicate Count is incremented after a lengthy time period has elapsed; this might indicate there is a new problem with the node, interface, or address.
  • Duplicates are configured by the NNMi administrator using the SNMP Trap Configuration, Syslog Messages Configuration, or Management Event Configuration form available from the Configuration workspace.
RCA Active

Used by NNMi to identify whether NNMi considers the incident to be active or inactive. If set to True, the incident is considered to be active. If set to False, the incident is considered to be inactive.

NNMi considers an incident to be active when the root cause analysis (RCA) engine is actively evaluating the problem reported by this incident.

NNMi considers an incident to be inactive when NNMi confirmed that the problem reported by this incident is no longer a problem. For example, the device is now functioning properly.

NNMi initially sets an incident's RCA Active attribute to True and the incident's Lifecycle State to   Registered. When NNMi sets the RCA Active attribute to False, it also sets the incident's Lifecycle State to   Closed.

Examples of when an incident's RCA Active attribute is set to False include:

  • When an interface goes up, NNMi closes the InterfaceDown incident.
  • When a node goes up, NNMi closes the NodeDown incident.
Correlation Notes

Stores notes about the correlation status of the incident.

NNMi provides the following information in the Correlation Notes field when it sets an incident's Lifecycle State to  Closed:

  • The Conclusion information identifying the reason NNMi changed the incident's Lifecycle State to Closed. For example, NNMi might include an Interface Up Conclusion as the reason an Interface Down incident was closed.
  • The time measured between when NNMi detected a problem with one or more network devices to the time the problem was resolved.
  • The time when NNMi first detected the problem associated with the incident.
  • The time when NNMi determines the problem associated with the incident is resolved.

NNMi inserts the information in front of any existing information provided.

NNMi provides Correlation Notes information only when the Causal Engine has analyzed and Closed the incident. Software that is integrated with NNMi might also provide information identifying the reason an incident was closed. Any time an incident is closed manually (for example, by the network operator), NNMi does not provide Correlation Notes information.

First Occurrence Time Used when suppressing duplicate incidents or when specifying an incident rate. Indicates the time when the duplicate or rate criteria were first met for a set of duplicate incidents or for a set of incidents that has a rate criteria that was met.
Last Occurrence Time

Used when suppressing duplicate incidents or specifying an incident rate. Indicates the time when the duplicate or rate criteria were last met for a set of duplicate incidents or for a set of incidents that has a rate criteria that was met.

If there are no duplicate incidents or incidents that have a rate criteria that were met, this date is the same as the First Occurrence Time.

Origin Occurrence Time The time at which an event occurred that caused the incident to be created; for example, the time held in the trap.

Correlated Parents Tab

[This is the Context-Sensitive Help topic for the Incident form, Correlated Parents tab.]

The Incident Form provides details for troubleshooting purposes.

Correlated Parents Table
Attribute Description

Correlated Parents

If the current incident is a child incident, any correlated parent incidents of the child appears in this table view. For example, parent incidents are created when a root cause problem is detected. A Node Down root cause incident is a parent of an Interface Down incident. Therefore, on an  Interface Down Incident  form, a Node Down incident might appear under the Correlated Parents tab.

Double-click the row representing an incident. The Incident Form displays all details about the selected incident.

Correlated Children Tab

[This is the Context-Sensitive Help topic for the Incident form, Correlated Children tab.]

This form provides details for troubleshooting purposes.

Correlated Children Table
Attribute Description
Correlated Children

If the current incident is a parent incident, any correlated child incident of the parent appears in this table view. For example, an Interface Down incident would be correlated as a child under a Node Down root cause incident. Therefore, on a Node Down incident form, an Interface Down incident would appear on the Correlated Children tab.

Double-click the row representing an incident. The Incident Form displays all details about the selected incident.

Custom Attributes Tab

[This is the Context-Sensitive Help topic for the Incident form, Custom Attributes tab.]

This form provides details for troubleshooting purposes.

NNMi lists the Custom Attributes for incidents in the order in which they are received from the SNMP trap. If you sort or filter the Custom Attribute table, click the Restore Default Settings icon to restore the Custom Attribute order for the selected incident.

(NNMi Advanced - Global Network Management feature) The NNMi administrator for the Global Manager can configure Custom Incident Attributes in addition to the ones that appear on the Regional Manager. If you are an NNMi administrator, see Enrich Incident Configurations for more information.

Custom Attributes Table
Attribute Description
Custom Incident Attributes

Used by NNMi to add additional information to the incident that NNMi makes available for viewing. Each CIA includes a name, type, and value group that can be populated differently for different types of incidents. Varbind values that accompany SNMP traps are a common use for this attribute.

Double-click the row representing the Custom Incident Attribute that has the Custom Incident Attribute Form you want to see. For more information, see Custom Incident Attributes Provided by NNMi section below.

Custom Incident Attribute Form

[Content-sensitive link for the Incident Form:Custom Incident Attribute form.]

The Custom Incident Attributes (CIAs) form provides extended information that NNMi gathered about the incident. For example, if the incident is reporting an SNMP trap, the Varbind values are stored as CIAs. Each CIA includes a name, type, and value group that can be populated differently for different types of incidents.

(NNMi Advanced - Global Network Management feature) The NNMi administrator for the Global Manager can configure Custom Incident Attributes in addition to the ones that appear on the Regional Manager. If you are an NNMi administrator, see Enrich Incident Configurations for more information.

To view custom incident attribute information:

  1. Navigate to the Incident form.

    1. From the workspace navigation panel, select the Incidents workspace.
    2. Select the incident view that contains the incident of interest; for example, Root Cause Incidents.
    3. To open the Incident form, double-click the row representing an incident. This form displays all details about the selected incident.
  2. In the Incident form, select the Custom Attributes tab.
  3. Double-click the row representing the Custom Incident Attribute (CIA) of interest.

See the table below for an explanation of the Name, Type, and Value attributes displayed.

All varbind values are stored as CIAs in NNMi.

Custom Incident Attributes
Attribute Description
Name

Name used to identify the CIA.

The Custom Incident Attribute (CIA) name limit is 80 characters. If this limit is exceeded, NNMi truncates the value from the left.

If different varbinds have the same oid, NNMi appends a number to the original oid; for example: .1.2.3.4.5.6.2.7.1_1 and .1.2.3.4.5.6.2.7.1_2
Type

Describes the type of data that is stored for the CIA. Examples of types include:

Double - Used to describe real numbers; for example 12.3

Integer - Used for integer numeric values; for example 1, 2, or 3

String - Used for character values

Boolean - Used to store true or false values

All SNMP Trap types begin with asn. If the CIA represents a varbind value, NNMi might provide additional types, such as Counter.
Value

For management events that are generated from NNMi, this value is the CIA value in the incident that was provided by NNMi.

The Custom Incident Attribute value limit is 2000 characters. If this limit is exceeded, NNMi truncates the value from the right.

Custom Incident Attributes Provided by NNMi (Information for Operators)

NNMi uses custom incident attributes to attach additional information to incidents.

A subset of CIAs are available for any particular incident. Any relevant CIAs are displayed on the Incident Form, in the Custom Attributes tab. There are two categories of possible CIAs: 

  • SNMP trap varbinds identified by the Abstract Syntax Notation value (ASN.1).Varbinds are defined in MIB files that the NNMi administrator can load into NNMi.
  • Custom incident attributes provided by NNMi.

Some of the potential custom incident attributes provided by NNMi are described in the table below. If you are an NNMi administrator, also see Custom Incident Attributes Provided by NNMi (for Administrators).

Custom Incident Attributes Provided by NNMi
Name Description
cia.address SNMP agent address.
cia.incidentDurationMs

The time measured in milliseconds between when NNMi detected a problem with one or more network devices to the time the problem was resolved.

This CIA is used only when NNMi's Causal Engine has analyzed and Closed the incident. Any time an incident is closed manually (for example, by the network operator), NNMi does not include cia.incidentDurationMs.
cia.reasonClosed

The Conclusion information identifying the reason NNMi changed the incident's Lifecycle State to Closed. For example, NNMi might include an Interface Up Conclusion as the reason an Interface Down incident was closed.

This CIA is used when NNMi's Causal Engine has analyzed and Closed the incident. Software that is integrated with NNMi might also provide values for cia.reasonClosed. Any time an incident is closed manually (for example, by the network operator), NNMi does not include cia.reasonClosed.
cia.remotemgr (NNMi Advanced - Global Network Management feature) Hostname or IP address of the either of the NNMi Regional Manager that is forwarding the event.
cia.snmpoid SNMP trap object identifier.
cia.timeIncidentDetectedMs

The timestamp in milliseconds when NNMi first detected the problem on the network device associated with the incident.

This CIA is used only when NNMi's Causal Engine has analyzed and Closed the incident.. Any time an incident is closed manually (for example, by the network operator), NNMi does not include cia.timeIncidentDetectedMs.
cia.timeIncidentResolvedMs

The time when NNMi determines the problem on the network device associated with the incident is resolved.

This CIA is used only when NNMi's Causal Engine has analyzed and Closed the incident. Any time an incident is closed manually (for example, by the network operator), NNMi does not include cia.timeIncidentResolvedMs.

For network monitoring thresholds, additional custom incident attributes are provided for your use. Click here for more information.

Custom Incident Attributes Provided for Fault Thresholds and Performance Thresholds
Name Description
cia.thresholdParameter

The monitored attribute that is being measured. The NNMi administrator configures these thresholds.

Possible threshold values for Nodes include:

  • Backplane Utilization

    Threshold based on the percentage of backplane usage compared to the total amount of available backplane resources.

(NNM iSPI Performance for Metrics) Possible performance thresholds for Interfaces include:

Requires Network Node Manager iSPI Performance for Metrics Software (NNM iSPI Performance for Metrics). To populate performance data in the dashboard views or enhance NNM iSPI Performance for Metrics reports by sharing NNMi configuration settings, install the optional Network Performance Server (NPS).

cia.thresholdLowerBound The configured value for the low threshold.
cia.thresholdUpperBound The configured value for the high threshold.
cia.thresholdPreviousValue Results from the previous Fault Polling Interval or Performance Polling Interval. For example, the performance threshold results for Interface Input Error Rate might change from Nominal to High, based on a change in the thresholdMeasuredValue. See Interface Form for a complete list of possible values.
cia.thresholdCurrentValue Results from the most recent Fault Polling Interval or Performance Polling Interval. For example, High. See Interface Form for a complete list of possible values.
cia.thresholdMeasuredValue The most recent measurement for the threshold monitored for violations. This measurement is the average of all measurements taken during the last polling interval (determined by the NNMi State Poller).
cia.thresholdMeasurementTime The time at which the threshold was reached. For example, if a threshold for the Input Error Rate is 6.0, and the thresholdMeasuredValue is 6.0, the time at which the thresholdMeasuredValue become equal to 6.0 is stored in this custom incident attribute. The time appears in ISO 8601 format.

Diagnostics Tab

[This is the Context-Sensitive Help topic for the Incident form, Flow Runs tab.]

This form provides details for troubleshooting purposes.

Diagnostics Table
Attribute Description

List of Diagnostics

Requires Network Node Manager iSPI Network Engineering Toolset Software (NNM iSPI NET) and requires installation of a Diagnostic Server.

The history of all the Diagnostic reports that have been run for the incident's Source Node. Diagnostics are sets of automated commands specific to one or more device types, including Cisco routers and switches, Cisco switch/routers, and Nortel switches.

To generate a new instance of these Diagnostics reports, click ActionsRun Diagnostics.

You can also right-click any object in a table or map view to access the items available within the Actions menu.

Double-click the row representing a Diagnostic report. NNMi displays all details about the selected report. See Incident Diagnostic Results Form (Flow Run Result).

Incident Diagnostic Results Form (Flow Run Result)

[This is the context-sensitive link for the Flow Run Results Form. This topic should not appear in the TOC.]

Requires Network Node Manager iSPI Network Engineering Toolset Software (NNM iSPI NET) and requires installation of a Diagnostic Server.

NNM iSPI NET automatically prepares diagnostic reports when certain incidents are generated and when using ActionsRun Diagnostics. This form shows details about the currently selected diagnostic report instance.

You can also right-click any object in a table or map view to access the items available within the Actions menu.Because the values on this form are generated by NNM iSPI NET, these attribute values cannot be modified.
 Diagnostic Results Details
AttributeDescription
Start TimeDate and time NNM iSPI NET created this instance of the Diagnostics report. NNM iSPI NET uses the locale of the client and the date and time from the NNMi management server.
DefinitionThe name of the flow as defined in NNM iSPI NET.
Status

The current status of this NNM iSPI NET Diagnostics report. Possible values include:

New - The Diagnostic is in the queue, but is not yet running

In Progress -The Diagnostic has been submitted and is not finished running

Completed - The Diagnostic has finished running

Not Submitted - An error condition prevented the Diagnostic from being submitted

Timed Out - NNMi was unable to submit or run the Diagnostic due to a timeout error. The timeout limit for submitting a Diagnostic is one hour. The timeout limit for running a Diagnostic is four hours.

Example error conditions include the following:

  • The number of Diagnostics in the queue might prevent NNMI from submitting the Diagnostic.
  • A configuration error, such as an incorrect user name or password, might prevent NNMi from accessing the required Operations Orchestration server.

Contact your NNMi administrator for Diagnostic log file information.

Report

NNM iSPI NET uses this text string to display the selected instance of the diagnostics report in a browser window.

Click this link to open the actual report.

You might be prompted to provide a user name and password to access the Operations Orchestration software. See the NNM iSPI NET Planning and Installation Guide for more information.
Lifecycle State

Incident Lifecycle State of the target Incident.

If the incident's Lifecycle State matches the value specified here, the Diagnostic runs.

The Diagnostic automatically runs on each applicable Source Node in the specified Node Group if the incident has the Lifecycle State currently configured in this attribute of the Diagnostic (Flow Definition - set of automated commands).

Last Update TimeDate and time NNM iSPI NET last updated this instance of the Diagnostics report. NNM iSPI NET uses the locale of the client and the date and time from the NNMi management server.

Registration Tab

[This is the Context-Sensitive Help topic for the Incident form, Registration tab.]

This form provides details for troubleshooting purposes.

Registration Attributes
Attribute Description

Created

Date and time the selected object instance was created. NNMi uses the locale of the client and the date and time from the NNMi management server.

This value does not change when a node is rediscovered. This is because the Node object is modified, but not created.

Last Modified

Date the selected object instance was last modified. NNMi uses the locale of the client and the date and time from the NNMi management server.

Note the following:

  • When a node is rediscovered, the Last Modified time is the same as the Discovery Completed time. This is because the node’s Discovery State changes from Started to Completed.
  • When a Node is initially discovered, the Last Modified time is slightly later than the Created time. This is because node discovery does not complete until after the Node is created.
Object Identifiers Attributes
Attribute Description

ID

The Unique Object Identifier, which is unique within the NNMi database.

UUID

The Universally Unique Object Identifier, which is unique across all databases.