The following illustration depicts the basic TrueSight Operations Management deployment with TrueSight App Visibility Manager and TrueSight Infrastructure Management providing data to the Presentation Server. With both data providers, all functionality is enabled. This deployment illustration does not cover all possible integrations.
All TrueSight Operations Management deployments require the following products or components:
|Product or component||Function|
|Atrium Single Sign-On and the TrueSight SSO Admin Console|
Deploy TrueSight Single Sign-On for user and tenant management and for authentication to the TrueSight console.
Note: TrueSight Single Sign-on can be installed on the same server with the TrueSight Presentation Server if necessary.
For information about deploying TrueSight Single Sign-On, see .
|TrueSight Presentation Server and the TrueSight console|
Deploy a single Presentation Server to present data from the data providers. The TrueSight console hosted on the Presentation Server provides monitoring functions, role-based access control, solution administration, and configuration for TrueSight App Visibility Manager, a BMC Synthetic Transaction Execution Adapter Agent (TEA) Agent, and TrueSight Infrastructure Management.
Best practice: Install the Presentation Server separately from the Infrastructure Management Server.
For details about the TrueSight console and the Presentation Server, see.
When both TrueSight App Visibility and TrueSight Infrastructure Management are installed, the App Visibility portal can be connected to the Infrastructure Management Server Cell or a Remote Cell. For instructions, see Adding and editing components.
The following illustration shows a basic deployment using only Infrastructure Management as the data provider. By installing Infrastructure Management, you enable event management for automating the detection and resolution of IT problems through correlation and prioritization of events. Before deploying Infrastructure Management, you must size your environment to determine the number of servers required to support the events and performance data received from your monitors. For complete information about deployment options and for best practices for deploying these components, see Planning the Infrastructure Management deployment.
To enable TrueSight Infrastructure Management as a data provider, deploy the following components:
|Product or component||Function|
|TrueSight Infrastructure Management Server and Infrastructure Management console|
Deploy a TrueSight Infrastructure Management Server to collect and compute information related to events, performance, services, and applications. The Infrastructure Management Server hosts the Infrastructure Management operator console, the Infrastructure Management administrator console, and the Infrastructure Management Service Level Object (SLO) console. The Infrastructure Management Server requires a database, either the locally embedded Sybase database or a remote Oracle database. For more information about deploying Infrastructure Management, see Deployment use cases and best practices for Infrastructure Management. For multiple tenants, see Service provider and tenant deployment for TrueSight Operations Management.
|(Optional) Atrium CMDB and the BMC CMDB Extensions|
|(Optional) Event Enrichment Cell (Remote Cell)|
Installed separately from the TrueSight Infrastructure Management Server, a Remote Cell functions as part of a larger distributed network of cells that pre-process and propagate events to the TrueSight Infrastructure Management Server Cell. You can install the Remote Cell on its own host or an Integration Service host. Networks of Remote Cells can be organized to serve any business hierarchy (such as geographical, functional, or organizational) or configured to meet technical issues (such as network or system limitations). You can configure a Remote Cell for high availability by configuring a primary cell server and a secondary cell on a separate server to be used for failover if the primary cell server fails.
If service impact management is implemented, the Remote Cell can also associate events with service model components and calculate the components’ statuses. If service impact management is not implemented, then the cell is simply an event management cell.
|Infrastructure Management Integration Service host|
A single Integration Service host is required for managing events from event sources such as PATROL Agents, event adapters, and SNMP traps, and for forwarding performance data to the Infrastructure Management Server.
For more information, see .
|PATROL Agents and monitoring solutions|
PATROL Agents collect performance data and generate events for availability metrics. Monitoring solutions consist of one or more knowledge modules (KMs). (A KM is a set of instructions that the PATROL Agent uses to monitor objects in your environment.) For a list of Knowledge Modules supported with the current version of Infrastructure Management, see List of Monitoring Solutions and KMs in Infrastructure Management.
Determine what will be monitored in the environment and how that data will be used. Specifically identify from which systems, applications, and components in your environment you need performance metrics (and historic trend data), and from which components you need events and alerts. Next, determine the location of all PATROL Agents and the respective Integration Services. At least one Integration Service should exist for each secure network zone, and generally the Integration Service must be closer to the PATROL Agents connecting to it. This requirement minimizes the number of connections to the Infrastructure Management Server and makes firewall management easier because there is one connection per Integration Service. For additional details, see the following topics:
You configure PATROL Agents from the TrueSight console. The configuration information is sent to the PATROL Agent through the Infrastructure Management Server and the Integration Service following the same path and ports that data flows up through.
For information about deploying the PATROL Agent, see and .
|Transaction response time and third-party transaction monitors|
User transaction monitors collect performance data, such as response time, for web applications and web pages. Third party data adapters provide a mechanism for external applications to feed data into Infrastructure Management. Data adapters facilitate the synchronization of performance data collected by specific monitoring solutions into Infrastructure Management for further analysis.
The following illustration shows a basic deployment using App Visibility Manager as the data provider. By installing App Visibility Monitoring, you enable application performance monitoring and diagnostics and the ability to automatically generate application models.
Typically, the App Visibility environment uses separate computers for the portal, one or more collectors, and one or more proxies. You can install the App Visibility Server components on a single computer for a small environment, or you can deploy several App Visibility collector components over separate computers. For further information, see Sizing App Visibility Manager and Synthetic TEA Agent components.
|Product or component||Function|
|App Visibility server|
The App Visibility server comprises the following components:
The server receives and analyzes data from the end user's browser, from the App Visibility agents for Java and .NET that are installed on web application servers, and from the synthetic Transaction Execution Adapter (TEA) Agent.
|App Visibility portal|
One App Visibility portal manages App Visibility collectors, App Visibility proxies, and App Visibility agents. The portal communicates with the associated App Visibility collectors to gather the data to be sent to the Presentation Server and viewed in the TrueSight console. App Visibility agents and App Visibility proxies request configuration information from the App Visibility portal, including which collector to send data.
A maximum of one App Visibility portal can be assigned to BmcRealm or a tenant. For multiple tenants, see Service provider and tenant deployment for TrueSight Operations Management.
|App Visibility collectors|
An App Visibility collector receives and stores the information for the application that is monitored by the App Visibility agent. Each App Visibility collector has its own database, where all information is saved. For each proxy, you can connect from one to five App Visibility collectors. Install multiple collectors on separate host computers to support the agents.
|App Visibility agents|
Install App Visibility agents on each application server hosting the application that you want to monitor, such as an IBM WebSphere or Microsoft Internet Information Service (IIS) for Windows application server. An App Visibility agent captures a sample of the transactions that have latency violations or errors. The captured data and the metrics data for the application server are sent to the App Visibility collector. Each App Visibility agent is paired with an App Visibility collector.
The following agents are available:
|(Optional) App Visibility proxies|
The App Visibility proxy must be able to receive the beacons that contain the end-user metrics and attributes about application performance, which are sent from the end user's browser. For guidelines to help you plan the installation of the App Visibility proxy, see 753801149.
The following illustration shows a basic deployment using App Visibility Manager and TrueSight Synthetic Monitor as data providers. By installing TrueSight Synthetic Monitor and the Synthetic TEA Agent, you enable synthetic transaction monitoring to predict application health and performance.
Operations Management with App Visibility Manager and TrueSight Synthetic Monitor
To enable TrueSight Synthetic Monitor as a data provider, deploy the following components:
|Product or component||Function|
|TrueSight Synthetic Monitor with Silk Performer|
The Silk Performer utility is used to record or author .ltz scripts that simulate user transactions. The scripting utility also serves as an execution module to run scripts on the computer with the Synthetic Transaction Execution Adapter (TEA) Agent. On each TEA Agent computer, you can install the full Silk Performer installation or a smaller agent installation.
Synthetic Transaction Execution Adapter (TEA) Agent
The TEA Agent runs the scripts that generate synthetic transactions for monitoring and predicting application performance. The TEA agent transfers the synthetic data to the App Visibility portal. Install the agent on a computer that simulates an end user accessing the application that you are testing. The TEA Agent monitors the results received or experienced by the synthetic end user. This is unlike the App Visibility agents that directly monitor the application.
Operations Management with TrueSight Synthetic Monitor only
You can add one or more load balancing servers or reverse proxy servers to your system for added stability and security. Load balancing servers control which App Visibility collector is assigned to a particular App Visibility agent, while a reverse proxy server adds a layer of security for the App Visibility server. App Visibility requires an OSI Layer-4 load balancer with a dedicated Virtual IP for the host name used for App Visibility proxy beacons, or a Layer-7 load balancer that can make routing decisions based on the Host header.
Operations Management with App Visibility Manager and TrueSight Synthetic Monitor using reverse proxy or load balancing servers
Your environment setup affects where you install the App Visibility proxy in your network and how you facilitate the successful delivery of beacons. The App Visibility proxy can operate in an environment where both a load balancer and router lie between the beacon's origin (end user’s browser) and the beacon’s destination – the App Visibility proxy. To ensure that the beacon arrives at the App Visibility proxy unmodified, TCP-termination devices that lie between the origin and destination must support the following requirements:
The beacon is sent as an HTTP POST. The POST DATA, which is in the body of the request, must not be altered or truncated.
The HTTP payload of the beacon must never be modified. Any cookies, headers, or POST contents must not be stripped out.
The beacon must be redirected to the App Visibility proxy. The TCP ports used between the end user and the network terminating device are not important; however, the networking device needs to forward the beacon to the appropriate port on the App Visibility proxy. This port is set during installation of the App Visibility proxy.
When the App Visibility proxy is behind a load balancing server and not receiving connections directly from end-user browsers, update the value of the App Visibility proxy callback.address property. The property value must be the host name or IP address of the load balancing server. For instructions, see Changing App Visibility proxy settings.
App Visibility's end-user experience data collection works with networking equipment as long as it does not manipulate the HTTP payload. Networking equipment, such as load balancers and routers, must intercept the network connection (OSI Layer 4) and forward it as-is to the intended destination with no impact to the HTTP payload (OSI Layer 7). As long as the load balancers are configured to allow the beacons through with no changes to the existing HTTP data, the App Visibility proxy can process the beacon.
App Visibility uses HttpOnly cookies if the application or application server supports Servlet 3.0, or later. The cookie, used only by TrueSight to identify unique users, is managed as an independent user tracking mechanism, with no correlation to any similar mechanisms managed by the application or application server, such as sessions in the monitored application.
For more information about hardware and software system requirements for App Visibility components, see System requirements for App Visibility Manager.
Consider the following options for deployment of the App Visibility proxy.
Option 1: App Visibility proxy on network
BMC recommends this use case in nonproduction environments or for internal-user applications only.
In this use case, install the App Visibility proxy when installing the App Visibility server. The host name of the App Visibility server becomes the host name portion of the URL injected by the App Visibility agent. Before installing the App Visibility proxy, ensure that you have addressed the following requirements:
Option 2: App Visibility proxy deployed behind a load balancer
BMC recommends this use case when monitoring large-scale production web applications, and includes a router or other network equipment that terminates TCP connections.
BMC tested this use case with a load balancer, the most common type of network equipment that terminates a TCP connection. Any system or device that functions in a similar manner (such as a reverse-proxy) should also work, provided that it does not modify the HTTP payload.
Because the injection of code that calculates performance metrics must occur at the origin, performance monitoring is not available for web pages that are cached by a Content Delivery Network (CDN). However, performance monitoring is available for pages whose page container is called from the origin (or proxies), but the static components of the page are cached, and will still work.
The following illustration shows a basic deployment using Real End User Experience Monitoring Software Edition. By installing end-user monitoring, you enable end user-centric performance monitoring that helps IT ensure the quality and availability of web-based applications, determine whether applications meet service-level objectives, and proactively find and fix problems.
To enable Real End User Experience Monitoring Software Edition as a data provider, deploy the following components.
|Product or component||Function|
The Cloud Probe sends information through the Real User Collector on a BMC Real End User Experience Monitoring system.
By deploying a Cloud Probe, BMC Real End User Experience Monitoring can monitor applications that are deployed in a public cloud environment, such as Amazon EC2, a private data center, or a hybrid deployment.
The Cloud Probe sends information through the Real User Collector. You must plan your distribution to the Real User Collector and Real User Cloud Probes, so that you know to which Real User Collector you will connect each Cloud Probe. The Cloud Probe service can capture HTTP or HTTPS traffic destined for the system on which it is hosted; it cannot capture traffic going out of the system.
Real User Collector
A Real User Collector captures traffic data from a tapping point between the application and the end user (for example, a network tap or a mirror port on a network switch) and makes it available to a Real User Analyzer.
A Collector is responsible for deciphering encrypted traffic in a secure way and applying rules to protect the confidentiality of application end users. It also has controls for managing a portion of its functionality.
Every BMC Real End User Experience Monitoring system must have at least one Collector component.
|Real User Analyzer|
The Analyzer organizes traffic data acquired from the Real User Collector component into segments, processes it, and provides usable information.
Every BMC Real End User Experience Monitoring system must have at least one Analyzer component.
For additional deployment scenarios, see Deployment options for Operations Management.
To size your environment and review the system requirements, see Planning.