Use > Monitor Incidents for Problems

Monitor Incidents for Problems

See Incident Form for more details about the Incident attributes that appear in an incident's view column headings.

NNMi actively notifies you when an important event occurs. The event is reflected by a change of background color of a node in a network map and is reported through incident views.

NNMi enables an NNMi administrator to limit visibility and control to parts of the network for some or all operators. If your NNMi administrator has configured Security Groups to limit node access, then as a network operator you can view a node and its associated incidents only if one of the User Groups to which you belongs is associated with that node's Security Group. See .Node and Incident Access for more information.

Many services (background processes) within NNMi gather information and generate NNMi incidents. In addition, an SNMP agent might send information to NNMi. For example, an SNMP agent detects that a managed critical server is overheating and about to fail. The SNMP agent forwards a trap to NNMi.

Incidents might also be reporting on information that was requested by NNMi. For example, NNMi might generate an "Address Not Responding" incident after using ICMP to check whether communication channels are open to a device (using ping).

For most incident views displayed, you can identify an incident's overall severity, Lifecycle State, source node, source object, and its message.

Some incidents might have the Source Node or Source Object value set to <none>. This happens when the NNMi database does not contain any object representing the problem device. Example: An incident having a Source Node or Source Object that is not included in the current NNMi Monitoring Configuration settings might be displayed as <none>.

The following table describes the severity icons used by NNMi.

Incident Severity Icons
Icon Meaning Icon Meaning Icon Meaning Icon Meaning
Normal Minor Critical Disabled
Warning Major Unknown No Status

NNMi provides management mode attributes that determine whether an is discovered and monitored (for example, node, chassis, interface, card, or address). Your administrator can set some of these management mode attribute values. Any object that has a management mode that is set so that it is no longer discovered and monitored might still have incidents associated with it that existed before the object was no longer managed. To check whether   a node associated with an incident is being managed, open the form for the incident and then open the form for the source node associated with the incident. See Working with Objects for more information.

Incident views are useful for quickly identifying items described in the following table.

Incident View Uses
Use Description

Identify potential or current problems

Within a view, each incident has a corresponding icon that indicates its severity so that you are immediately notified of potential or current problems.

You can filter incidents so that you only view incidents that has a severity that is Critical or you can choose to filter incidents to view all incidents that have a severity that is greater than Normal.

Identify problem nodes

You can sort incidents by node to help you quickly identify the problem nodes.

Determine the cause of the problem

You can sort an incident view by description, to see all incidents reporting a node or interface that is disabled or otherwise unavailable.

You can also use the child incidents attribute to view all of the incidents that are a result of the root cause problem reported.

Determine historical information

You can sort your incidents by notification date to determine whether a group of nodes went down within a specified time frame.

You can also filter your list of incidents according to notification date to view only those incidents received within the last hour.

To track historical information for a specific node, sort your incidents by First Occurrence. Then, filter your view by node Name. This lets you view a chronological list of the kinds of errors (indicated by Origin) that have occurred for the current node.

You can then open the Incident form to use the child incidents attribute to view all of the incidents that are a result of the root cause problem reported.

Identify only the incidents important to you

You can filter an incident view so that you see only those incidents of interest. For example, you might filter incidents so that you only view incidents that have a status that is Critical or only those incidents assigned to you. You can also view only those incident associated with a Node Group. Your NNMi administrator creates node groups. For example, your NNMi administrator might choose to group all of your important Cisco routers into a node group. See Filter Views by Node or Interface Group for more information.

Your NNMi administrator can define the format of incident messages so they are most useful to you and your team.

Your team can use the Notes attribute of the incident views to notify everyone else about which issues are being covered.

If a node is deleted, only an NNMi administrator can view the incidents associated with that node.

Tasks Performed from an Incident View

You can perform the following tasks from an incident view:

Organize Your Incidents

Track an Incident's Progress

Apply an Action to an Incident Source Node or Source Object

Monitor Incidents in a Global Network Management Environment (NNMi Advanced)

Own Incidents

Assign Incidents

Unassign Incidents

Keep Your Incidents Up to Date

Display a Map from an Incident

Organize Your Incidents

You can organize your incidents in one of three ways:

  1. Sort them according to the column of interest. For example, you might want to sort your incidents by status.
  2. Filter them according to the values for a particular column or attribute. For example, filtering by status lets you filter out the status values that are not of interest to you. Filtering by the Assigned To attribute lets you view only the incidents assigned to you.
  3. Filter them according to a Node Group. Your network administrator can group sets of nodes into Node Groups. An example Node Group could be all important Cisco routers, or all routers in a particular building. See Filter Views by Node or Interface Group for more information about filtering a view by Node Group.

See the help topic for each incident view for more details about how you might want to sort or filter a specific incident view.

Track an Incident's Progress

NNMi provides the Lifecycle State attribute to help you track an incident's progress. Your network administrator might have additional or different guidelines for their use.

Possible Lifecycle State values are as follows:

  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.

You should know your guidelines for lifecycle states so that you can keep your incidents updated accordingly.

To update your Lifecycle State, use the ActionsChange Lifecyclemenu or a form.

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

To update your Lifecycle State using the Actions menu from a view:

  1. If you do not have an incident open, from the workspace navigation panel, select the incident view you want to open.
  2. Select the row representing the incident that has a Lifecycle State you want to change.
  3. From the main menu toolbar, select ActionsChange Lifecycle and then the Lifecycle State you want, for example, In Progress.

To update your Lifecycle State from a form:

  1. If you do not have an incident open, from the workspace navigation panel, select the incident view you want to open.
  2. From the incident view, open the incident you want to update.

    Under the Basics pane, select the Lifecycle State you want from the drop-down menu.

    From the main menu, click Save to save your changes or  Save and Close to save your changes and exit the form.

    From the form menu, select Actions and then the Lifecycle State you want. For example, select Completed.

    The action takes effect immediately. This means you do not have to select Save.

  3. After performing an action on a form that modifies the object being viewed, you must refresh the form before you can save any additional changes.

Apply an Action to an Incident Source Node or Source Object

If you are using incident views to monitor your network, you might want to apply an action from the Actions menu to the incident Source Node or Source Object to determine more information. NNMi enables you to access the same actions that are available for node, interface, and IP address objects.

Only the Actions that apply to either the incident's Source Node or Source Object are available. If the Action does not apply to either the Source Node or Source Object, the color of that Action turns from black to gray to indicate it is unavailable.

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

To access an action from an incident view:

  1. Navigate to the incident view of interest (for example, Incident Browsing workspace, Root Cause Incidents view).
  2. Select the row representing the incident of interest.

    Select only one incident.

  3. From the Actions menu in the main toolbar, select one of the following menu options:

    • Node Actions
    • Interface Actions
    • IP Address Actions
  4. Select an action that is valid for either the incident Source Node or Source Object. See Using Actions to Perform Tasks for information about the actions available for each object type. Also see Investigate and Diagnose Problems.

    NNMi performs the selected action on whichever of the following is the valid object for the action selected:

    • Incident's Source Node
    • Incident's Source Object

To access an action from an incident form:

  1. Navigate to the incident view of interest (for example, Incident Browsing workspace, Root Cause Incidents view).
  2. Double-click the row representing the incident from which you want to select an action.
  3. From the Actions menu in the main toolbar, select one of the following:

    • Node Actions
    • Interface Actions
    • IP Address Actions
  4. Select an action that is valid for either the incident Source Node or Source Object. See Using Actions to Perform Tasks for information about the actions available for each object type. Also see Investigate and Diagnose Problems.

    NNMi performs the selected action on whichever of the following is the valid object for the action selected:

    • Incident's Source Node
    • Incident's Source Object

Monitor Incidents in a Global Network Management Environment (NNMi Advanced)

The NNMi Global Network Management feature enables multiple NNMi management servers to work together while managing different geographic areas of your network. Each NNMi management server discovers and monitors a portion of the network. Concept Link IconSee Also

Specific NNMi management servers can be designated as Global Managers and display the combined Node object data. However, each Regional Manager maintains responsibility for management of Nodes that were forwarded to a Global Manager. The Global Manager generates and maintains an independent set of Incidents related to those Nodes. The Incidents on the Global Manager are generated within the context of the combined topology and using the Incident configuration settings on the Global Management server.

Regional Manager administrators can intentionally forward copies of SNMP Trap Incidents to the Global Manager:

On the Global Manager, the Custom Incident Attribute tab on the Incident form identifies if the SNMP Trap Incident was forwarded and from which Regional Manager.

From any Incident view, to determine the server or servers that forwarded the incident:

  1. From the workspace navigation panel, select a workspace containing a view of the incidents of interest (for example, Incident Management workspace).
  2. Select a view that contains the specific incident (for example Open Key Incidents view).
  3. Double-click the row representing an incident. The Incident Form displays all details about the selected incident.
  4. Navigate to the Custom Attributes tab.
  5. In the Name column of table view, look for the following value: cia.remotemgr.

    • If cia.remotemgr is not listed, this means the incident was not forwarded from a Regional Manager.
    • If cia.remotemgr appears in the list of Custom Attributes, NNMi displays the hostname of the NNMi Regional Manager in the corresponding Value column.

    If the trap or event has been forwarded through multiple servers, cia.remotemgr includes the hostname or IP address of each forwarding server, separated by commas. The list of servers provided in cia.remotemgr starts with the server that generated the original SNMP Trap Incident or Management Event Incident.

Related Topics

Display a from an Incident (Custom Poller Only)

Incident Views Provided by NNMi