Main Universal Agent page > Screen shot tour > Integration Example #2

Integration Example #2
Integrating an application for which you have NO source code

This integration example (the ProcessInfo "no-source" integration) is available for download here. Full source code is provided for this Windows-platform integration.

In order to integrate an application for which there is no source code, we need to be able to look inside the application to identify what instrumentation points are available. The boundary layer between an application and its runtime support is always visible from within the application and what you find here is all the support APIs that the application is using.

For a larger view please click the image.

It is important to understand the power and scope of this instrumentation technique. We're not talking just about API functions that were explicitly coded by the programmer at the source code level of the application. We are talking about the basic API building blocks that the application uses to interface with the operating system.

Since we can't instrument the source directly, we will instrument the runtime APIs upon which the application is built. Note that we can also always instrument application start and termination since these points are well defined even when source code is not available. We will use OC Systems' patented application patching technology to perform the instrumentation at runtime, when the application is in memory.

OC Systems' engineers are expert at identifying and exploiting application instrumentation points and can either assist you or perform the entire instrumentation for you. In fact, one of OC Systems' flagship products is RootCause, which is a powerful tool for peeking inside applications. Simply point RootCause at your application and it will identify all the runtime APIs that are used by the application. (RootCause does much more, of course.)

Most of the Universal Agent screen shots you have been viewing show the integration of process IEXPLORE.EXE. This is the Windows Internet Explorer application, for which no source code is available. Yet a fairly powerful integration was accomplished for this application in a couple hours using the Universal Agent! Let's see how this was done.

Here we see the Universal Agent Node View showing an integration of application IEXPLORE.EXE where only the IO (Input/Output) Resource node has been expanded. The specific resources that are being monitored are:

• Number of calls to Read, Write, and Other I/O functions.

• Number of bytes transferred by Read, Write, and Other I/O functions.

How did we extract this information from an application for which no source code is available, and how did we integrate those values into Unicenter NSM?

At the bottom left of the screenshot we see file ProcessInfo.apc. This shows a portion of the code that was developed to instrument the application and integrate it into Unicenter NSM. (Actually, it shows only the code for IO Resources and has been condensed for clarity.) Let's take a look at what the code does, starting at the bottom of the file:

• "probe program" and "on_entry" indicates that instrumentation code is to be inserted and executed once, when the application starts. The code that is to be executed (the call to "CreateThread") creates a thread and that thread executes function tMain().

• Function tMain() simply loops, calling CollectData() to gather information and ReportData() to process the data. The Sleep() call controls the sampling frequency.

• Function CollectData() uses standard documented system APIs to obtain information about the process.

• Function ReportData() uses the Universal Agent API to forward the resource data to Unicenter NSM.

Let's look at the UA_api() calling sequence. The first parameter identifies the resource name; the second parameter specifies its value. Notice how each individual portion (separated by dots) of the resource name is mapped into distinct nodes in Node View.

The Universal Agent application instrumentation technology allows you to inject code into a "no-source" application at program entry and exit, and runtime API entry and exit (where all API parameters are also visible). In this example, we applied instrumentation only at program entry.

At the bottom right of the screenshot we see an example of an alternate method of obtaining the number of IO bytes read and written by an application. This probe directly instruments the Win32 system API functions in a Windows DLL (kernel32.dll) and extracts information from the API calling parameters ("$3" is the third parameter passed to the function and "$return" is the value returned by the function). This is not a particularly useful probe, but is intended to illustrate how easy it is to instrument system API functions and use the extracted information in a Unicenter NSM application integration.

A "no-source" integration has subtle power. Since you didn't directly instrument application source code, the resultant integration need not be application-specific. In this case, the integration can be applied to any application. An example of this is the ProcessInfo integration (discussed above) that collects a variety of process-specific resource data for the IEXPLORE.EXE application. But this integration is not application-specific; we chose to apply it to IEXPLORE.EXE for these screen shots. The ProcessInfo integration can be applied to any Windows application!

Finally, these "no-source" instrumentation/integration techniques are useful even if you have source code for an application. If you are interested in overall resource usage by the application, for example, you may only be able to obtain this data by instrumenting the system API layer. In other cases, it is simply easier to extract the desired resource data by instrumenting the API layer.

Want to learn more? Schedule an online demo.