Based upon your business and monitoring information needs, deploy Operations Management with one or more data providers. 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.
Operations Management basic deployment with all data providers
The following illustration depicts the basic BMC TrueSight Operations Management deployment with BMC TrueSight App Visibility and BMC 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 BMC TrueSight Operations Management deployments require the following products or components:
|Product or component||Function|
|BMC Atrium Single Sign-On and the BMC Atrium SSO Admin Console|
Deploy BMC Atrium Single Sign-On for user and tenant management and for authentication to the TrueSight console.
Note: BMC Atrium Single Sign-on can be installed on the same server with the TrueSight Presentation Server if necessary.
For information about deploying BMC Atrium Single Sign-On, see .
|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 BMC TrueSight App Visibility Manager or a BMC Synthetic Transaction Execution Adapter Agent (TEA) Agent. For BMC TrueSight Infrastructure Management configuration, Central Monitoring Administration is launched from the TrueSight console.
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 BMC TrueSight App Visibility and BMC 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 .
To enable BMC TrueSight Infrastructure Management as a data provider, deploy the following components:
|Product or component||Function|
|BMC TrueSight Infrastructure Management Server and Infrastructure Management console|
Deploy a BMC 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 . For multiple tenants, see BMC TrueSight Operations Management service provider and tenant deployment.
|(Optional) BMC Atrium CMDB and the BMC CMDB Extensions|
|(Optional) Event Enrichment Cell (Remote Cell)|
Installed separately from the BMC 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 BMC 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 BMC 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|
BMC 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 BMC PATROL Agent uses to monitor objects in your environment.) BMC TrueSight Infrastructure Management 10.0 supports BMC PATROL Agent version 9.5 and later. For a list of Knowledge Modules supported with Infrastructure Management 10.0, see List of Monitoring Solutions and KMs in Operations 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 Central Monitoring Administration. 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 Monitoring configuration best-practice process 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.
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 hosts 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 and Synthetic TEA Agent components.
|Product or component||Function|
|App Visibility server|
The server receives and analyzes data from the end user's browser and from agents that are installed on web application servers. The App Visibility server is comprised of an App Visibility portal, one or more App Visibility collectors, and, optionally, one or more App Visibility proxies. New databases are created during the App Visibility Server installation. The databases are installed locally on the App Visibility portal and App Visibility collector host or hosts.
|App Visibility portal|
A single App Visibility portal manages App Visibility collectors, the App Visibility proxy, 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 BMC TrueSight Operations Management service provider and tenant deployment.
|App Visibility collector|
The 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 agent|
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 a App Visibility collector.
The following agents are available:
|(Optional) App Visibility proxy|
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 App Visibility proxy server deployment guidelines.
Operations Management basic deployment with App Visibility Manager and Borland Silk Performer Synthetic Transaction Monitoring
The following illustration shows a basic deployment using App Visibility Manager and Borland Silk Performer Synthetic Transaction Monitoring as data providers. By installing Borland Silk Performer Synthetic Transaction Monitoring for BMC Software and the Synthetic TEA Agent, you enable synthetic transaction monitoring to predict application health and performance.
Operations Management with App Visibility Manager and Borland Silk Performer Synthetic Transaction Monitoring
To enable Borland Silk Performer Synthetic Transaction Monitoring for BMC Software as a data provider, deploy the following components:
|Product or component||Function|
|Borland Silk Performer Synthetic Transaction Monitoring for BMC Software|
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 BMC Synthetic Transaction Execution Adapter (TEA) Agent. On each TEA Agent computer, you can install the full Silk Performer installation or a smaller execution-module-only installation.
BMC 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 Borland Silk Performer Synthetic Transaction Monitoring 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 Borland Silk Performer Synthetic Transaction Monitoring using reverse proxy or load balancing servers
App Visibility proxy server deployment guidelines
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 BMC 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 App Visibility system requirements.
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), such as Akamai. 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.
Where to go from here
For additional deployment scenarios, see Deployment use cases and best practices.
To size your environment, see Sizing and scalability considerations.
For system requirements, see System requirements.