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:
| Product or component | Function |
|---|---|
| Remedy Single Sign-On and SSO Admin on TrueSight console | Deploy Remedy Single Sign-On for user and tenant management and for authentication to the TrueSight console. Note: Remedy Single Sign-on can be installed on the same server with the TrueSight Presentation Server if necessary. For information about deploying Single Sign-On, see Installing Remedy SSO. |
TrueSight Presentation Server and the TrueSight console | Deploy a single TrueSight Presentation Server to present data from the component products. The TrueSight console hosted on the TrueSight Presentation Server provides monitoring functions, role-based access control, solution administration, and configuration for TrueSight App Visibility Manager, a Synthetic Transaction Execution Adapter Agent (TEA) Agent, and TrueSight Infrastructure Management. Best practice: Install the TrueSight Presentation Server separately from the Infrastructure Management Server. For details about the TrueSight console and the TrueSight Presentation Server, see TrueSight Operations Management overview. |
Note
For a proof-of-concept deployment, see Guidelines for installing on a single computer.
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:
| 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 TrueSight Infrastructure Management Server hosts the TrueSight Infrastructure Management operator console, the TrueSight Infrastructure Management administrator console, and the TrueSight Infrastructure Management Service Level Object (SLO) console. The TrueSight Infrastructure Management Server requires a database, either the locally embedded Sybase database or a remote Oracle database. For more information about deploying TrueSight 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 | Optionally, for Service Impact Management, integrate BMC Atrium CMDB with Infrastructure Management to retrieve and view TrueSight Configuration Management Database (CMDB) configuration items in Infrastructure Management service models. |
| (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 release of TrueSight 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
|
| 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
|
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.
| 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 TrueSight 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 a * (default) or another 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 receives and processes end-user experience data so that you can see end-to-end transaction time and availability. The end user’s browser downloads JavaScript from the proxy. The proxy, in turn, receives beacons from the browser and sends end-user metrics to the App Visibility collectors, and stores end-user data in its storage engine. 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 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 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
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 server components.
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 component | Function |
|---|---|
| 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.
Comments
Log in or register to comment.