When you create applications and transactions on the NAM Server, you organize the monitored data according to a higher level of abstraction. You apply a business view to the data technically divided into tiers and services. After creating applications and transactions, you are able to use dedicated reports to supervise your strategic application performance.
This step is mandatory only if you integrate NAM Server data into BSM. For other product configurations, your system will work without applications being defined. However, if you want to obtain a less technical view and go beyond simple network performance monitoring you should consider performing this part of the configuration.
Applications and transactions defined on the NAM Server are based on and represent your own view of the monitored subjects. The rules are based on the logic imposed by the individual who configures the NAM Server. These rules are meant to represent an actual software organization running on a web server and the relations between its components.
Applications, transactions, and tiers
An application is a universal container that can accommodate transactions. Each application can contain one or more transactions; those transactions can originate from different sources. An application defined on the NAM Server is a cohesive container that helps you organize information about the application delivery chain.
Applications organize the data traveling through your network into logical units or tasks. These tasks are performed over the network. You can distinguish each web application running on a single web server.
A transaction consists of operations that are grouped as steps. Transactions are built out of a single step or a number of steps. For example:
- A simple, single-step transaction may consist of a single operation such as a web page load.
- An extended transaction may consist of a collection of non-sequenced operations (an unstructured transaction).
- A more complex transaction may consist of sequences of operations, each operation being a single step. NAM monitors sequences of web page loads and sequences of XML calls, and it reports on these sequences (as transactions) and on individual operations within sequences.
A transaction defines a logical business goal such as registration in an online store. One or more transactions constitute an application. Note that a transaction can have only one parent application.
Data for a transaction can come from:
- NAM Probe
- Enterprise Synthetic agent
The same transaction can contain data from different data sources at the same time (for example, data from NAM Probe and from Enterprise Synthetic). However, metrics for each data source are aggregated separately.
A tier is a logical application layer. It is a representation of a fragment of your monitored environment.
The front-end tier in a user-defined configuration is the layer that is closest to the end user.
How tiers, transactions and applications are related
Each application is defined as a set of transactions and can be divided into logical layers (tiers) such as web servers, middleware, or a database.
Each transaction can be a collection of data gathered across various tiers, as shown in the following figure.
This picture shows some transactions spanning three tiers:
Each transaction can be a collection of operations occurring within one tier.
Each tier is defined as a set of rules dependent on the tier type.
All tiers are defined globally. The global definition applied to a specific application shows the appropriate sequence of tiers for that application.
Multi-level hierarchy reporting
Business-critical applications or advanced Web applications that support core business processes typically have complex multi-level structures of business-related transactions, tasks, steps, processes, and operations. NAM provides data organization for reports that reflect the business structure of the monitored application. The service-module-task-operation hierarchy provides technical performance information.
For some analyzers, for example SOAP, operations hierarchy is inherent. NAM Server reports organize data in a clear manner making fault domain isolation easy. The hierarchy levels are automatically reported by the NAM Probe (for example, for HTTP or SOAP), or configured on the report server (for example, for SAP).
Operations performed by monitored applications are grouped and presented according to a certain pattern. Hierarchy levels above single operations are containers for the lower-level entities. You can group smaller (but numerous) items and limit the data you observe on reports. You can use this hierarchy model, with a business perspective (applications and transactions), to create greater logical compounds that reflect part or all of your monitored environment.
The analyzer type determines if the NAM Server can provide data for hierarchy levels. Some analyzers provide only one or two levels or none at all. The NAM Server can report on up to four levels for the following traffic types:
Each level is reported independently or combined with the other levels. You can use DMI to create reports with entries from arbitrarily chosen hierarchy levels like display metrics for level-one entries paired with their level-three entries.
In the current NAM release, the following hierarchy levels are supported:
Operation (id: pUrl)
For HTTP, this is the URL of the base page to which the hit belongs. For other analyzers this can be a query, operation type or an operation status. Operation is ascertained by the NAM Probe, based on referrer, timing relations between hits and per-transaction monitoring configured on the NAM Probe. This dimension can assume values of a particular operation - if this operation is monitored. Note: The visibility of this dimension on reports depends on whether another dimension, related to servers - e.g. server IP or server DNS - has been used when formulating the query.
The All other operations record serves a catch-all net for al the traffic that has been seen to-from a server, but was not classified as belonging to a specific monitored-by-name operation. It accounts for statistics of:
operations which were not reported in per specific operation records (for example those that fall out of topN reported operations for a specific analyzer) - in such case the number of operations and slow operations, as well as operation time and other transactional statistics will be reported as an aggregate/average;
traffic which was not classified to any operations (for example, idle TCP session closure, TCP handshake without any operation, etc) - in such case only volumetric statistics (bytes, packets) will be reported for this specific traffic.
Task (id: pUrlURLHierarchyLvl1)
Task is the second level in the reporting hierarchy. For example, in HTTP monitoring this is the page name; in database monitoring this is the operation name (may contain regular expression if configured on the NAM Probe) or operation type prefix, and in SOAP monitoring this is the SOAP method. This entity can be broken to smaller bits such as operations or operation types.
Module (id: pUrlURLHierarchyLvl2)
Module is the third level in the reporting hierarchy. For example, in database monitoring this is the database name, and in SOAP monitoring this is the SOAP service. This entity can be broken to smaller bits such as tasks.
Service (id: pUrlURLHierarchyLvl3)
Service is the highest level of multi-level reporting hierarchy. For example, in SAP GUI monitoring this is the business process. This entity can be broken to smaller bits such as modules.
Reporting hierarchy in NAM
Table 1. Hierarchy Levels for Selected Analyzer Groups
|Level||HTTP Analyzer group||SOAP Analyzer group||SAP Analyzer group||Database Analyzer group||SMB Analyzer group||Visibility|
|Service||—||—||Business process||—||Server name||NAM Server|
|Module||—||SOAP Service||Process step||Database name||Share name||NAM Server|
|Task||Page name (for NAM data)||SOAP Method||Process step||Operation name (with optional regular expression) or operation type prefix||Folder path||NAM Server|
|Operation||URL||SOAP call||Object (T-Code and operation status)||SQL command||Read Write Control||NAM Server|
|Hits||Hits, pages, transactions||Operation, transaction||Operation, window name, window status||Full query||N/A||ADS|
Applies to DC RUM 2017
In addition to NAM Server, ADS shows non-aggregated data, exact time stamps, and one entity per record. Note that ADS does not support the hierarchy itself. Any entity other than operation is ignored.
“All Other” aggregate
The “All other” aggregate appears on reports in places where no named entity for the given level is found. This information is either derived from the NAM Probe configuration or reflects the specifics of monitored protocols. For example, in HTTP monitoring all levels above task are aggregated as “All other” module and service, because they do not exist within the current model.
Hierarchy on reports
The reports are available from the Reports menu. They provide a unified way of representing the hierarchy of measured entities. Section tabs represent the hierarchy levels. You can switch perspective and verify the data either up the hierarchy or down.
To obtain performance information on the hierarchy levels start from the Tiers or Software services report, go down to the Servers report, then view the Operations report for the given server or all servers within a tier.
View all or selected hierarchy levels with the following reports:
Use the Operations report, to display data for selected or all software services. You can analyze how the top of the hierarchy is affected by certain operations, software service, and servers.
Hierarchy levels for database monitoring
There are three levels of reporting hierarchy for database monitoring:
Operations: Queries or procedure calls
Tasks: Query names, query names plus regular expression set on the NAM Probe, or operation type prefixes.
Module: The database name is reported as module.
Some hierarchy levels may not be reported because of database monitoring configuration settings. You may see missing database name, operation name, or query. The following are scenarios:
- Missing database name:
(Module) *All other* (Task) *Operation name + regex* (Operation) *SQL command*
Occurs when the database name monitoring is not configured or the NAM Probe is unable to report the database name because it cannot detect the beginning of the session.
- Missing operation name (with regular expression):
(Module) *Database name* (Task) *SQL command* (Operation) *SQL command*
Occurs when you configure the NAM Probe to monitor individual queries, and you choose exact queries as a configuration rule but do not set names for queries.
- Missing database name and missing operation name (with regular expression):
(Module) *All other* (Task) *All other* (Operation) *SQL command*
Occurs when the NAM Probe does not report the database name and the operation name reporting is not configured.
- Missing operation name (with regular expression) and missing query:
(Module) *Database name* (Task) *Operation type prefix* (Operation) –
Occurs when an operation other than query or RPC (for example, login or logout) is recorded by the NAM Probe.
- Missing operation name (with regular expression), missing query and missing database:
(Module) *All other* (Task) *Operation type prefix* (Operation) –
Occurs when database name recognition is not configured or it is not seen in the traffic; plus the operation is not a query or an RPC.
If you want to remove these limitations, fine-tune the monitoring settings using the NAM Console.
Hierarchy levels for SAP monitoring
The SAP reporting hierarchy is imported from a configuration file that is generated on SAP Solution Manager. Use this file to couple the NAM reporting hierarchy tightly with the SAP application business hierarchy.
Hierarchy levels for SMB monitoring
There are four levels of reporting hierarchy for SMB monitoring. Levels of the hierarchy are mapped as following:
Services: Server name
Module: Share name
Task: Folder path
Operations: limited to Read, Write and Control
The Operation name is identified by the SMB action performed, Service, module and task (
performed action: \\Service\Module\Task). For example: