Basic deployment options for TrueSight Operations Management

Based on your business and monitoring information needs and your license entitlements, deploy TrueSight Operations Management with one or more component products. Review the basic deployment use cases in this topic to understand the products and components required to provide the data that enables functionality in TrueSight Operations Management.

You can also deploy TrueSight Operations Management with additional integrations, to ensure high availability, to enable disaster recovery, and to enable use by multiple tenants.

TrueSight Operations Management basic deployment with all data providers

The following illustration depicts the basic TrueSight Operations Management deployment with TrueSight App Visibility Manager and TrueSight Infrastructure Management providing data to the TrueSight 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:

When both TrueSight App Visibility Manager 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.

Note

For a proof-of-concept deployment, see Guidelines for installing on a single computer in the Installation-process-overview.

TrueSight Operations Management basic deployment with TrueSight Infrastructure Management only

The following illustration shows a basic deployment using only TrueSight Infrastructure Management as the data provider. By installing TrueSight Infrastructure Management, you enable event management for automating the detection and resolution of IT problems through correlation and prioritization of events. Before deploying TrueSight 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:

Operations Management basic deployment with App Visibility Manager

The following illustration shows a basic deployment using App Visibility Manager as the data provider. By installing App Visibility Manager, 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.

Operations Management basic deployment with App Visibility Manager and TrueSight Synthetic Monitor

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:

If you want to enable synthetic monitoring only, you must still install the App Visibility server, as shown in the following illustration.Operations Management with TrueSight Synthetic Monitor only

Operations Management App Visibility Manager deployment with reverse proxy or load balancing server

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

App Visibility proxy server deployment guidelines

To enable end-user monitoring through browser instrumentation, 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. The App Visibility JavaScript injection is supported by most web-based applications and browsers. HTML pages must contain the <head> element and the pages must be produced dynamically: JavaServer Pages (JSP) or Java servlets for Java application servers, ASP.NET applications for .NET application 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.
Because the JavaScript injection on end-user browsers requires the dynamic JavaScript insertion and the beacon to be sent in HTTPS, any interim networking equipment must be able to supply a signed certificate to enable the browser to trust the connection. The App Visibility proxy must also support the installation of signed certificates. For instructions, see Importing-a-keystore-file-or-replacing-the-certificate-for-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 callback.address property.
When monitoring a CDN-accelerated web application, the CDN's network must allow the beacon through without modification. However, the JavaScript file that calculates metrics and delivers the beacon can be cached.

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.

Note

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.

App Visibility proxy deployment options

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:

Firewall: The end users of the monitored application must be able to communicate with the App Visibility proxy on the defined ports (ports 8300 and 8343 by default).
The App Visibility proxy must have a fully qualified domain name.
The App Visibility proxy must have a certificate installed for this host name, which will be trusted by end-user browsers.
- For internal applications, you can use a certificate signed by a local signing authority (with the root preinstalled on employee browsers).
- For external applications, you must provide a signed certificate.

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.

Additional considerations for Content Delivery Networks

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.

Operations Management with Real End User Experience Monitoring Software Edition

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.

Where to go from here

For additional deployment scenarios, see Deployment-options-for-Operations-Management.

To size your environment and review the system requirements, see Planning.