Differences Between Element and Service Instrumentation

A large installed base of element instrumentation already monitors infrastructure elements. These elements include servers, applications, switches, and databases. Monitoring service behavior requires different instrumentation approaches.

Technical managers have always relied on the instrumentation in various infrastructure elements for guidance. The instrumentation supplies management applications with information on element status, resource usage (CPU or bandwidth, for example), and errors. Instrumentation also generates real-time alerts when an element needs immediate attention from the management system. The management application processes the information and may initiate a set of responses depending on the results. The application displays the information for an administrator through a console or management portal, activates other management tools, and saves the information for further analysis.

Most organizations have already made substantial investments in element instrumentation and in the tools for collecting and analyzing the information that the tools provide. Administrators can monitor status, collect operational statistics, and receive real-time alarms when an element needs immediate attention.

Each element collects information about itself. The behavior of an individual element, however, may not have a direct impact on service behavior and quality. For example, the failure of an individual network element may have no impact on service quality when there is adequate redundancy and responsive dynamic routing. An element problem must be addressed and resolved by those responsible for managing it, but no problem has occurred from a service manager's perspective as long as the SLA metrics are in an acceptable range.

Element instrumentation is absolutely essential; unfortunately, however, it is insufficient for measuring service behaviors. A service behavior is determined by the aggregate behavior of the supporting infrastructures and their elements. Different instrumentation is needed to measure service behavior and to identify actual or potential service disruptions, which are inabilities to comply with an SLA. A disruption initiates a top-down process that first identifies the most likely infrastructure causing the disruption. Further analysis and measurement is needed to determine which elements are contributing to the problem.

Infrastructure administrators still must deal with an element failure because it is their responsibility to maintain high availability and redundancy within the infrastructure. They may prioritize their tasks based on service quality impacts, with those elements affecting critical services receiving attention first. Element management tools then are used to pinpoint the problem, take corrective actions, and verify that the element is operating properly. Finally, services instrumentation verifies that the service disruption has been resolved and eliminated.

Administrators also need information on infrastructure behavior and the correlation between services and infrastructure usage. They need to understand when element problems might affect their service quality. They also need to identify the elements associated with any given service when there is a disruption.

As shown in Figure 4-1, service instrumentation extends the discipline beyond monitoring individual elements. Elements are organized into infrastructures that are monitored as cohesive systems. Actual service behavior is measured across the appropriate infrastructures that support the associated activities. Examples of these service classes include interactive, streaming, and transaction.

Figure 4-1. Element and Service Instrumentation

Figure 4-1 shows the relationship between elements and service instrumentation. Service instrumentation must monitor and measure the overall behavior of the aggregate elements supporting any service flow.

Business managers also rely on real-time information to track business processes and goals. Technical information must be translated into business-centric metrics. A large transaction volume indicates high server performance, but this high volume may have no business value if the transactions are completing quickly because the desired content is missing.