Business Objects products in this release may contain redistributions of software
licensed from third-party contributors. Some of these individual components may
also be available under alternative licenses. A partial listing of third-party
contributors that have requested or permitted acknowledgments, as well as required
notices, can be found at: http://www.businessobjects.com/thirdparty
2008-12-04
Contents
Preface7Chapter 1
About this guide...........................................................................................8
6BusinessObjects Enterprise XI Release 2 Monitoring Guide
Preface
1
Preface
1
About this guide
About this guide
The objective of this guide is to provide information about developing and
implementing a monitoring solution for BusinessObjects Enterprise.
Information includes guidelines and recommendations for developing a
monitoring strategy, usage information for BusinessObjects monitoring
probes, and instructions for implementing a monitoring solution using system
and application tools, IBM Tivoli, and Microsoft Operations Manager.
Comments welcome
Your feedback is important to us. You can send your comments about this
guide to: mailto:jc.raveneau@sap.com
8BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring
strategy
2
Developing a monitoring strategy
2
Determining which components to monitor
This section of the guide describes a process for developing a monitoring
strategy that includes:
•Determining which components to monitor
•Defining metrics, targets, and monitoring activities
•Defining monitoring responses
•Integrating BusinessObjects monitoring probes into your strategy
•Implementing your monitoring solution in stages
Note:
If your requirement is to quickly implement a basic monitoring solution, it is
recommended that you start with availability metrics for key components of
your system.
•
Components recommended by BusinessObjects on page 16 describes
key components for a typical BusinessObjects Enterprise system.
•
Staging your monitoring implementation on page 21 provides information
about implementing availability monitoring as a first step.
•
The Availability monitoring example on page 124 shows components,
metrics, targets, and monitoring activities for an availability monitoring
solution.
Determining which components to
monitor
The first step in developing a monitoring strategy is determining which system
components to monitor. The diagram below shows information sources you
can draw upon to identify and prioritize system components.
10BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring strategy
Determining which components to monitor
Recommendations for how to use each source of information are provided
in the following topics:
•
Performance goals and service level agreements (SLAs) on page 11
•
BusinessObjects Enterprise components and metrics on page 114
•
Surveying end users on page 14
•
Interviewing system architects and administrators on page 15
•
Components recommended by BusinessObjects on page 16
2
Performance goals and service level agreements
(SLAs)
Performance goals are commonly defined in Service Level Agreements
(SLAs) between IT departments and business units. The following list includes
examples of performance goals that you may find in a typical SLA:
•Availability schedules (e.g. 24/7 availability with planned system outages
for maintenance)
•User login wait time (e.g. 7 seconds maximum wait time)
•Availability of report outputs (e.g. report output refreshed daily by 6AM)
•Maximum wait times for viewing a report (e.g. 10 seconds for simple
report)
Performance goals can often be broken down into the system and application
components involved in delivering a particular service to end users.
For example, the process behind viewing a BusinessObjects Web Intelligence
report may depend on the following system and application components:
BusinessObjects Enterprise XI Release 2 Monitoring Guide11
The BusinessObjects Enterprise Administrator's Guide provides an overview
of the BusinessObjects Enterprise architecture in which it describes each
system component and provides an overview of information flows for
scheduling and viewing objects.
Components directly linked to performance goals are likely to be high priority
components in your monitoring strategy.
If your organization does not define performance goals within an SLA, a first
step in defining your monitoring strategy may be to define performance goals
that reflect business requirements. This information will help identify and
prioritize system and components to include in your monitoring strategy.
BusinessObjects architecture
When developing a monitoring strategy, consider all of the components that
participate in your BI system.
Identifying relevant components in an enterprise system can be a challenging
undertaking in larger IT environments. You may require assistance from
system architects and administrators.
The underlying network infrastructure should also be considered a
component.
A tiered view of BusinessObjects Enterprise technical architecture is shown
in the following diagram. The diagram may be of assistance in identifying
the components of your system.
12BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring strategy
Determining which components to monitor
2
For a description of each component refer to the BusinessObjects Enterprise
XI Release 2 Administrator's Guide.
BusinessObjects Enterprise XI Release 2 Monitoring Guide13
Developing a monitoring strategy
2
Determining which components to monitor
When identifying components keep in mind that BusinessObjects components
may be installed on more than one machine, server processes may be
distributed, and duplicate instances of server processes may be running on
one or more machines.
The BusinessObjects Central Configuration Manager (CCM) displays a list
of BusinessObjects services that are part of the your BusinessObjects
Enterprise system. On Windows the CCM is a graphical interface tool, as
shown in the diagram below. On UNIX, the CCM is a shell script (ccm.sh)
that allows you to manage BusinessObjects Enterprise servers from the
command line.
Surveying end users
Surveying end users can help you determine which areas of your system
require monitoring. For example, an end user survey can tell you which
applications are used most often, where there are performance issues, and
where to expect increased user activity.
14BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring strategy
Determining which components to monitor
An end user survey may tell you that running a particular report takes longer
than usual, or that the Finance department is hiring new people who will
increase demand on system components used to create financial reports.
When conducting an end user survey, ask users about performance concerns,
average daily usage, and future usage. Questions you might ask include:
•What types of reports are run and how often?
•Is performance slow when performing particular tasks?
•What types of objects are used most often?
•Will system usage increase or decrease in the near future?
•Is the business hiring new people?
•Does the business plan to use BusinessObjects applications to perform
additional tasks in the future?
The information gathered will help identify and prioritize components for
monitoring.
Interviewing system architects and administrators
2
When defining a monitoring strategy, interviewing system architects and
administrators can provide insight into which components require monitoring.
For example, System Architects may be able to help answer the following
types of questions:
•What type of load is the system designed for (e.g. how many concurrent
active users and simultaneous requests can system components support?)
•Which components are at risk if load increases?
•Which components are low risk? For example, is network bandwidth a
low risk component?
•Are there system dependencies that may not be obvious?
•Are there single points of failure in the system (i.e. systems or components
that have no redundancy)
•Which machines are likely to require additional CPU resource, memory,
or disk space in the near future?
System Administrators may be able to provide the following types of
information:
•A history of system performance including previous trouble spots
•Insight into application components or information flows
BusinessObjects Enterprise XI Release 2 Monitoring Guide15
Developing a monitoring strategy
2
Determining which components to monitor
•System usage patterns including peak usage times
Components recommended by BusinessObjects
For typical BusinessObjects Enterprise deployments that include Crystal
Reports, Web Intelligence, and Desktop Intelligence applications, the
components recommended for monitoring are outlined in the diagram below.
Components include:
•BusinessObjects Enterprise components
•System level components
•Web application server (WAS) components
•Database components
Your system components may be a subset of the recommended components
or may include additional components. For example, you may have custom
applications or other BusinessObjects applications you want to include in
your monitoring solution.
16BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring strategy
Defining metrics, targets, and monitoring activities
2
Information about recommended components is provided in the following
reference topics:
•
BusinessObjects Enterprise components and metrics on page 114
•
Web Application Server components and metrics on page 120
•
System level components and metrics on page 121
•
Database components and metrics on page 124
Defining metrics, targets, and monitoring
activities
After you identify the components you want to monitor, the next step is to
establish metrics, targets, and monitoring activities for each component.
Metrics are used to measure the health of a component. The metrics you
define depend on the components you are monitoring and your requirements.
Examples of metrics include user login time, query execution time, CPU
usage percentage, availability status for a system service, etc.
BusinessObjects Enterprise XI Release 2 Monitoring Guide17
Developing a monitoring strategy
2
Defining metrics, targets, and monitoring activities
A target is an expected result for a metric. For example, your business may
require that a system login action take no more than 6 seconds or that
average CPU usage on your servers is below 85 percent. A result that does
not meet a target may indicate a problem. Defining targets often requires
that measurements be taken over time to establish an acceptable result
range.
A ‘monitoring activity’ defines how and when data is collected for a metric.
For example, you may decide to collect user login data using an automated
script that performs a login action every few minutes, or you may use a
monitoring tool to poll your system for CPU usage metrics at a specified
interval.
The following tables provide examples of metrics, targets, and monitoring
activities for a BusinessObjects service (CMS.exe), a web application server,
system CPU, and a database.
Note:
Targets and monitoring activities, including execution and polling frequency,
will differ from system to system. For example, you may want to poll your
system less frequently if you are concerned about impacting system
performance.
BusinessObjects component (CMS.exe):
Monitoring activityTargetMetric
Ping every 2 minutes24/7CMS service availabil-
ity
< 6 secondsCMS login time
Web application server component
18BusinessObjects Enterprise XI Release 2 Monitoring Guide
Perform login action every 5 minutes
Poll system every 30 seconds< 30% usageCMS CPU usage
Poll system every 30 seconds< 95% usageCMS Disk read time
Poll system every 30 seconds< 5% usageCMS Disk write time
Developing a monitoring strategy
Defining metrics, targets, and monitoring activities
Monitoring activityTargetMetric
Ping server every 2 minutes24/7Availability
2
< 6 secondsResponse time
System component (CPU):
tion
Database component
< 6 secondsResponse time
Send HTTP request every 5 minutes
Monitoring activityTargetMetric
Poll system every 30 seconds< 85% usageAverage CPU utiliza-
Poll system every 30 seconds< 90% usageUser CPU
Poll system every 30 seconds< user CPUSystem CPU
Poll system every 30 seconds< 2 per CPURun queue
Poll system every 30 seconds< 30%I/O wait time
Monitoring activityTargetMetric
Ping server every 2 minutes24/7Availability
Run a database query every 5
minutes
For components recommended for monitoring by BusinessObjects, metrics
and targets are outlined in the following topics:
•
BusinessObjects Enterprise components and metrics on page 114
•
Web Application Server components and metrics on page 120
•
System level components and metrics on page 121
•
Database components and metrics on page 124
BusinessObjects Enterprise XI Release 2 Monitoring Guide19
Developing a monitoring strategy
2
Defining monitoring responses
Defining monitoring responses
After you define metrics, targets, and monitoring activities, the next step is
to define responses if monitoring results do not meet expected targets.
The response you define depends on the metric. For metrics related to
availability, you may chose to raise an e-mail alert to initiate immediate action.
For less critical metrics, it may be more appropriate to log results to a report
that is reviewed weekly by a system administrator.
The following table shows example responses for metrics used to measure
the health of the BusinessObjects CMS service (CMS.exe). In this example,
the response for the availability metric is to raise an e-mail alert after three
consecutive failed attempts. For login time, CPU, and disk metrics, data is
logged to a report.
ResponseMonitoring activi-
E-mail notification after 3 consecutive failed attempts
Log data to reportPerform login ac-
Log data to reportPoll system every
Log data to reportPoll system every
Log data to reportPoll system every
availability
CMS login
time
CMS CPU
usage
CMS Disk
read time
CMS Disk
write time
TargetMetric
24/7CMS service
< 6 seconds
< 30% usage
< 95% usage
< 5% usage
ty
Ping every 2 minutes
tion every 5 minutes
30 seconds
30 seconds
30 seconds
Integrating monitoring probes into your
strategy
BusinessObjects monitoring probes are a set of SDK-based scripts you can
use to monitor components of your BusinessObjects Enterprise system.
20BusinessObjects Enterprise XI Release 2 Monitoring Guide
Developing a monitoring strategy
Staging your monitoring implementation
With BusinessObjects monitoring probes you can:
•Simulate end user workflows including user login actions and report
execution for Web Intelligence, Desktop Intelligence, and Crystal Reports
applications.
•Test availability, functionality, and performance of BusinessObjects
services
•Test the BusinessObjects Central Management Server (CMS) core
functionality, CMS cache service, and CMS database connection
•Test your web application server by running probes in web mode (through
a browser)
•Test Windows AD or LDAP authentication services by running probes
under a user account that requires authentication
Monitoring probes, which can be run from a command line or web browser,
can be quickly integrated into any monitoring strategy to provide a means
of monitoring BusinessObjects components. Probes are also designed with
XML-based input and output streams that allow for integration with proprietary
or industry standard monitoring tools such as IBM Tivoli or Microsoft
Operations Manager.
The next section of the guide provides in-depth information about deploying,
running, and working with BusinessObjects monitoring probes.
2
Related Topics
•Introduction to monitoring probes on page 24
•Deploying monitoring probes on page 29
•Working with monitoring probes on page 53
•Monitoring BusinessObjects with IBM Tivoli on page 71
•Monitoring BusinessObjects with Microsoft Operations Manager (MOM)
on page 89
Staging your monitoring implementation
It is generally recommended that monitoring be implemented in stages. Your
monitoring requirements may dictate a different approach, but as a guideline
the following staged implementation is recommended:
BusinessObjects Enterprise XI Release 2 Monitoring Guide21
Developing a monitoring strategy
2
Staging your monitoring implementation
Stage 1: Availability monitoring
Availability monitoring is defined as monitoring availability of BusinessObjects
services and core system components.
Availability monitoring can largely be achieved through process based
monitoring (to ensure the process/service is “alive”) and the use of
BusinessObjects monitoring probes. For an example of availability monitoring,
see Availability monitoring example on page 124.
Stage 2: Stability monitoring
Stability monitoring adds metrics for key system indicators that help you
detect early signs of system instability. For example, in this stage you might
add monitoring for CPU, memory, and disk usage by BusinessObjects
services. Key indicators may differ for your system but the goal is the same,
which is to add metrics to your monitoring solution that allow you to react
before an outage occurs.
Stage 3: Performance monitoring
In this stage, a wider range of system metrics are added to the monitoring
solution. The goal is to use a wide array of data from system metrics,
monitoring probes, and key indicators to better understand how system
components interact, where bottlenecks occur, and how sizing and tuning
parameters can be adjusted to improve or maintain system performance.
22BusinessObjects Enterprise XI Release 2 Monitoring Guide
BusinessObjects monitoring
probes
3
BusinessObjects monitoring probes
3
Introduction to monitoring probes
Introduction to monitoring probes
BusinessObjects Enterprise monitoring probes provide you with the ability
to monitor your BusinessObjects system using simulated application
workflows which are run through SDK-based scripts.
Monitoring probes are provided in a Monitoring Add-on package that is
distributed as a .zip file for Windows deployments and a tar.gz file for
UNIX deployments. The package is available for download from the Business
Objects Labs website at: http://labs.businessobjects.com/enterprise_moni
toring/
The files required to run monitoring probes are deployed to your system
when you extract the Monitorig Add-on package to your BusinessObjects
root installation directory.
There are eight monitoring probes you can use to monitor different aspects
of your BusinessObjects system:
•CMS Logon Logoff probe
•Crystal Reports Service through Page and Cache Server probe
•Crystal Reports Service through Report Application Server probe
•Desktop Intelligence Service probe
•Web Intelligence Service probe
•CMS Ping probe
•CMS Cache probe
•CMS Database Connection probe
Monitoring probes are described in the Monitoring probes overview on
page 26.
Running a monitoring probe involves executing a monitoring probe command
with the appropriate attributes and parameters. The monitoring probe
command is monitoring.bat on Windows systems and monitoring.sh on
UNIX systems. You can run a monitoring probe from a command line
(command line mode) or from within a URL (web mode).
All monitoring probes share the same attributes which include user, password,
system, authtype, and classname. Monitoring probes that run against Crystal
Reports, Web Intelligence, and Desktop Intelligence report engines include
document ID, document name, document refresh, and file export parameters.
24BusinessObjects Enterprise XI Release 2 Monitoring Guide
BusinessObjects monitoring probes
Introduction to monitoring probes
Attributes and parameters can be defined dynamically or in an XML-based
configuration file that is called when a monitoring probe is run. The following
is an example of a monitoring probe configuration file:
Monitoring probe output is an XML-based data stream with information that
includes a success flag, execution duration, and error description (if an error
is encountered). The following screen capture shows output from a monitoring
probe run in web mode:
BusinessObjects Enterprise XI Release 2 Monitoring Guide25
BusinessObjects monitoring probes
3
Introduction to monitoring probes
XML based input and output streams are intended to provide flexibility for
integrating monitoring probes with industry-standard and proprietary
monitoring solutions.
Related Topics
•Monitoring probe attributes and parameters on page 44
•Running a monitoring probe in command line mode on page 40
•Running a monitoring probe in web mode on page 42
Monitoring probes overview
The following table describes the current set of monitoring probes and the
application workflows they simulate.
26BusinessObjects Enterprise XI Release 2 Monitoring Guide
BusinessObjects monitoring probes
Introduction to monitoring probes
DescriptionMonitoring probe
3
CMS Logon Logoff
Crystal Reports service
through Page and Cache
Server
Crystal Reports service
through Report Application
Server
Desktop Intelligence Service
Web Intelligence Service
Tests the availability of the Central Management Server (CMS) and the ability of users to
log on to the system through client applications.
The probe logs on a single user, tests session
validity, and logs off the user.
Tests the availability of the Crystal Reports
service through Crystal Reports Page Servers
and Cache Servers. Using the Crystal Reports
Page and Cache Servers, the probe opens a
report, refreshes the report, optionally exports
the report to PDF format, and closes the report.
Tests the availability of the Crystal Report service through the Report Application Servers.
Using the Report Application Servers, the probe
opens a report, optionally exports the report to
PDF format, and closes the report.
Tests the availability of the Desktop Intelligence
service through Desktop Intelligence Report
Servers. The probe opens a Desktop Intelligence document, refreshes it, optionally exports the document to XLS and PDF format,
and closes the document.
Tests the availability of the Web Intelligence
service through Web Intelligence Report
Servers. The probe opens a Web Intelligence
document, refreshes it, optionally exports the
document to XLS and PDF format, and closes
the document.
BusinessObjects Enterprise XI Release 2 Monitoring Guide27
BusinessObjects monitoring probes
3
Introduction to monitoring probes
DescriptionMonitoring probe
CMS ping
CMS cache
CMS database connection
Sends an empty query to the CMS. The test is
considered successful if the CMS returns a
parse failure error. Because query parsing is
part of CMS core functionality, the test is expected to complete quickly.
Tests the availability and health of the CMS
cache by executing the following query:
select SI_NAME from CI_SYSTEMOBJS
where SI_ID=4
This query returns the system InfoObject that
contains the CMS cluster name. After a warmup period, it is expected that the CMS retrieves
the system InfoObject from the cache rather
than the repository database. If the query fails,
the cache may not be functioning properly or
the cluster definition may be incorrect.
Tests the availability of the repository database
by executing the following query:
select SI_NAME from CI_SYSTEMOBJS
where SI_OBTYPE=13
This query returns the system InfoObject which
contains the CMS cluster name. The CMS retrieves the system InfoObject from the repository database. If this query fails there may be
a connection problem between the CMS server
and repository database.
Note:
Crystal Reports, Desktop Intelligence, and Web Intelligence probes require
a report to run whereas CMS related probes do not. Probes that use reports
have report related parameters.
28BusinessObjects Enterprise XI Release 2 Monitoring Guide
BusinessObjects monitoring probes
Deploying monitoring probes
Monitoring probe deployment includes one or more of the steps described
in the following table:
DescriptionDeployment step
Deploying monitoring probes
3
Step 1: Deploying the monitoring
probes package (on Windows or
UNIX).
Step 2: Deploying the monitor
ing.war file
Step 3: Configuring monitoring
probes for authentication
Deploying the monitoring probes package
is required to run monitoring probes. After
deploying the monitoring probes package
to your system, you can run monitoring
probes in command line mode.
After deploying the monitoring probes
package, you have the option of deploying
the monitoring.war file which allows you
to run monitoring probes through a web
browser (web mode).
To deploy the monitoring.war file, you
must:
1. Update the monitoring.war file
2. Deploy the monitoring.war file to
your web application server.
If you do not plan to use monitoring
probes in web mode, you can skip this
step.
If you want to use monitoring probes with
Windows AD or LDAP authentication, you
must perform additional configuration steps.
If you do not plan to run monitoring probes
with Windows AD or LDAP authentication,
you can skip this step.
Related Topics
•Deploying the monitoring probes package on Windows on page 30
•Deploying the monitoring probes package on UNIX on page 31
BusinessObjects Enterprise XI Release 2 Monitoring Guide29
BusinessObjects monitoring probes
3
Deploying monitoring probes
•Deploying the monitoring.war file on page 32
•Configuring monitoring probes for authentication on page 38
Deploying the monitoring probes package on
Windows
Monitoring probes require Java Development Kit (JDK) 1.4.2 or 1.5.1. If you
are using a BusinessObjects Enterprise Java application (e.g. Java InfoView),
it is recommended that you use the same JDK for the monitoring probes.
Deploying the monitoring probes package on Windows involves extracting
the monitoring probes package (monitoring.zip) to the root directory of
your BusinessObjects installation.
1. Extract the contents of the monitoring.zip file to the BusinessObjects
root installation directory. The default BusinessObjects root installation
directory is: X:\Program Files\Business Objects\, where X: is the
system drive.
Extracting the contents of the monitoring.zip deploys the following:
•a monitoring.jar file to <BOE_INSTALL_DIR>\common\3.5\java\lib
•a monitoring.war file to <BOE_INSTALL_DIR>\BusinessObjects
Enterprise 11.5\java\applications
•a monitoring folder to <BOE_INSTALL_DIR> (the BusinessObjects
root directory).
The <BOE_INSTALL_DIR>\monitoring directory will appear as follows in
Windows Explorer:
30BusinessObjects Enterprise XI Release 2 Monitoring Guide
Loading...
+ 120 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.