BMC TrueSight Operations Management basic deployment
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.
Functionality | Deployment use case | Data provider | ||
BMC TrueSight Infrastructure Management | BMC TrueSight App Visibility Manager | Borland Silk Performer Synthetic Transaction Monitoring for BMC Software | ||
Application context Create models to represent your critical applications so you can monitor the related infrastructure and manage associated events |  | |
| |
Infrastructure monitoring Manage your infrastructure health through event and device management | |
|
| |
Application monitoring Monitor application performance, perform diagnostics, and trace application transactions |
| |
| |
Synthetic monitoring Predict application performance and health by generating and monitoring synthetic transactions |
| | | |
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 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 BMC Atrium Single Sign-On 9.0. |
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 BMC-TrueSight-Operations-Management-overview. |
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 Planning the deployment of BMC TrueSight Infrastructure Management.
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 Deployment use cases and best practices. For multiple tenants, see BMC-TrueSight-Operations-Management-service-provider-and-tenant-deployment. |
(Optional) BMC Atrium CMDB and the BMC CMDB Extensions | Optionally, for Service Impact Management, integrate BMC Atrium CMDB with Infrastructure Managementto retrieve and view BMC Atrium Configuration Management Database (CMDB) configuration items in Infrastructure Management service models. |
(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 Infrastructure Management Integration Service. |
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 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 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 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 the 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 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
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.
- 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.
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.
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.
Related topics
Planning-worksheets-for-Operations-Management