Table of Contents

Understanding Processing Framework

Understanding Processing Framework

This appendix provides SLM processing information and data calculations. This appendix contains:

• Overview
  
  
• Round-Trip Latency Computation
  
  
• Availability Computation
  
  
• Mean Time To Repair (MTTR) Computation
  
  
• Mean Time Between Failures (MTBF) Computation
  
  

Note   SLM is not a performance monitoring tool. Therefore, raw data is cached for only a short period of time. After the raw data is aggregated and included in report information, it is then discarded.

Overview

The SLM application processes SLC and SLA configuration and data. This includes the distributed data collection component in the Management Engine 1100 (ME 1100) Series. An SLC containing at least one SLA is defined using the SLM administrative GUI framework, which then sends the SLC/SLA in XML format via HTTP to the SLM server. The SLM server stores this configuration, generates the appropriate ME 1100 Series requests in XML format, then determines which ME 1100 Series (if more than one is configured on a network) should receive the request using HTTP.

Note   An SLC might not generate any request to an ME 1100 Series if similar SLCs already exist within the SLM server. Although SLCs must be unique across SLM, the same device pairs can be included in several SLCs. As a result, like device pairs share the same request identification number.

When the ME 1100 Series receives the request, it uses SNMP to configure the device by setting the MIB variables in the CISCO-RTTMON-MIB. The ME 1100 Series takes a high-level XML request and translates that into SNMP operations required to set up the specified Service Assurance Agent (SA Agent) operation. The ME 1100 Series also initiates a scheduled data retrieval routine to collect SA Agent operation data from the device.

When you create an SLC/SLA, the SA Agent operation required for this monitoring is set up in the source device, and test operations are performed from source device to target device. The SA Agent in the source device stores the test operation results in the MIB tables. Different MIB tables are used for different types of SA Agent operations.

The SA Agent stores detailed test results for ICMP echo, UDP echo, and DNS SLAs in the rttMonHistoryCollectionTable MIB table. For HTTP and VoIP, the results are not as detailed; only hourly totals are stored in rttMonHTTPStatsTable and rttMonJitterStatsTable tables respectively.

The ME 1100 Series periodically retrieves the data. All MIB data retrieved from the source device is stored in an embedded database on the ME. If the data comes from the rttMonHistoryCollectionTable and the interval is less than 5 minutes, the data is first aggregated into 5-minute averages before being stored in the database. This data is then retrieved and further processed and stored in the SLM database by the SLM server process.

Process data is stored in aggregated, hourly, daily, or monthly groups. Aggregated is the most detailed, which, in time, is processed then moved to the hourly group, the daily group, and finally the monthly group.

After trending the data from group to group, the SLM Server process deletes older data to maintain the database from growing indefinitely. Aggregated data is stored for 2 days. Hourly data is stored for 31 days. Daily data is stored for 1 year, and monthly data is stored for 2 years.

After the data is persisted to the database, SLM reports can be generated, which can take 2-3 hours from the time the SLC/SLA was initially set up. The SLM reports are generated by Java servlets, that calculate thresholds as well as MTBF and MTTR. Only data values within the specified apply time are used to calculate threshold exceptions.

Reports for the current day, month, and year are generated dynamically, but static reports—prior day, prior month, or prior year—are only generated once and then cached.

Round-Trip Latency Computation

For ICMP echo, UDP echo, and DNS, these values are directly retrieved from the MIB value for rttMonHistoryCollectionTable table. The MIB is rttMonHistoryCollectionCompletionTime. When aggregation is needed, the average sample value is used.

For HTTP, the value is calculated from the following MIB values in the rttMonHTTPStatsTable.

Note   The values retrieved from the MIB are hourly totals. The hour range does not necessarily correspond with the hourly clock boundary. The hour range begins when the SA Agent operation is set up and ends 60 minutes from that time.

Table B-1 displays HTTP calculations.

For VoIP, the MIB values from the rttMonJitterStatsTable are also in hourly totals and have the same hourly range definition as the HTTP SA Agent operation.

Table B-2 displays VoIP calculations.

Availability Computation

Availability calculations are only performed for ICMP echo, UDP echo, and DNS SLAs. The two types of availability noted are device and link. Device availability (or reachability) refers to the source device. If the target device is unreachable from either a network path issue of disruption of service within the target device, that is counted as Link availability.

• Device availability is calculated by the ME 1100 Series using an internal periodic connectivity timestamp to the source sysUpTime.
  
  
• Link availability is computed using the rttMonHistory table MIB variable, rttMonHistoryCollectionSense.
  
  

For ICMP echo and UPD echo, rttMonHistoryCollectionSense values associated with link down errors are:

• disconnected (2)
  
  
• timeout (4)
  
  
• notConnected (6)
  
  

For DNS, rttMonHistoryCollectionSense values associated with link down errors are:

• disconnected (2)
  
  
• timeout (4)
  
  
• notConnected (6)
  
  
• dnsServerTimeout (11)
  
  

Mean Time To Repair (MTTR) Computation

MTTR is calculated in SLM as average downtime in minutes or hours for the applied time period. From the aggregated operation data, a table is created containing device and link uptime and downtime events. Since data is collected at intervals, the sampling granularity specified by the user affects the uptime and downtime recordings for link events.

For example, if samples are collected every 30 minutes, then the link uptime and downtime might be off by as much as 29 minutes from the actual event. Device uptime and downtime event calculations use the sysUpTime of the source device and the periodic communication timestamp from the ME 1100 Series to the source device. The default ME 1100 Series to source device interval is 30 minutes, which means that the accuracy of device uptime and downtime events is within 30 minutes.

MTTR is calculated as follows:

• M = number of down signals in the applied time period.
  
  
• T₁Up = time of applied period start.
  
  
• T₁Down = time of period end if there were no down signals in the applied time period (for example, the link or device was up the entire period).
  
  

If M = 0, MTTR = Not Applicable.

For i = 1 to M, MTTR =

(T_i+₁Up - T_iDown) / M.

Where:

• T_iUp = the time at which the _ith Up event in the period was recorded.
  
  
• T_iDown = the time at which the _ith Down event in the period was recorded.
  
  

Mean Time Between Failures (MTBF) Computation

MTBF is calculated in SLM as average uptime in hours or days for the time period shown. One day = 24 hours, even though the applied time period might be less. Down events that occurred outside the applied time are not included in the calculations.

MTBF is calculated as follows:

• N = number of non-zero uptime periods in the time period (for example,
  N = the number of times that T_iDown j T_iUp > 0.
  
  
• T₁Up = time of applied period start.
  
  
• T₁Down = time of period end if there were no down signals in the applied time period (for example, the link or device was up the entire period).
  
  
• For i = 1 to N, MTBF =
  
  (T_iDown - T_iUp) / N.