Active monitoring refers to the process of monitoring a business function by performing one or more tests on important business flows that need to be watched.
These tests are performed periodically from strategic customer locations to monitor important business flows and are known as synthetic transactions. These are known as synthetic as they inject simulated load on the system for monitoring purposes.
Synthetic transactions are executed at regular intervals to evaluate the performance of various business flows. These transactions get executed even during periods of no load during a specific business function. For instance, in the case of the travel portal example, there could be periods of high load in flight search whereas there may not be enough load in the hotel search. During such periods, it is highly likely that certain metrics associated with the associated infrastructure may not even show any potential service disruption. To consider an example, during periods of low load, the throughput metric associated with the underlying application server may also show a very low value, making it difficult for the system administrator to determine if the throughput is indeed low due to low load or due to high latency in the application. Synthetic transactions are highly useful in such scenarios. As these transactions are run periodically, irrespective of the actual user load, it is possible to determine degradation in the business function by evaluating the performance of the synthetic transactions.
Passive monitoring techniques provide various metrics for the underlying IT
infrastructure that host various business flows and often make it harder to determine the performance of a specific business flow. In many cases, the synthetic transactions provide a direct indicator of the performance of the business function, which
otherwise would be difficult to measure. As the synthetic transactions are defined based on periodic tests on certain business functions, the response of the business flow to these regular tests indicates the performance of the actual business function itself. For example, performing a hotel search in a travel portal may involve multiple
Chapter 5
[ 171 ]
steps such as selection of the search criteria such as location, date, budget range, and so on, and then performing the actual search. The performance measurement of these different steps may not be straightforward. The average response time of the underlying application may provide the average of not just hotel search, but also other business flows. In such cases, performance measurement of the business service is simplified by evaluating the performance of certain focused synthetic transactions that target the business flow to be watched.
As discussed before, the passive monitoring techniques based on monitoring the system components in the IT infrastructure very often do not offer any insight into how the service is being experienced by different categories of users. If the customers access the application from multiple geographies, it may be necessary to monitor the perceived behavior of the business from strategic locations with a higher percentage of user population. For instance, before a holiday season in China, such as the Chinese New Year, it may be worthwhile to monitor the perceived user experience of the travel portal business flows from Beijing to ensure that key business flows are accessible despite an anticipated high load. Such a distinction is not possible by using passive monitoring techniques, as the metrics of the underlying IT infrastructure is a measure of the overall load, including other locations such as Tokyo and Singapore.
This can be easily achieved by monitoring the response of the business functions for various synthetic transactions executed from Beijing.
The availability and performance of the business functions can be modeled based on the availability and performance of various synthetic transactions, executed periodically from different strategic customer locations. This can be achieved by modeling the business functions as service targets based on service tests and beacons in OEM Grid Control. This chapter will provide detailed information on defining, modeling, and monitoring the various service targets using service tests and beacons.
Beacons
The Oracle Management Agent provides a small module named beacon that is capable of executing service tests that monitor important business flows
periodically. A beacon is an abstraction of a geographical location within an OEM Grid Control instance. In order to execute synthetic transactions periodically from any given geographical location, at least one beacon must be deployed there. An enterprise may opt to deploy a beacon in each of the strategic locations based on the geographical spread of the targeted customers. Beacons may be defined within or outside an enterprise network, provided the beacons can ping the targeted business service successfully.
In each of these strategic locations, an Oracle Management Agent must be installed and a beacon must be configured within the management agent. The Oracle Management Agent provides the following functionalities to the beacon module:
Lifecycle support: The agent provides all the lifecycle-related functions to the beacons such as creation of beacons, enabling, disabling, starting, and stopping the synthetic transactions, and so on.
Configuration: The agent provides a uniform means of configuring different types of synthetic transactions for different beacons. The configurations include the various parameters such as login credentials, business service details, the test execution frequency, and so on.
Metric collection: The agent also offers a uniform channel to collect and upload metrics for various synthetic transactions. The performance metrics associated with each execution of synthetic transactions are uploaded like any other metric to the Oracle Management Server.
Self-monitoring: The agent also monitors the beacon module as a target.
This is to facilitate the monitoring or self-monitoring requirement. By modeling the beacon itself as a target, the administrators can be notified of any downtime of the beacon and there by warned of potential disruption in active monitoring from a specific location.
Even though OEM Grid Control supports the definition of multiple beacons within the same Oracle Management Agent, for better performance it would be prudent to limit one beacon per agent.
Just as the same enterprise may provide different business functions to the customers in a single location, a beacon is capable of monitoring multiple business services by executing various synthetic transactions. A beacon within OEM Grid Control supports execution of multiple synthetic transactions to model the same business service. For instance, for the flight reservation business function within the travel portal example, the beacon may execute multiple synthetic transactions such as flight search and flight reservation. Beacons also support execution of different transactions to model multiple business services. For example, the same beacon can execute different transactions periodically to monitor a flight reservation business service and a hotel reservation business service independently.
Beacons provide isolation of each of the synthetic transactions. The various synthetic transactions configured within execute independent of each other. The frequency of execution of each of the synthetic transaction can be configured separately. Similarly, the performance metrics of each of these synthetic transactions are also collected independent of each other.
•
•
•
•
Chapter 5
[ 173 ]
As discussed before, it is possible to have different synthetic transactions from multiple locations monitor the same business service. The response from each of these locations is a measure of the real end user experience at those places. As discussed in Chapter 4, Modeling Services, even though there can be multiple beacons in various geographical locations monitoring the same business service, not all beacons may participate in the availability definition. It is quite possible that certain beacons are deployed in locations of less customer concentration for additional monitoring. Those beacons that represent important locations from a business-centric view to define the availability of the business service that is monitored are called key beacons. Synthetic transactions from the key beacons are used only in the availability computation of the associated business target.
As discussed, the same beacon may execute different synthetic transactions to monitor different business services. Hence, the same beacon may act as a key beacon for one service target based on strategic importance of the business function and act as a non-key beacon for another service target.
The following image illustrates the concept of executing synthetic transactions from beacons within an Oracle Management Agent:
The previous image is an illustration of two different beacons deployed in locations Tokyo and New York respectively. These beacons are deployed within the
respective Oracle Management Agent installations in the corresponding locations.
Each of these beacons executes different synthetic transactions such as Flight Search and Hotel Search to monitor the respective business services. The beacons execute the synthetic transactions and use the metric upload mechanism supported by the agent to report availability and performance information to the Oracle Management Server.
As discussed, each beacon within an agent is modeled as a target within OEM Grid Control. The list of all beacons associated with an agent can be viewed in the Monitored Targets region within an Agent Target Home Page.