Welcome to my latest update in the BI4 Diagnostic series. I left off speaking about the pillars of monitoring in BI4 and how these pillars are critical to the whole solution offering in BI4. I recently covered the metrics pillar and how instrumental Wily Introscope is in this scenario. I now want to move on to discussing the probes pillar and fill you in on how these probes can be used in your BI4 deployment.

Probes

The idea of probes has actually been around for some time internally. We use these types of scripts and such for testing the platform when in development. Being able to extend this platform into the released product is a big step for BI Administrators. Now these same scripts can be used to monitor the health of an environment under normal operating conditions. These probes use the synthetic transaction approach to monitoring that I discussed in my first blog. These probes do not monitor actual user or server events but instead utilize scripting to simulate the steps you want to measure. BI4 does come with a number of default probes that can be used straight out of the box.

Probe Types

The probes themselves are broken down into three categories (Diagnostics, Health, and Hybrid). They provide you with the functionality to design probes specifically for your application and for your workflows. These probes can test the simplest things like ensuring a server is responsive or if a user can logon. They can also perform more complex routines like running particular reports to ensure the backend response times are acceptable for your users.

Diagnostic probes are probes that generate reports containing current system information. Examples of diagnostic probes include Stop/Start Server. This probe checks all the servers, records the state of each server, restarts the servers and collects information about servers again.

Health probes are probes that generate metrics of data types such as integer, Boolean, or string. Examples of health probes include CMS Logon/Logoff. This probe checks whether users can log on and log off from the Central Management Server (CMS) successfully.

Hybrid probes are probes that function as both diagnostic and health probes. Except for Stop/Start Server probes, which are diagnostic probes, all other probes provided with SAP BusinessObjects BI platform are hybrid probes.

Default Probes

The probes that come with BI4 are just a few simple examples of what probes can do. Because there are so few probes by default you are really encouraged to develop your own probes for exactly what you want to measure. The default probes are listed below with a description of what they are used for.

CMS Logon Logoff probe checks the availability of the CMS for users to logon to the SAP BI4 landscape from a client application. If it successively logs one user on to the system and checks the session validity then logs the user off. By running this probe every two minutes it would provide you with an early alert if the environment became unstable.

The CMS ping probe queries the central management server (CMS), it will succeed if the CMS returns a parse failure error. The probes will return very quickly because the query parsing is a core part of the CMS. Any other error returned would indicate a problem and an unhealthy CMS.

The CMS cache probe tests the availability of the Info store cache. A short time after startup it is expected that the CMS retrieves most of its information from the cache; as a result the query will not hit the CMS database. If the query fails the cache may not be properly functioning or the cluster definition is incorrect.

The CMS database connection probe tests the availability of the CMS database by sending a query to the system for and Info Object representing the cluster name. The CMS subsequently retrieves this from the database and a failure would indicate a connection problem between the CMS and the database.

The Crystal Reports Service through Page and Cache Server probe checks the availability of the Crystal Report service through the Page and Cache servers. By using the Page and Cache servers the probe will open a Crystal report, refreshes it, and export it to PDF format and close it.

The Crystal Reports Service through Report Application Server probe checks the availability of the Crystal Report service through Report Application servers. By using the Report Application servers the probe will open a Crystal report and export it to PDF format and close it.

The Web Intelligence Service probe tests the availability of the Web Intelligence service through the Web Intelligence Report Servers. When it successively opens a Web Intelligence document, refreshes it, and exports it to XLS and PDF format it will return with success.

The InfoView Probe will test the logon/logoff availability of the InfoView web application.

Custom Probes

As mentioned before the platform allows you to create customized probes and add them to the monitoring service. You can create a new probe by using the provided SDKs, through the command-line interface, or through DFOs. If you are familiar with developing in java it is pretty simple to create a new probe and add it. Each probe that is added is an InfoObject just like every other object in the landscape. Without going into too much detail here I will say that the probe you add can have a number of attributes defined for it. The table of these attributes is below.

Attributes/Parameters	Description
-auth	Authentication type
-classname	Fully qualified class name of the probe
-cms	CMS name
-help	Print help for this application
-inputparam	Input parameters for the probe. For example, key1:type1:value1; key2:type2:value2 supports Integer/Long/Boolean/String
-name	Name of the probe
-password	Password to run the probe
-timeout	Timeout interval in seconds
-type	Defines the type of the probe. The values 1, 2, and 3 may appear, which correspond to: 1. Health probe 2. Diagnostic probe 3. Probe that functions as both health and diagnostic probes
-username	Username to run the probe
-probeInputType	This can be commandLine or script upload. if (commandLine) Key:CommandLine type:String value: <the command> if (scriptUpload) -scriptLocation and then specify the script location
EnableVirtualMetrics	key:EnableVirtualMetrics type:Boolean value:true/false
Delimiter	key:Delimiter type:String value:,
FirstRowhasColumnNames	key:FirstRowhasColumnNames type:Boolean value:true/false
metriccolumns	key:Metric_Columns type:Integer value:any integer
anchorcolumn	key:AnchorColumn type:Integervalue:any integer

I would like to hear some of your ideas. You have seen the sample probes we provide, what do you think would be very useful probes for you to use in your environment? I have been interested in developing a couple probes and would like to hear how they are used or could be used in live deployments. Feel free to add your comments and let us know how a probe could help you.

For the most up to date instructions for creating an E2E Trace, please refer to: https://service.sap.com/sap/support/notes/1861180

If you have ever worked on an SAP support message you have without a doubt had to collect BusinessObjects trace logs. Often you are faced with several challenges and requirements during this process including:

You must go into the Central Management Console and manually enable tracing
You need to know exactly which components are involved in the workflow you are tracing
Traces are huge and contain far more information than is really needed
Merging the traces from various components into an ordered and sequenced list is very time consuming
Filtering the traces based on thread id, user id, etc then identifying a particular workflow can be downright difficult

Wouldn't it be great if you could have just one log file that contains only the trace entries related to an end user workflow? Wouldn't it be nice if this one log file contained traces from all of the involved servers and web applications in sequential order? Better yet, what if this could be accomplished without even manually turning on tracing for all of these components? I know this seems like wishful thinking but with SAP BusinessObjects Business Intelligence Platform 4.x this is now all possible. The secret sauce that makes this all possible is a new feature implemented in BI 4.x called SAP Passport.

The SAP Passport is a unique identifier that is generated by a small client application named the SAP Client Plug-In. Using the SAP Client Plug-in you launch Internet Explorer and during subsequent transactions, the SAP Passport identifier (technically known as the correlation id) is injected into the HTTP header of each request. The SAP Passport id is then forwarded by the application server to all servers involved in the user's workflow. Inside of the SAP Client Plug-in you have the ability to override the default trace level meaning you do not need to manually enable tracing on your BI servers/web applications. The trace override is passed to each individual server and instructs the server to trace at the specified level for this user's workflow. Each trace entry created by the server for the user's workflow can now be identified by the SAP Passport id thereby enabling a true end to end trace across the BI landscape.

The SAP Client Plug-in is only part of the end to end tracing equation. The second half of the equation is to bring all of these traces into one continuous view based on the user's SAP Passport id. There are several different programs on the internet that could allow you to do this, however we have a new log file reader specifically designed to consume and parse BI 4.x GLF files. This handy little Java application is aptly named the GLF Viewer and gives you the ability to select multiple GLF files (or a folder), parse these files for a particular string (in this case the SAP Passport id), and build a new log file containing only the information that you want to analyze.

Without further adue, let's get into the gnitty gritty of how to generate an end to end trace in your BI 4.x landscape.

Generate the E2E Trace

1. Download SAP Client Plug-in 71 SP05 Patch 3 from Note 1435190. This version is for Internet Explorer 8 and 9 and works only with IE 32-bit.

2. Copy the SAP Client Plug-in archive to the client where you will be executing the workflow and unzip the files into an empty folder.

3. Close any open browsers then start the SAP Client Plug-in by executing the file plugin-starter-gui.exe.

4. Set the "Application" option to Microsoft Internet Explorer and click Launch.

5. Internet Explorer (32-bit) will launch and now you must define a few properties before you begin executing your workflow. Under the "Business Transaction Name" property choose a name that describes the workflow that you are capturing and set the "Next Step TraceLevel" to High. The "Next Step TraceLevel" setting overrides the current trace level for each component involved in the user workflow.

6. Before you start your end to end trace, you should first queue up the browser to the beginning of the problematic workflow that you wish to trace. In this example, we'll be tracing a view on-demand request for a Web Intelligence document based on a SQL Server data source (UNX).

7. When you are ready to begin your workflow, click the "Start Transaction" button.

8. After you have completed your workflow press the "Stop Transaction" button. You can ignore the message "Settings are not valid" as it relates to the SMD Agent settings for Solution Manager. Click OK to close the SAP Client Plug-in window.

Consume the E2E Trace

For the most up to date E2E trace log reader, please refer to: http://wiki.scn.sap.com/wiki/display/BOBJ/Flexible+Log+Reader

1. In the same directory where you executed the SAP Client Plug-in, browse to the /log directory. Inside of the log directory will be a folder that is named after the value you specified as "Business Transaction Name". Browse to the folder that was generated from your tracing session.

2. Open the file BusinessTransaction.xml using IE or notepad and search for the string “BusinessTransaction id=”. Locate the id associated with the BusinessTransaction as this is the unique identifier associated with your E2E trace.

3. Since the location of the BILaunchpad or OpenDocument traces is not in the same location as the default logging, you should copy these traces to the default logging directory. On your application server host, browse to the C:\ drive (or $HOME for Unix) and according to the modified date timestamp, locate the newest folder named SBOPWebapp_BIlaunchpad_*. Browse into this folder and copy *.glf to the default logging location (for example: C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\logging).

If you have a multi-node landscape, you should copy *.glf from each application server and each BI 4.x node to a centralized folder location. (note that you may need to set trace level to none or stop the SIA in order to copy the logs from the /logging folder)

4. Download the GLF Viewer from here (requires an S-USER logon) This GLF Viewer is from a BI 4.1 build and contains the functionality needed to complete the log parsing. Older GLF Viewers may not work as shown in this article.

5. Start the GLF Viewer by executing the file runGLFViewer.bat.

6. Inside the GLF Viewer, click File, Open. Choose Add Files (the Add Folder option will crash the GLFViewer at the time of this writing) and add all *.glf files from the /logging folder (or from your central log folder) that were generated with today’s date.

7. Next, confirm that the option “Should merge all into a single tab” is checked. This option is required to create the end to end view of our traced workflow.

8. Check the option to “Filter and only read matching entries:” then under the Column option select the field named “DSRRootContextID”, the operator should be “contains”, and in the text box below paste in the BusinessTransaction id that you found previously in step 2, then click OK.

9. You are now viewing a continuous end to end trace generated by components in the BI landscape. These logs have been filtered to show only the transactions generated for your user’s workflow. Additionally, the trace entries are shown in sequential order as they occur during the workflow. Analyze the DeviceName column to determine the component that generated each transaction.

10. Save your E2E trace as one trace file by clicking File then Export current (filtered) view.

Dear Folks,

Just wanted to share some of the groundwork I did with BusinessObjects monitoring.BusinessObjects monitoring application helps administrators to identify if an application is functioning normally and response times are as expected.It also allows them to

Check the performance of each server
View the recent failures on the dashboard screen
Check system availability and response time
Analyze peak load and peak period for the CMS

Frequently used terms in monitoring

Dashboard

The Dashboard page provides a centralized view for the system administrator to monitor the performance of all servers. It provides real-time information on the system KPIs, recent alerts, watches, and corresponding graphs based on the watch state.

Metrics

Metrics are foundation of the monitoring engine. A metric in its simplest definition is something to be measured. There are bunches and bunches of them predefined in the system such as CPU’s, CPU Utilization for the last 15 minutes, Total Memory, Number of Deadlocked Jobs.

Probes

Probes monitor different services and simulate the different functionalities of SAP BusinessObjects Enterprise components. By scheduling probes to run at specified intervals, the system administrator can track the availability and performance of key services provided by SAP BusinessObjects BI platform

Watch

Watches provide real-time status and historical trends of servers and workflows within the SAP BusinessObjects BI platform environment. Users can associate thresholds and alerts to a watch. You can create a watch using data from probes, servers or Derived Metrics.

Alert

An alert is a notification generated by the monitoring application, when a user-defined threshold value set for different metrics applied to a watch is breached. You can choose to receive alerts either through Email or view on the "Dashboard" page.

Below are all some of the probes and metrics that are utilized for monitoring in our environment.

List of probes

Probe Name	Probe Description	Schedule plan
CMS DB Connection	This probe tests the availability of the repository database	Every 30 mins
CMS Ping	This probe sends an empty query to the CMS and check for its response.	Every 30 mins
CMS Logon Logoff	This probe tests the availability of the CMS and the ability of users to log on to the system through client applications.	Every 30 mins
Info View Probe	This probe will log in to the BI Launch Pad using an account and authentication type you specify.	Every 30 mins
Crystal Reports Service	This probe will run a Crystal report using page and Cache Servers or RAS and track how long it takes to refresh it.	Every 30 mins
Interactive Analysis	This probe will run a Web Intelligence report and track how long it takes to refresh it.	Every 30 mins
Start Stop Servers	It will stop and start all of your servers.	Weekly

List of Metrics (Shortlisted based on applicability)

Servers

Metrics

Core

Crystal

WebI

Dashboard

Schedule frequency

Central Management Server

Input File Repository

Output File Repository

Connection Server

Crystal Reports Cache Server

Crystal Reports Processing Server

Adaptive Job Server

Adaptive Processing Server

Web Intelligence Processing Server

Dashboards Cache Server

Dashboards Processing Server

Health State

30 mins

Server Running State

30 mins

Server Enabled State

30 mins

Busy Server Threads

30 mins

Disk Size

30 mins

CPU Usage Percentage last 15 minutes

30 mins

CPU Usage Percentage last 5 minutes

30 mins

Total Disk Space in Root Directory (GB)

30 mins

Free Disk Space in Root Directory (GB)

30 mins

CPU Usage (%)

30 mins

Virtual memory size (MB)

30 mins

X - represents the applicability.

We will see more in detail about scheduling of probes and metrics, creating watches and alerting in my upcoming blogs.

Looking for your valuable feedback. Thanks for reading.

SAP BusinessObjects 4.0 Monitoring Blogs

SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(2)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(3)

Hi All,

This is the continuation of my previous blog SAP BusinessObjects 4.0 Monitoring Configuration SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

Schedule monitoring probes from the CMC

Log on to the Central Management Console. http://Server:8080/BOE/CMC
Go to Monitoring > Probes

3. Select the CMS Logon Logoff probe and click on Schedule

4. When the Schedule options appear, set the probe to run every 3 minutes from the current time to 24 hours later. We want the CMS Logon Logoff probe

to run every 3 minutes. Go to the Schedule section and set it to run every 3 minutes for the next 24 hours

5. Select the InfoView probe and set it to run every 5 minutes for the next 24 hours.

6. You should now see 2 probes set as scheduled from the Probes dashboard.

7. If the Infoview probe shows a failure, it is probably because the username/password it is using is not correct.

Right-click on the probe and select Properties
Edit the username/password, Click Save and Close. Right-click on the probe and select Run Now.
Click the refresh icon, next to the Enable Auto-Refresh button.
If you wish the probe screen to automatically update, select the ‘Enable Auto-Refresh’ button.

Creating a watch

The CMS probe is now scheduled and you want to base a watch on it so it generates an alert if the Logon Logoff action takes longer than 200 milliseconds.

Go to Monitoring > Watchlist

2. Click on New and define a name, description for your new watch as showed in the screenshot. Set the number of states to Two (OK, Danger) and check the 2 options Show on Dashboard.

3. Click on Next

Browse the available metrics and select Probes > BI40SIA.CMSLogonLogoff > execution time.

On the right panel, set the Danger operator to ‘>=’ and value to 200 (or choose a value that appears just above the current average so that you get some alerts)

4. Click on Next. Leave the settings to default: alert notifications will be sent every time the threshold is reached and notifications

will be sent to the ‘Administrator’ or to any user.

5. Click on Save to save this new watch.

Alert notification

We will get the notification when the threshold is reached. To see the alerts when your CMS probe has been running for a few hours

you may have sent alerts to the Administrator. If required we can cascade the alerts to e-mail recepients as well.

Log on to BI Launch Pad
From the Home Page, notice the new Alerts from the Alerts module – if you have alerts you will see something similar to this.

3. Click on one of the alerts to view the details

Hope you find this interesting. Thanks for reading.

SAP BusinessObjects 4.0 Monitoring Blogs

SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(2)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(3)

Remote support component, is a system monitoring and analysis platform, specifically for SAP customers who only have an SAP BusinessObjects Enterprise XI 3.1 install base.

Current development of remote support component has stopped and all future development and bug fixes will be considered in the development of a trimmed down edition of Solution Manager for Java, which will likely be named Solution Manager Diagnostics.

A monitoring solution that will work with SAP Business Intelligence Platform 4.0 is currently under development and more information on development progress will be advertised once we are closer to the release date.

In the meantime, we offer the following options for extended diagnostics for SAP Business Intelligence Platform 4.0.

Solution	EarlyWatch Alert	Documentation
SAP Solution Manager	Yes	Note 1653689 - SolMan 7.1: Managed Sys Setup - BI Platform 4.0
Wily Introscope stand-alone configuration	No	Note 1540591 - Wily Introscope Setup for SAP BOE 4.0

The BI Platform 4.x monitoring application has undergone significant improvements since the 4.0 release. In this SCN blog series, I'll outline some important fixes, tips, tricks, and documentation regarding the BI Monitoring application that every BI administrator should be made aware of. The goal of this series is for you to get the most out of the native BI monitoring application so that you may keep your BI landscape as stable and efficient as possible.

False Alerts

When using probes and alerts to programmatically re-create user workflows and confirm the availability of various aspects of your BI landscape, you may find that you are getting alerts in your email or BI inbox that have already been triggered in the past. This can be particularly annoying since you depend on these alerts to inform you of any system outages. If you are getting alerts when a watch's danger rule hasn't actually been breached then you may find yourself logging on to the company network instead of enjoying your weekend time off in peace. The reason why you get these "false" alerts is because by default, there is a 2 day reminder that re-sends alerts if they have not been acknowledged or read by the BI administrator. These reminders are also sent if the Monitoring service is restarted.

To fix this annoyance, you must go to the Central Management Console, applications, then Monitoring and change the reminder setting from 2 days to 0 days. Then restart your Adaptive Processing Server (Monitoring Service). Refer to the example below:

Stability and High CPU Consumption

If you have noticed some stability issues in the Adaptive Processing Server (Monitoring Service) in the BI 4.0 Support Pack 4 codeline, then it is because there are indeed some significant performance issues. In some cases, the Monitoring service may utilize 100% CPU on the node where the service is running. This can cause other services on the node to be starved of resources which ultimately defeats the purpose of monitoring in the first place. The good news is that we have discovered and corrected a few memory leaks which are to blame for the stability issue. The more metrics and probes defined in your BI landscape, the more likely you are to experience this issue. After applying the correction, the monitoring service will be very stable and you may scale out your metrics and probes as much as is needed to keep tabs on your BI landscape.

This problem is tracked under problem report ADAPT01682093. For more details about the problem, see note 1833881.

To fix the problem, upgrade your BI landscape to one of the following codelines:

SAP BI Platform 4.0 Support Pack 7
SAP BI Platform 4.0 Patch 4.12
SAP BI Platform 4.0 Patch 6.1

Monitoring the Availability of a BI server

One of the best features of BI Monitoring is that by default, you have the capability to keep a watchful eye of the status of your BI4 servers. If one of your BI4 servers goes down, you can configure a watch to send an alert so that you may take action to get the server back online before it causes a widespread system outage. I have documented a simple danger rule example that you may use for this purpose in note 1839303.

There are a few caveats that you need to be aware of in terms of monitoring the availability of the BI server.

You need to watch out for BI servers that get hung in stopping or starting status, not just those that stop unexpectedly or crash. There is an issue with this functionality in that the Monitoring application cannot differentiate between running state and stopping/starting state. We have tracked this issue in problem report ADAPT01685525. To correct this issue, upgrade your BI landscape to Support Pack 6 or higher.
By default, the server metrics are cached for 60 seconds. This means that if the state of the server was checked during the last 60 seconds and the server has stopped within that timeframe, then the watch will not detect that the server stopped until the next time the server metrics are collected (for example 61 seconds). To change this granularity, you can adjust the parameter "Metric Refresh Interval" to a smaller value (15 seconds is the lowest possible granularity). This setting can be found under Central Management Console, Applications, Monitoring. Refer to the example below:

Trending Database Woes

In order to be able to view historical data in the BI Monitoring application and to create trending reports against monitoring data, you must have a working trend database. For performance reasons, it is highly recommended that you migrate your trending data from the default Derby database to the Auditing database. For instructions, refer to note 1741961. Before you make the move, you need to be aware of the following issues with Oracle and SQL Server.

The documentation for using Oracle as a trending database is not correct in the BI 4.0 SP6 Administrator's Guide. To use Oracle for your trending database, refer to note 1768678.
When using SQL Server as your trend database, some special configurations must be made prior to enabling the Auditing data source, otherwise data will not be successfully entered into the details table: MOT_MES_DETAILS. Refer to note 1828472

In smaller BI landscapes (with only one node), it is ok to use the default Apache Derby database to store trend data. For larger production landscapes (with two or more physical nodes), it is best practice to use the Audit data source due to performance benefits and data integrity.

Probe Customization with Java

With custom probes, you can extend the functionality of probes to monitor almost any aspect of your BI landscape. Your imagination (and programming skills) is the limit. Should you need to develop your own custom probes and would like a tutorial to get started from, you may refer to the SCN whitepaper Developing and deploying a custom Java probe in BI 4.0. This whitepaper also includes example code for a probe that can be used to monitor the availability of the Web Servers in your application server landscape.

Stay tuned for more BI Monitoring application updates, tips, tricks and documentation in the next blog in this series coming soon to the SCN near you.

This is the continuation of my previous blogs on monitoring application in BusinessObjects 4.0.

SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(2)

So far we setup monitoring application, probes and metrics analysis, creation of watches and finally the alert configuration. In this blog we are going to see the monitoring database configuration.The real-time monitoring process goes as below

Go to Monitoring > Probes

2. Select one of the probes you scheduled earlier, for instance CMS Logon Logoff

3. From the bottom right graph, select the time window during which the probe has been running

If required we can use the time slider to select a different time window and zoom in and out. Now it’s time to analyze the captured monitoring data over a period of time. As a prerequisite for this we need to enable the monitoring database and set its properties according to the requirement.

To Configuring Monitoring database

1. Go to CMC > Applications > Monitoring Application > Properties

2. Enable Monitoring Application option has to be enabled and choose the trending database option

For monitoring database selection we have two options. We can either select the default Derby database or we can use our existing auditing database itself to hold the monitoring tables.

Default Derby database selection

Default Audit database selection

Once the monitoring database is enables we need to create Monitoring Universe and set of reports to do the historical reporting on monitoring. Let us see those activities in the upcoming blog. Hope this is interesting.

BusinessObjects Monitoring Blog series

SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(2)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(3)

I started to implement a new plugin in 2013. It is called check_sap_health (i always name my plugins like this, check_oracle_health, check_mssql_health,...). Unlike the old plugins (check_sap) it's written in Perl, based on the module sapnwrfc. This way it can be extended easily by self-written addons.

Some examples of it's usage:

$ check_sap_health --ashost 172.24.0.195 --sysnr 42 \

--username NAGIOS --password *** \

--mode connection-time

OK - 0.06 seconds to connect as NAGIOS@NPL|'connection_time'=0.06;1;5;;

$ check_sap_health ... \

--mode ccms-mte-check \

--name 'SAP CCMS Monitor Templates' \

--name2 'Enqueue' \

--name3 'NPL#Enqueue#Enqueue Server#Total Lock Time' \

--separator '#'

OK - Total Lock Time = 0.188 s | 'Enqueue Server_Total Lock Time'=0.18s;;;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $USER4/etc/check_sap_health \

--mode my-bapi-bpgetlist --name A000000001

OK - BAPI_BUPA_CENTRAL_GETDETAIL is OK, found partner ConSol* Software GmbH, runtime was 0.14s | 'runtime'=0.14;5;10;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $OMD_ROOT/etc/check_sap_health \

--mode my-snap-dumps-check

CRITICAL - 2 new shortdumps appeared between 20140509 171649 and 20140513 164249

More documentation and the download link can be found here:

http://labs.consol.de/lang/de/nagios/check_sap_health

Gerhard

Any server crashes causes disruption for your users and also costs time and money to fix. Hence, monitoring your server is important so that you can act on any issue in a proactive manner . SAP BusinessObjects BI Platform 4.0 (and above) include provisions for monitoring that you can use for individual services like APS, IFRS, OFRS, etc.. But when the CMS is down or an Apache service has exited, or even if you want to monitor beyond that, SAP BusinessObjects monitoring might not be your best solution. This calls for Enterprise Third Party Monitoring solutions. In this blog, we will see how to use Zabbix, an Enterprise class Open Source Monitoring solution, to monitor SAP BusinessObjects BI Platform.

Before we move on, let’s make sure you’ve installed and configured a running Zabbix server. We will be using Zabbix version 2.4. You can refer to Zabbix documentation for installation and configuration: https://www.zabbix.com/documentation/2.4/.

Installing Zabbix Agent

The first step is to install and configure Zabbix agent in SAP BusinessObjects BI Platform Server host. Take a look at the following steps to install Zabbix agent in SAP BI Platform.

Download Zabbix agent to the server from this link: http://www.zabbix.com/downloads/2.4.4/zabbix_agents_2.4.4.win.zip
Extract the zip files and copy the contents to the filepath C:\zabbix
Open the file win.conf present inside the conf folder and edit the following parameters:

Parameter	Value
EnableRemoteCommands	1
Server	<IP of Zabbix Server>
ServerActive	<IP of Zabbix Server>
Hostname	<Hostname of BI Platform Server>

Start the service by running the following command inside the bin folder and respective Win32/Win64 (preferred) folders

zabbix_agentd.exe –config C:\zabbix \conf\zabbix_agentd.win.conf –start

Now, Zabbix agent will be installed in the SAP BI Platform Server host. To confirm the installation, look for an entry called Zabbix Agent in msc folder.

There are other configurations that are used to auto discover hosts in Zabbix and configure advanced options and security. These are beyond the scope of the blog. You can find them in the Zabbix documentation: https://www.zabbix.com/documentation/2.4/

Configuring Zabbix Server for BI Platform

The next step is to configure Zabbix server to start monitoring the SAP BusinessObjects BI Platform host. All of these actions are done using the web based user interface of Zabbix.

Creating Host group

Host group contains all the BI Platform hosts that are to be monitored. Follow the steps below to create a Host group.

Navigate to Host groups section under Configuration tab and click on ‘Create host group’ from the right corner

Enter the group name as SAP BI Platform and click on Save to create the group

Adding host to Host group

Now, let us create a host as shown in the following steps and add the created BI platform host to our host group (created in the previous step).

Navigate to Host section under Configuration tab and click on ‘Create Host’ from the right corner

Enter the host details in the appropriate fields (Hostname, Visible Name, Agent IP Interface). Add the corresponding Host group from Other groups to In groups. Leave the port settings as default. Now, set the Status field as ‘Enabled’ and click ‘Save’.

Defining Template for SAP BI Platform

Templates host the set of applications and related configuration for monitoring them. The steps below show how to create a template for SAP BI Platform. We will add this template to our previously created Hosts group.

Navigate to Template section under Configuration tab and click on ‘Create template’ from the right corner

Enter the template name as BI_PLATFORM_TEMPLATE and add the corresponding group (SAP BI PLATFORM group) and the host (SAP BO SERVER) we created from previous step.

Now we have created and defined a template to the host. In the next series of this blog, we will define the monitoring conditions and the actions for this template which you can read here Enterprise Monitoring SAP BusinessObjects BI Platform with Zabbix – Part 2

Like this blog! Tip this blog @ 1DtfHaPcUCaA95WY4eaM2se7kkvPQFELsz

In the first part of the blog on Enterprise Monitoring SAP BusinessObjects BI Platform with Zabbix – Part 1, we had created and configured Zabbix server agent and host groups for our SAP BusinessObjects BI platform. In this second part of the blog, we will configure and setup monitoring and corresponding actions.

Adding Application to Template

A template contains the set of applications that we need to monitor. Now let us see how to create an application for our BI platform.

Navigate to Template section under Configuration tab and click on the previously created template BI_PLATFORM_TEMPLATE

Click on Application from the second level list and click on ‘Create Application’ from the right corner

Enter the application name as BI_PLATFORM_APP and click on Save to create the application. Now the application is created.

Adding Items to monitor in application

We will add each process to monitor as items in zabbix . Zabbix has some inbuilt monitoring keys that can be used to monitor the process/service and the host system. We will be creating items for the following :

BOEXI40Tomcat – BI Tomcat Service
BOEXI40SI<Hostname> where hostname is your BI Platform hostname – SI Agent Service
exe – BI Tomcat windows process
exe process – CMS Server windows process

Navigate to Template section under Configuration tab and click on our template BI_PLATFORM_TEMPLATE
Select the items from the second level list and click on the ‘Create item’ from the right corner

Enter the name for the item and select type as Zabbix agent
Select the appropriate host interface that was defined when creating the host
Select the time interval. 60 seconds is recommended for production monitoring.
Select the application as BI_PLATFORM_APP

Enter the following key and show value for the items

Items	Key	Show value
BOEXI40Tomcat	service_state[BOEXI40Tomcat]	Windows service state
BOEXI40SI<Hostname>	service_state[BOEXI40SI<Hostname>]	Windows service state
Tomcat7.exe	proc.num[tomcat7.exe]	As is
CMS.exe	proc.num[CMS.exe]	As is

Perform the above steps for all the four items that are to be monitored.

Creating Triggers to monitor the items

Triggers specify the change in state of the items in the application. It triggers a particular action based on some conditions. For eg., when CMS process is down or when the Apache process exits abruptly, etc.

Navigate to Template section under Configuration tab and click on our template BI_PLATFORM_TEMPLATE
Select the Triggers from the second level list and click on the from the right corner

Create the Triggers for each item as per the below table. Replace <Hostname> with the hostname that was defined when creating the host

Name	Expression	Severity
BOEXI40Tomcat	{<Hostname>:service_state[BOEXI40Tomcat].last()}#0	High
BOEXI40SI<Hostname>	{<Hostname>:service_state[BOEXI40SIA<Hostname>].last()}#0	High
Tomcat7.exe	{<Hostname>:proc.num[tomcat7.exe].last()}=0	High
CMS.exe	{<Hostname>:proc.num[CMS.exe].last()}=0	High

Now that you have set the trigger, your application will now be monitored by Zabbix.

Creating Actions for Triggers

Actions are the commands that are executed once the trigger is alerted. These commands are executed on the host system with the help of Zabbix agent.

Navigate to Action section under Configuration tab and click on from the right corner

Enter the Action name as BO_RESTART and navigate to the conditions tab
Select the New Condition as Trigger and type the name of the Trigger that you created in the previous step. Add all the four triggers that were created.

Similarly, add the Template name as BI_PLATFORM_TEMPLATE

Navigate to the Operations section and create a new Action operation as per the details below:

Operation type	Remote Command
Target	Current host
Type	Custom Script
Execute on	Zabbix agent
Commands	net start BOEXI40Tomcatnet start BOEXI40<Hostname>

The action is now created. Every time the trigger is set, the action would execute and restart the BI platform and Apache Server.

Additional Monitoring

Although Zabbix is a very powerful enterprise grade monitoring tool in itself, you can also set additional monitoring tasks like Web URL monitoring for SAP BusinessObjects BI Platform which is triggered when the BOE URL is not reachable. Monitoring CMS Database, memory usage and disk space for the platform host is also a feature provided by Zabbix. You could refer here for additional process to monitor BusinessObjects Servers monitoring and their executables path

Monitoring is an integral part of any platform and having an extended monitoring system helps us to setup proactive measures than reactive measures. Do you use monitoring in your platform? Try this out and let us know!

Some examples of it's usage:

$ check_sap_health --ashost 172.24.0.195 --sysnr 42 \

--username NAGIOS --password *** \

--mode connection-time

OK - 0.06 seconds to connect as NAGIOS@NPL|'connection_time'=0.06;1;5;;

$ check_sap_health ... \

--mode ccms-mte-check \

--name 'SAP CCMS Monitor Templates' \

--name2 'Enqueue' \

--name3 'NPL#Enqueue#Enqueue Server#Total Lock Time' \

--separator '#'

OK - Total Lock Time = 0.188 s | 'Enqueue Server_Total Lock Time'=0.18s;;;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $USER4/etc/check_sap_health \

--mode my-bapi-bpgetlist --name A000000001

OK - BAPI_BUPA_CENTRAL_GETDETAIL is OK, found partner ConSol* Software GmbH, runtime was 0.14s | 'runtime'=0.14;5;10;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $OMD_ROOT/etc/check_sap_health \

--mode my-snap-dumps-check

CRITICAL - 2 new shortdumps appeared between 20140509 171649 and 20140513 164249

More documentation and the download link can be found here:

http://labs.consol.de/lang/de/nagios/check_sap_health

Gerhard

Some examples of it's usage:

$ check_sap_health --ashost 172.24.0.195 --sysnr 42 \

--username NAGIOS --password *** \

--mode connection-time

OK - 0.06 seconds to connect as NAGIOS@NPL|'connection_time'=0.06;1;5;;

$ check_sap_health ... \

--mode ccms-mte-check \

--name 'SAP CCMS Monitor Templates' \

--name2 'Enqueue' \

--name3 'NPL#Enqueue#Enqueue Server#Total Lock Time' \

--separator '#'

OK - Total Lock Time = 0.188 s | 'Enqueue Server_Total Lock Time'=0.18s;;;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $USER4/etc/check_sap_health \

--mode my-bapi-bpgetlist --name A000000001

OK - BAPI_BUPA_CENTRAL_GETDETAIL is OK, found partner ConSol* Software GmbH, runtime was 0.14s | 'runtime'=0.14;5;10;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $OMD_ROOT/etc/check_sap_health \

--mode my-snap-dumps-check

CRITICAL - 2 new shortdumps appeared between 20140509 171649 and 20140513 164249

More documentation and the download link can be found here:

http://labs.consol.de/lang/de/nagios/check_sap_health

Gerhard

Some examples of it's usage:

$ check_sap_health --ashost 172.24.0.195 --sysnr 42 \

--username NAGIOS --password *** \

--mode connection-time

OK - 0.06 seconds to connect as NAGIOS@NPL|'connection_time'=0.06;1;5;;

$ check_sap_health ... \

--mode ccms-mte-check \

--name 'SAP CCMS Monitor Templates' \

--name2 'Enqueue' \

--name3 'NPL#Enqueue#Enqueue Server#Total Lock Time' \

--separator '#'

OK - Total Lock Time = 0.188 s | 'Enqueue Server_Total Lock Time'=0.18s;;;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $USER4/etc/check_sap_health \

--mode my-bapi-bpgetlist --name A000000001

OK - BAPI_BUPA_CENTRAL_GETDETAIL is OK, found partner ConSol* Software GmbH, runtime was 0.14s | 'runtime'=0.14;5;10;;

$ check_sap_health ... \

--with-mymodules-dyn-dir $OMD_ROOT/etc/check_sap_health \

--mode my-snap-dumps-check

CRITICAL - 2 new shortdumps appeared between 20140509 171649 and 20140513 164249

More documentation and the download link can be found here:

http://labs.consol.de/lang/de/nagios/check_sap_health

Gerhard

Diagnostics in SAP BI 4.0 - Pillars of Monitoring - Probes

Probes

Probe Types

Default Probes

Custom Probes

How to generate and consume an E2E trace with BI4.x (for non-SolMan landscapes)

SAP BusinessObjects 4.0 Monitoring Configuration - Part(1)

Frequently used terms in monitoring

List of probes

SAP BusinessObjects 4.0 Monitoring Configuration - Part(2)

Alert notification

Remote support component merges with Solution Manager diagnostics

Five Important Things Every BI4 Administrator Should Know About the BI Monitoring Application

False Alerts

Stability and High CPU Consumption

Monitoring the Availability of a BI server

Trending Database Woes

Probe Customization with Java

SAP BusinessObjects 4.0 Monitoring Configuration - Part(3)

Monitoring SAP Netweaver with Nagios

Enterprise Monitoring SAP BusinessObjects BI Platform with Zabbix – Part 1

Installing Zabbix Agent

Configuring Zabbix Server for BI Platform

Creating Host group

Adding host to Host group

Defining Template for SAP BI Platform

Enterprise Monitoring SAP BusinessObjects BI Platform with Zabbix – Part 2

Adding Application to Template

Adding Items to monitor in application

Creating Triggers to monitor the items

Creating Actions for Triggers

Additional Monitoring

Monitoring SAP Netweaver with Nagios

Monitoring SAP Netweaver with Nagios

Monitoring SAP Netweaver with Nagios