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.
- SAP Managed Tags:
20 Comments
