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

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.