FeedbackTable Of Contents
Correlation and Root Cause Analysis
Attributes Used by the Event Correlation Algorithm
Associating Events, Tickets, and Alarms
Ticket-Related Configuration Options
Northbound Integration Services
Fault Management in Cisco ANA
A common problem in the management of large networks is that a single fault manifests itself as multiple alarms in the Network Management System (NMS). This makes manual analysis of faults costly and also diverts attention from major problems. This is a major motivation for applying analysis and correlation in an NMS.
Many types of problems threaten service delivery; for example, hardware failures, software failures, and so on. An effective root cause analysis technique must be capable of identifying all these problems automatically. This technique must work accurately for any environment and for any topology, including interrelated logical and physical topologies, with or without redundancy.
Cisco ANA analyzes and manages faults by implementing world-class event collection, identification, and correlation functionality. After identifying the event, Cisco ANA groups related events and uses the automatically discovered virtual network model to perform fault inspection and advanced correlation to determine the root cause of the fault and to create a ticket.
Cisco ANA 3.7 introduces a fault management architecture that:
•
Ensures that events are never incidentally dropped.
•
•
•
•
•
The following topics describe the key concepts of Cisco ANA fault management:
•
•
Event Management
An event is a distinct incident that occurs at a specific point in time. Examples of events include:
•
•
•
•
An event is a possible symptom of a fault, which is an error, failure, or exceptional condition in the network.
Events and Alarms
In Cisco ANA NetworkVision and Cisco ANA EventVision, an event is represented by a small icon in the form of a bell (see Figure 2-1).
Figure 2-1 Example Events
Events have an associated severity. Events with a severity of Critical (red), Major (orange), Minor (yellow), and Warning (sky blue) are said to be flagging events; events with a severity of Cleared (green) are called clearing events. Events that are informational in nature are marked in dark blue.
The lifecycle of a fault scenario is called an alarm. An alarm is characterized by a sequence of related events, such as port-down and port-up. In this guide, an alarm is denoted by an oval (see Figure 2-2).
Figure 2-2 Example of an Alarm
If event A is followed by event B as part of an event sequence, then event A is the predecessor of B and B is A's successor.
The last event in the sequence determines the severity and state of the alarm. An alarm that ends with an event that has a severity of cleared is called a cleared alarm.
Event Discovery
Cisco ANA discovers events in the following ways:
•
•
Network Events
Events can pertain to network faults or network elements:
•
•
Upon receipt of an event notification or service alarm, Cisco ANA frequently expedites (immediately triggers) the polling of specific data from the device. Thus, the incoming notifications often yield additional generated event notifications or service alarms that are key to the subsequent correlation process.
The list of traps and syslog notifications that cause polling expedition is device specific, and varies from VNE to VNE.
Internal Faults
In addition to network faults, the gateway and units can generate system events that indicate Cisco ANA internal faults, such as disk full or unit unreachable.
Event Identification
The event manager parses the event notification message to obtain more information about the event and creates an internal event object to represent the underlying event. During event identification, Cisco ANA determines the following information:
•
•
•
•
•
Based on the event type and event subtype, an event has numerous additional correlation and metadata attributes that determine how the event is processed by Cisco ANA. These attributes are discussed in Chapter 3, "Correlation Scenarios." These attributes are documented in the Cisco Active Network Abstraction 3.7 Reference Guide.
Incoming Event Identification
Incoming event notifications (traps and syslogs) are identified by matching the event data to predefined patterns. A trap or syslog is considered supported by Cisco ANA if it has matching patterns and can be properly identified.
If the incoming event notification cannot be identified, Cisco ANA creates an event-object of the nonactionable type. Nonactionable events are not used in subsequent correlation activity. Instead, Cisco ANA preserves the trap OID and forwards it through the event notification service for both nonactionable and known event types.
The payload structure of a particular trap might differ between SNMP versions, and a trap might be supported by Cisco ANA only for a specific SNMP version.
In some cases, the identification is based on the internal values of the event. For example, the Line Down trap is mapped to event type and subtype as described in Table 2-1.
Table 2-1 Line Down Trap
Status=down
Line Down trap
Line Down trap
Status=up
Line Down trap
Line Up trap
Traps are mapped to event type and subtype regardless of the SNMP version in use.
Event Dropping
The event type determines whether the event continues to be processed or is dropped. Events that are dropped after event identification are not stored in the fault database, and do not participate in correlation. Dropping events at this stage is important because it prevents Cisco ANA from being overwhelmed by large numbers of insignificant event notifications.
Event Severity
Each event has an assigned severity. Events broadly fall into the following three severity categories, each with their associated color in Cisco ANA EventVision and Cisco ANA NetworkVision:
•
•
•
For example, a Link Down event might be assigned a critical severity, while its corresponding Link Up event will have a cleared severity.
The last event in the sequence determines the severity of an alarm (an event sequence). Exceptions to this rule include bookkeeping events (see Bookkeeping Events), which do not change the severity of the sequence (the alarm).
Event Source Association
Event identification is followed by source association. Cisco ANA examines and parses the event notification message to pinpoint the precise entity that is the location, or source, of the event. Rather than simply relate the event to the managed element as a whole, the association code determines the precise source of the event. The source corresponds to an object in the VNE model. The event is populated with the unique IMO identifier of that object (the OID).
For instance, the source of an Ethernet flow point (EFP) Down event would be the corresponding EFP model object. Correctly associating an event to its closest source is an important step for the subsequent correlation actions.
Source Association Fallback
In some cases, the event source might not be in the internal VNE model at the time of the event notification. For instance, when a new module is inserted, it takes some time for Cisco ANA to poll all its interfaces and build up (populate) the model. If the new event notification is handled before the model is fully populated, the association logic might fail to find and retrieve the entity that is the correct source of the trap. A retry mechanism minimizes the occurrence of such a rare condition, but if it persists, the association logic falls back to the managed element entity (the network element) that is the source of the new event. An additional identifier (the alarm differentiator), representing the intended source, is later used in the correlation logic. For more information about alarm source OIDs, see the Cisco Active Network Abstraction 3.7 Reference Guide.
Correlation and Root Cause Analysis
Causality correlation is the process of relating an event to an existing alarm in a causality relationship. The root of the resulting causality hierarchy is called the root cause, and the correlation process that determines the root cause of a fault is referred to as root cause analysis (RCA).
RCA is performed on historic snapshots of the VNE model and forwarding information. These snapshots, maintained for ten minutes, enable the correlation logic to traverse the VNE network model at a time in the past, before the occurrence of the fault that is being analyzed. This is critical for root cause analysis in the presence of network faults.
The unique correlation capability of Cisco ANA is derived from this ability to learn the impact of the suspected fault by examining snapshots of the network before the occurrence of the fault.
Network and Local Correlation
Cisco ANA supports both network and local correlation and RCA of events:
•
•
•
After correlation and RCA, the event is considered an enriched event.
For more information about correlation and root cause analysis, see Chapter 3, "Correlation Scenarios."
Event Correlation and Alarms
Event correlation is the process of relating one event to other events. Cisco ANA distinguishes two types of relations between events:
•
Figure 2-3 Event Sequence
For more information, see New Event Associations.
•
Causality correlation is the process of relating an event to an existing alarm in a causality relationship (see Figure 2-4).
Figure 2-4 Causality Correlation
Causality correlation creates a hierarchy, and the top-most cause is called the root cause.
In Figure 2-5, the Link Down alarm is the cause for OSPF Neighbor Loss alarm, and Card Out is the cause for Link Down and the root cause for all the other alarms as well.
Figure 2-5 Root Cause Analysis
For more information about event correlation, see Chapter 3, "Correlation Scenarios."
New Event Associations
Cisco ANA associates a new event to an existing event if it identifies an existing event with the following criteria:
•
•
•
•
–
Figure 2-6 Updating an Alarm
–
Figure 2-7 Extending a Cleared Alarm
If the new event arrives later, cannot be associated, and is ticketable, a new alarm is created, as illustrated in Figure 2-8.
Figure 2-8 Creating a New Alarm
Flapping Events
Flapping is the occurrence of a flood of consecutive event notifications (often severity toggling) related to the same alarm. Flapping can happen when a fault is unstable and causes repeated event notifications; for example, the use of a cable with a loosely-fitting, rattling connector. Cisco ANA recognizes this flapping phenomenon, and represents the new event notifications with a single generated event with a flapping subtype. The alarm is said to be flapping. When the fault stabilizes and the new event notification frequency returns to normal, the fault management logic terminates the alarm's flapping mode by generating a final event notification (either Flapping Stopped Cleared or Flapping Stopped Uncleared subtype), based on the state of the fault (the last received new event notification) at that time.
During flapping, the fault management logic generates periodic event notifications with a Flapping Update subtype that also becomes part of the alarm's event sequence.
A flapping situation is illustrated in Figure 2-9.
Figure 2-9 Flapping Event
A sequence of events is identified as flapping if:
•
•
•
Flapping detection is enabled for certain events and disabled for others.
For information about customizing fault behavior, see the Cisco Active Network Abstraction 3.7 Customization User Guide.
Event Persistence
Events that are not dropped after the identification phase and that are correlated, are stored in the fault database. The relationships between the events are also retained. The content of the database can be reviewed using the Cisco ANA EventVision application.
Note
Archive Events
The stored events might be marked as archived. Archived events are persisted in the fault database and can be viewed by using Cisco ANA EventVision.
An event is archived if either of the following is true:
•
•
Attributes Used by the Event Correlation Algorithm
Table 2-2 describes the attributes that control the algorithm Cisco ANA uses to perform event correlation.
Correlation Process
Figure 2-10 illustrates the Cisco ANA correlation process.
Figure 2-10 Correlation Process in Cisco ANA
The correlation process starts after a VNE receives a new event notification (see Event Identification). The correlation steps, shown in Figure 2-10, include:
A
The first step in the process is event identification. After the trap has been identified, and if it is not dropped by the VNE, its attributes are determined.
Note
B
Cisco ANA examines and parses the event notification message to pinpoint the precise entity that is the location, or source, of the event. For more information on event source association, see Event Source Association.
C
Cisco ANA then examines the new event for flapping. If this event is part of a flapping sequence, it is suppressed as described in Flapping Events.
D
Cisco ANA then further examines the new event. If the event is configured for correlation, the new event is subject to correlation. Most flagging events are subject to correlation; clearing events are not. If this event was configured to expedite polling, the specific polling command is generated as well, which might result in additional generated events.
If the event is not configured for correlation, Cisco ANA tries to relate the event to an event sequence. See Step J to Step M for additional details.
E
The correlation process is suspended for two minutes. This gives other events, possibly related in terms of cause and effect, a chance to be detected.
No further processing is performed on the event while it is suspended. As a result, the update to the fault database and Cisco ANA NetworkVision for this event is delayed by two minutes.
F
After the two-minute suspension, other events are examined for possible causality. Two different processes can be followed: local correlation (Step G) or network correlation (Step H), depending on the event configuration.
G
Local correlation examines and finds other events related to the same (local) NE from which the new event originated; no network flow is initiated.
Local correlation is well suited for the following scenarios:
•
•
•
Most trap and syslog events use the local correlation process. The correlation logic looks for causing events in the VNE that:
•
•
•
H
Flow or network correlation broadens the search for events to those coming from other NEs, including those that are several hops away.
Flow correlation is well suited for the following scenarios:
•
•
Flow correlation uses historic snapshots of the VNE model to search the local VNE and other VNEs for causing events that meet the following criteria:
•
•
•
I
Correlation processes often yield more than one candidate-causing event. Additional, specific, rule-based filtering logic eliminates unlikely causing events, such as Cloud Problem, BGP Process Down, or LDP Neighbor Down. Finally, the causing event with the highest weight (or the closest in time, when there is more than one) is selected as the causing event.
The new event becomes the starting point of a new, correlated alarm.
J
If the previously described correlation process does not yield any causing events, or the new event was not subjected to correlation, it is possible that the new event simply relates to an existing event sequence (alarm). Cisco ANA searches for such an event sequence with the same source and event type as the new event.
K
If a matching event sequence is found, the new event is appended to it, and the alarm severity is updated accordingly.
L
If no matching alarm is detected, the new event is potentially a root cause in its own right. If the new event is ticketable, it is the basis for a new alarm that, in turn, causes the creation of a new ticket.
M
If the new event is not ticketable, it is archived and is no longer involved in correlations.
Ticket Management
Ticket management refers to managing the life cycle of tickets, including:
•
•
•
•
Ticket creation is distributed among the units. When a ticket needs to be created, it is created in the unit that generated it by the fault agent running in that unit.
Events and alarms are associated with tickets by polling the fault database and associating enriched events with the tickets and alarms.
Ticket management includes both automatic and manual operations that are involved in managing the life cycle of a ticket and alarm. Automatic operations include associating an event with a ticket and alarm, updating the aggregated ticket state (such as severity and event counter), and automatic archiving. Manual operations include acknowledging a ticket, clearing a ticket, and so on. The automatic operations are orchestrated by the ticket agent in the gateway.
For information about automatic operations, see Automatic Operations. For information about manual operations, see Ticket Management Operations.
Tickets
An alarm represents a scenario that involves a fault in the network, a managed element, or the management system. A ticket represents an attention-worthy root alarm whose type is marked as ticketable. A ticket has the same type as the root alarm it represents, and it has a status, which represents the entire correlation tree.
A ticketable event is an event that becomes a root cause for a new ticket if the new ticket is not correlated to any other event. Events are configured to be ticketable or not ticketable. For more information, see Ticket-Related Configuration Options.
Each ticket assumes the propagated severity of the alarm with the top-most severity, within all the alarms in the correlation hierarchy at any level.
A ticket is considered open as long as its severity is not cleared.
Both Cisco ANA NetworkVision and Cisco ANA EventVision display tickets and allow drilling down to view the consequent alarm hierarchy.
From an operator's point of view, a fault is always represented by a complete ticket. Operations such as Acknowledge or Remove are always applied to the whole ticket.
A ticket points to the root cause alarm that is the top-most alarm in the correlation hierarchy. The attributes of the ticket (such as short description) are derived from the root cause alarm.
Automatic Operations
In ticket management, automatic operations include finding the ticket to which an event belongs, finding the alarm to which the event belongs, and updating both. Alarms define a sequence of events in a ticket. Once the ticket is found, updating the alarm is immediate. Each event originating in the network is associated with a ticket. Only those events that are marked attention worthy, or ticketable, are visible to Cisco ANA NetworkVision. All alarms and tickets can be viewed in Cisco ANA EventVision.
Associating Events, Tickets, and Alarms
The main component of ticket management queries the fault database and retrieves events that can be connected to the ticket. Events that can be connected to a ticket are those events whose ticket ID is not known yet, but the ticket ID of the preceding event is known. The component continually executes this query to retrieve events that are not yet connected to a ticket or alarm. The following actions are taken for each event that is selected by the query:
1.
2.
3.
No events are lost in this process. As long as events are successfully persisted with their correlation information and the preceding event ID, they are associated with a ticket.
Clearing Tickets
Every minute, Cisco ANA reviews all the tickets and looks for tickets to clear. Cisco ANA clears a ticket if all of its events either are cleared or are configured for automatic clearing. In addition, Cisco ANA checks for tickets to archive. The archive timeout of a ticket is determined by the archive timeout setting of the root cause event.
Auto-Archiving Tickets
Auto-archiving is a ticket management component that periodically checks for tickets that are candidates for archiving. A ticket is a candidate for archiving if:
•
•
Auto-archiving interacts only with the fault database. Archiving a ticket marks its events and alarms as archived. They are not permanently deleted from the fault database. Events are kept in the fault database for three months. Alarms can be deleted sooner than three months because all required information exists in the event tables.
Ticket Management Operations
The following management operations might be applied to a ticket either manually or through the system (northbound) API:
•
•
•
Remove and Clear operations might be done automatically by the system. The mechanism used for these automatic processes is described in the following topics:
For more information about integrating with northbound applications, see the Cisco Active Network Abstraction Integration Developer Guide.
Bookkeeping Events
Cisco ANA also generates bookkeeping events. When a ticket is archived or acknowledged, a bookkeeping event is generated for all alarms that are correlated to the ticket.
Ticket-Related Configuration Options
You can configure the following ticket management options:
•
•
For example, in a link down > link up > link down scenario, you can specify how long to wait between the Link Up event and the second Link Down event before a new ticket is opened. This configuration option is relevant for tickets only. Once a ticket is cleared or auto-cleared and this timeout is exceeded, the ticket can be archived.
•
•
For more information about customizing fault behavior, see the Cisco Active Network Abstraction 3.7 Customization User Guide.
Ticket Auto-Remove
Cisco ANA uses the auto-remove process to remove tickets automatically. The process launches periodically and scans all unarchived tickets. It removes a ticket automatically if all of the following conditions are met:
•
•
•
•
The default value for the time interval to trigger the auto-remove process is one minute.
Note
Cisco ANA implements an additional automatic process to maintain the number of concurrent open (noncleared) tickets below a predefined threshold. If the number of open tickets found is above the threshold, the oldest tickets are removed and archived.
For more information about customizing fault behavior, see the Cisco Active Network Abstraction 3.7 Customization User Guide.
Ticket Auto-Clear
Situations can occur in which the root cause alarm is cleared, but alarms that are not cleared remain in the ticket correlation tree.
Noncleared alarms might exist in the correlation tree for one of the following reasons:
•
•
The situation described in the second scenario is undesirable, and Cisco ANA enables you to configure automatic clearing of alarms to address this type of situation.
Figure 2-11 shows an example ticket of a Link Down alarm.
Figure 2-11 Ticket of a Link Down Alarm
In this example, the alarm has been cleared (Link Up), but the severity of the ticket is still Major (Orange).
The reason for this situation is found in the correlation tree of the ticket (see Figure 2-12). The tree contains one Link Down syslog alarm that has not been cleared because its clearing syslog event did not reach Cisco ANA.
Figure 2-12 Correlation Tree of the Link Down Ticket
You can configure Cisco ANA so that it clears alarms automatically, or you can manually clear the ticket in Cisco ANA NetworkVision.
You can configure automatic clearing for each event type in Cisco ANA. It indicates whether or not this type of event can be automatically cleared by the auto-clear mechanism. This mechanism runs on Cisco ANA every minute and iterates on all the tickets that are not archived. For any open ticket, the auto-clear mechanism determines if all of its events either are cleared or are configured for automatic clearing. If the open ticket meets either of these criteria, the mechanism automatically clears the ticket.
Note
When an event is cleared automatically, the clearing event description displayed in Cisco ANA NetworkVision indicates this (for example, Auto Cleared - Link Down due to Admin Down).
In Cisco ANA, all syslogs and traps are configured to clear automatically, except the following:
•
•
Note
Syslog and trap events that are not cleared automatically must be cleared manually, using Cisco ANA NetworkVision.
The process that checks periodically for open tickets is also used to automatically remove tickets. As a result, both operations share the same time interval, which is one minute by default.
Duplicate Alarm Processing
By default, Cisco ANA avoids creating duplicate tickets by identifying and appropriately linking duplicate alarms to existing alarms within previously generated tickets.
Figure 2-13 shows a generic example. Alarm 1 is the top-most, or root, alarm for the ticket. Alarms 2 and 3 are both part of the correlation tree, derived from Alarm 1. Two duplicate alarms, Alarm 1.1 and Alarm 1.2, have arrived and Cisco ANA has assigned them as successors to Alarm 1.
Figure 2-13 Duplicate Alarms in a Ticket Correlation Tree
Cisco ANA uses the predecessor/successor concept to handle incoming duplicates properly, without either discarding them or creating new tickets for them. In this example, Alarm 1 is the predecessor of Alarm 1.1, and Alarm 1.1 is the successor of Alarm 1. Similarly, Alarm 1.1 is the predecessor of Alarm 1.2, and Alarm 1.2 is the successor of Alarm 1.1.
When an alarm arrives, Cisco ANA searches among its stored alarms for a possible predecessor. In this example, when Alarm 1.1 arrives, Cisco ANA identifies Alarms 1, 2, and 3 as possible predecessors, and then identifies the correct predecessor by matching it against the incoming alarm according to the following rules:
•
•
•
•
•
•
If all of these conditions are met, the incoming alarm is assigned to that predecessor, as shown in the example. The predecessor alarm also sets its successor to the new alarm. Later duplicates (like Alarm 1.2) become successors to the new alarm under the same processing rules.
Event Flow Through Cisco ANA
Figure 2-14 illustrates the flow of events through Cisco ANA.
Figure 2-14 Event Flow Through Cisco ANA
Events flow through Cisco ANA as follows:
1.
–
–
2.
3.
4.
–
–
–
–
–
–
5.
–
–
–
6.
7.
8.
9.
The actual event rates and optimal configurations of the flow processing path are highly dependent on many factors, including:
•
•
•
•
Exhaustive testing is required before changing default values.
Event Reduction
A key concept that is implemented in Cisco ANA fault management is that of event reduction, thereby providing you with correlated, actionable tickets. See Figure 2-15.
Figure 2-15 Event Reduction
As illustrated, the AEC collects a large number of events from the network and from managed devices. Some of events are actionable while others are not. After saving all events to the event archive, Cisco ANA drops the events that are nonactionable.
The remaining actionable events are identified and examined to determine whether they represent a sequence of related events or alarms. For example, a number of events that arrive from the same device within a short period of time might be grouped and identified as an alarm because it is likely that they are related to each other.
The groups are then examined further to determine a root cause. If multiple options exist for the root cause, the causing event with the highest weight or the closest in time is selected as the causing event. If the causing event is ticketable, a ticket is issued and the corresponding alarms are associated with the ticket.
Events, the AEC, and VNEs
Cisco ANA polls devices to discover changes in its network model, and generates internal events. External events (traps, syslogs) are treated as indications of faults that Cisco ANA confirms via expedited polling.
The AEC uses a high speed collector to obtain and receive traps and syslogs from network elements and distributes each event to the VNE that represents the device that sent it.
For each trap or syslog that it receives, the AEC creates a raw (unparsed) event. The AEC also stores each event from a managed element by sending the event to the event archive.
The AEC then sends the event to a shared buffer for forwarding to the appropriate VNE. If a high number of notifications arrive simultaneously, exceeding the per-VNE limit, the overflow notifications are directed to a burst buffer. The burst buffer operates on a first-come, first-served basis. If the burst buffer is full, any additional new events are dropped, and a system event is generated to inform the operator of this situation.
If required, you can configure the:
•
•
•
•
Upon receipt of the event, the VNE identifies the type of event and drops all nonactionable events.
Events that are dropped at this stage are not stored in the fault archive, and do not participate in correlation. Dropping events at this stage prevents Cisco ANA from being overwhelmed by large numbers of insignificant event notifications.
Pruning events older than three months in the event archive is handled by the Cisco ANA integrity process. For more information, see Integrity and Pruning Process.
Event Manager
When an event notification reaches the VNE, it is handled by the event manager. The event manager handles all network events, regardless of their detection method, such as polling, syslogs, traps, or threshold crossing alerts (TCAs).
If the VNE is in maintenance state, the VNE does not expedite events, but does respond to flows. Similarly, if a port is in disable alarm state, it does not expedite events but does respond to flows.
The event manager parses and persists the events as follows:
•
•
VNE and Fault Agent
The VNE sends a message to the fault agent with information about the correlation result, which is then updated in the event record.
As soon as the update message arrives, the fault agent determines if a new ticket should be created and, if so, creates one.
After the VNE completes the correlation for a flapping event or completes the handling for a clearing event, it sends an update to the fault agent, providing it with the following information:
•
•
•
•
•
This information is updated in the event record in the fault database. The concept of a preceding event boosts the association of the event with an alarm or ticket. If the event does not have a ConnectTo ID, the fault agent creates a ticket for it if it is defined as attention worthy.
Fault Agent
The fault agent runs in each Cisco ANA unit and is responsible for:
•
•
•
The fault agent is available as soon as its hosting AVM is up and recovers quickly if failover occurs in a high availability environment.
The fault database receives events in the following modes:
•
•
As soon as an event is persisted, it can be viewed in Cisco ANA EventVision.
Alarm Database
All events, alarms, and tickets that are not dropped after the identification phase, and the relationship between these items, are stored in the alarm database. The content of the database can be reviewed using Cisco ANA EventVision.
Events are stored in the form of a Cisco ANA event object. The original notification structure of incoming event notifications (trap or syslog) is not maintained.
Cisco ANA stores all event types, whether or not it recognizes them.
Statistics, such as how many events were persisted per second, how many tickets were created, and more, can be shown through the Report Manager in Cisco ANA Manage, Cisco ANA NetworkVision, and Cisco ANA EventVision.
If the fault agent fails for any reason, events that were waiting in its queue are lost and cannot be recovered.
The stored events might be marked as archived. Archived events are persisted in the fault database and can be viewed by using Cisco ANA EventVision.
An event is archived either because:
•
•
Northbound Integration Services
Cisco ANA supports notification services to both external OSS applications and northbound clients. Notification services are available for all event notifications for actionable and nonactionable events, as well as tickets and ticket updates.
NBI services are available for both:
•
•
Notifications are available in EPM-NOTIFICATION-MIB format only.
Note
See the Cisco Active Network Abstraction Integration Developer Guide for more information about:
•
•
Event Reporting
Cisco ANA includes Report Manager, a tool that enables you to produce and customize a variety of reports about events, traps, tickets, and syslogs. The standard event reports included with Cisco ANA enable you to view the:
•
•
•
•
•
•
•
•
•
The reports allow you to specify the time period and devices to be included, and provide output in a variety of output formats, such as XML, XLS, HTML, and PDF.
Report Manager is available in Cisco ANA Manage, Cisco ANA NetworkVision, and Cisco ANA EventVision. For information on the types of fault management reports available and how to create them, see the Cisco Active Network Abstraction 3.7 User Guide.
Database Management
Cisco ANA provides the following processes for managing the database:
•
Integrity and Pruning Process
The integrity and pruning process runs as a scheduled process in Cisco ANA and is responsible for:
•
•
•
You can control how long events, alarms, and tickets are kept before being pruned from the database. For more information about customizing fault behavior, see the Cisco Active Network Abstraction 3.7 Customization User Guide.
Database Size Maintenance
To prevent overflow in the database, Cisco ANA implements an automatic process that deletes old data. You can configure the period of time for which events should be maintained. The oldest time for which events should be maintained is the current time minus the event history size. Any event before this time will be deleted. For more information about customizing fault behavior, see the Cisco Active Network Abstraction 3.7 Customization User Guide.
