Page tree
Skip to end of metadata
Go to start of metadata

Based upon your business and monitoring information needs and your license entitlements, deploy 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 Operations Management.

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

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 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 componentFunction
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 BMC Atrium Single Sign-On 9.0 .

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 TrueSight Operations Management overview.

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.


Operations Management basic deployment with Infrastructure Management only

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 componentFunction
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 Infrastructure Management Integration Service .

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 Best practice approach to infrastructure monitoring administration and BMC PATROL Agent 9.6

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.

For more information, see  User Transaction monitors or BMC adapters and third-party data adapters .

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 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 componentFunction
App Visibility server

The App Visibility server comprises the following components: 

  • Portal
  • Collector
  • Proxy

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:

  • App Visibility agent for Java—The App Visibility agent for Java runs on the application server Java virtual machine (JVM), and captures designated information about application transactions. The binaries for the Agent for Java can be used to manage multiple application servers that are installed on the same host. BMC recommends installing and matching multiple instances of the App Visibility agent on a one-to-one basis with different application server types.
  • App Visibility agent for .NET—The App Visibility agent for .NET consists of two components: Agent Core and Probe. Agent Core runs as a Windows service. The probe, a subcomponent of the App Visibility agent for .NET, runs in the context of Internet Information Services (IIS) worker processes, and captures designated information about application transactions.
(Optional) App Visibility proxies

An App Visibility proxy collects and processes end-user experience data on a web application. The end user’s browser retrieves JavaScript from the proxy. The proxy, in turn, receives beacons from the browser and sends end-user metrics to the App Visibility collectors and portal. Install App Visibility proxies in the network's demilitarized zone (DMZ). Do not install the App Visibility proxy on the computer where the App Visibility portal is installed.

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.

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:

Product or componentFunction
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.

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 Changing App Visibility proxy settings.

  • 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.


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.

Product or componentFunction
Cloud Probe

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.

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.

1 Comment