Registering Applications
Of course, the applications monitored by an APM agent need to be registered so they can be identified unambiguously. Rather than invent a new mechanism, one was "borrowed" from the RMON2 MIB, which created a mechanism to register protocols. APM agents use RMON2's protocolDirectory to register those application protocols they can measure. There is no requirement, however, for an APM agent to implement any other part of the RMON or RMON2 MIBs.
APM MIB Reports
An APM agent measures every transaction it sees but does not report every transaction to the management station, because too much network bandwidth would be used. To manage this data more efficiently, APM agents statistically summarize these measurements into reports. The management station can specify the desired frequency of reports, as well as the desired granularity of each report.
A summary report is created once every reporting period. Each report comprises a number of records, each one summarizing a number of actual transactions. Each record contains:
» TransactionCount: The total number of transactions during this period.
» SuccessfulTransactions: The total number of successful transactions.
» ResponsivenessMean: The average of the responsiveness metric for all summarized successful transactions.
» ResponsivenessMin: The minimum responsiveness metric for all summarized successful transactions.
» ResponsivenessMax: The maximum responsiveness metric for all summarized successful transactions.
» ResponsivenessB1 - ResponsivenessB7: A set of "buckets," each of which contains the count of successful transactions whose responsiveness metric falls into a range specified for each bucket. The collection of a histogram in these seven buckets is very helpful because of the nature of responsiveness data in a network. For example, a transaction run over modems may take an average of 60 seconds, while the same transaction over a local LAN may take an average of three seconds. The APM MIB lets the management station configure the bucket boundaries for each set of circumstances.
For example, if from 9 to 10 a.m., an APM agent detected 1,806 transactions, those transactions might be summarized by application in three records. The management station would then be able to download the set of records shown in "APM MIB Summary."
Notice how the histogram can point out the large number of SAP/R3 transactions that are taking more than two minutes to execute, a fact obscured by a simple average. In this example, the bucket boundaries are equal for each application, but the management station has the ability to set them individually. This would let the bucket boundaries be skewed lower for HTTP transactions and higher for SAP/R3 transactions, so each can receive more precision in the range where its results usually fall.
The next step is to see the various ways we might organize an aggregation. The APM MIB provides four kinds of aggregation:
» Application based: An application-based aggregation compares the relative performance of various applications. This is the highest level of aggregation (in other words, it results in the fewest number of records). It can be a first line of defense, as it can show which application is experiencing trouble, suggesting further drill-down on that application.
» Server based: A server-based aggregation compares the relative performance of servers. If many transactions to a particular server are experiencing poor performance while other servers continue to see good performance, it is immediately apparent that the problem is isolated to that one server, saving diagnostic time.
» Client based: A client-based aggregation compares the relative performance of each client. If a user calls a helpdesk complaining of poor performance, this summary report can be used to verify instantly the performance seen by that user, so it can be compared with baseline performance or the performance seen by others.
» Flow based: The flow-based aggregation results in the largest number of individual records. A record is created for each distinct combination of application, client and server seen by an APM agent. Each record will aggregate all transactions seen for a particular application/client/server combination over a particular reporting interval.
Keep in mind that the management station is free to perform additional aggregations once the records are downloaded from the APM agent. These aggregation techniques are limited only by the ingenuity of the management-station vendor, but a couple of important techniques deserve mention:
» Geographic: A valuable and popular technique is to aggregate clients by geographic location. The most direct way to do this is to start with a client-based aggregation and, using knowledge of which desktops are in which offices, combine all records in each office. The resulting report can show which offices are experiencing poor performance -- a key signal that the network to that office may be congested.
» Media type: Grouping clients by the access technology they are using could be helpful -- for example, LAN versus WAN versus dial-up. Dial-up users will naturally receive poorer performance than LAN clients receive; this technique lets the IT manager focus attention on getting the best performance for users of each media type.
These aggregations cannot be performed by the APM agent, because the agent doesn't have all the information required (such as the office-by-office subnet allocation scheme).
Putting APM Reports to Use
To get APM measurements from an APM MIB agent, the management station creates one or more regular reports by specifying what to monitor, the reporting interval, the desired aggregation, the maximum size of each report and the number of reports to save. The agent then measures transactions and creates reports. The management station can download all reports or individual reports as needed.
Near-real-time reporting is also possible through this interface simply by reducing the reporting interval. Report intervals of 60 seconds or less certainly have the potential to use more resources, but you should consider this technique when each report has few records.
RSS
