RiverBed AppInternal Configuration

What’s in This Documentation

This material describes configuration tasks to set up AppInternals and customize its behavior to suit your application
environment. It assumes that the tasks described in the “Installation/Configuration Quick Start“ have already been
completed.
Most configuration is done through the AppInternals web interface. Some tasks require access to the agent or analysis
server systems.
Major topics are as follows:
 “Configuration Tasks in the Web Interface“
 “Configuration Tasks on Agent System“
 “Configuration Tasks on Analysis Server System“

Riverbed AppInternals/Release 9.0 1

2 Riverbed AppInternals/Release 9.0

Configuration in the Web Interface

This material describes AppInternals analysis server configuration tasks that you perform from screens in the Web
interface.
See “Configuration on the Agent System“ for tasks that require logging in to the agent system.
See “Configuration Tasks Using the CLI“ for tasks that require logging on to the analysis server virtual machine.

Riverbed SteelCentral AppInternals Version 10.0 1

2 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 1 Agent List Screen

This screen lists agent systems being monitored by the AppInternals analysis server.

Controlling the List of Agents Displayed

 You can limit the agents listed by choosing one or more of the criteria to the left. Each criterion limits the
displayed agents to those that have matching processes to instrument.

 You can also limit the agents listed by typing a a filter pattern in the text box. The pattern matches agent names.
Patterns can use an asterisk (*) as a wildcard to match zero or more characters and a question mark (?) to match a
single character. Patterns are case sensitive. The pattern matching takes effect as you type.

 Sort the list by choosing a Sort by option.

 Click an agent name to open the “Agent Details Screen“ for that agent.

Agent Status Legend

Each agent has a status icon that represents the status shown in the Legend area to the left.

Status Meaning
New An agent appears as new for 7 days or until one or more processes to instrument are
successfully instrumented. (You instrument processes to instrument in the “Agent Details
Healthy Screen“.)
Degraded Agent reports a healthy status for all its components.
Critical
Offline Agent reports at least one component as non-healthy.

Agent reports at least one component as not functioning.

Agent is off-line and cannot be reached.

Riverbed SteelCentral AppInternals Version 10.0 3

Agent List Screen
4 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 2 Agent Details Screen

This screen provides details on a specific agent system being monitored by the AppInternals analysis server.

Agent Name

The agent name and its status (see “Agent Status Legend“) appear at the top of the screen.

Delete Button

The Delete button is enabled only if the agent status is Offline. Click Delete to remove the agent from the “Agent List
Screen“ and open that screen. Deleting an agent does not affect it or any data it may have generated. If the agent restarts
and contacts the analysis server again, it will reappear in the agent list.
Deleting an agent is useful if you know the agent will not restart, such as when you no longer want to monitor a system
and have removed the agent software from that system. Deleting the agent removes the obsolete entry from the agent
list and other configuration screens.
Deleting an agent can also be useful even when you expect it to restart. This can be useful when you also force the
agent to rediscover all candidate processes to instrument and send a new list to the analysis server. This will remove
any incorrect and obsolete entries from the “List of Processes to Instrument“. (However, you will need to re-select the
processes you want to instrument and re-associate them with custom configuration settings.)
Follow these steps:

1) On the agent system, shut down the agent (see “Start Windows Services“ and “Using dsactl to Control Agent
Software on UNIX“).

2) On the agent system, Delete the jobs.json file in the <installdir>\Panorama\hedzup\mn\userdata directory.

3) On the this screen, click Delete.

4) On the agent system, restart the agent.

Riverbed SteelCentral AppInternals Version 10.0 5

Agent Details Screen

List of Processes to Instrument

One of the functions of the AppInternals agents is to detect applications that are candidates for monitoring. The agents
detects applications at the “processes to instrument” level, which corresponds to one or more processes running on the
system. Configuration options in the “Configuration Settings Screen“ apply at the processes to instrument level.
Data is reported in the web interface at the processes to instrument level
Each row in the list represents processes to instrument that the agent detected were running on the agent system. (You
can see all processes to instrument for all agents in the “Bulk Configuration Screen“.)
Select a row in the list to see details for the processes in the “Processes to Instrument Details“ area in the lower right
of the screen.

“Processes to Instrument”

This column shows the processes to instrument that the AppInternals agent discovered on the system it is monitoring.
Each name may correspond to multiple processes. This is common with Microsoft Internet Information Services (IIS)
application pools, which often have multiple AppDomains running in them. It also occurs when there are multiple Java
applications running under the same name.
The names that correspond to multiple processes are links with a dashed underscore. Click the link to open a dialog.

Modify AppDomains Dialog

For .NET processes (including application pools), the link opens the Modify AppDomains dialog.
AppInternals automatically discovers new AppDomains as they start and displays them in this list as long as they are
running. By default, all AppDomains will be instrumented if the ““Instrument?” Option“ for the process is selected.
Clear the Include? check box to prevent specific AppDomains from being instrumented.
Any changes you make here are reflected in the “AppDomain Blacklist/Whitelist“ settings in the “Configuration
Settings Screen“ for the configuration to which the processes are assigned. The AppDomain Blacklist/Whitelist
settings provides more control over the AppDomains that AppInternals will instrument and monitor. The blacklist or
whitelist affect the behavior of the Include? check box as follows:
 If an AppDomain matches an entry the blacklist for the configuration, its Include? check box is unchecked. (If

the matching entry included a wildcard, the Include? setting is also disabled.) You must modify the blacklist to
change whether the AppDomain is instrumented.
 Similarly, if an AppDomain matches an entry in the whitelist, its Include? check box is checked. (If the matching
entry included a wildcard, the Include? setting is also disabled.)

View Processes Dialog

For Java applications, the link opens the View Processes dialog that shows the processes and their process identifier.
Unlike with .NET AppDomains, you cannot exclude specific Java processes from instrumentation.
Once you select the ““Instrument?” Option“, the processes-to-instrument name appears in the analysis screens in many
places, labeled as AppDomains/JVMs or Instance. In the Search tab, you can search for a specific
processes-to-instrument name using the “instance“ search field. You can change the name by selecting the row and
clicking Rename in the “Processes to Instrument Details“ area. This changes the name throughout the AppInternals
interface.

6 Riverbed SteelCentral AppInternals Version 10.0

Agent Details Screen

Configuration

This column shows the name of the “configuration” with settings that control what application data that JIDA or the
dotNet sub-agent collects for the processes-to-instrument name. Click the name to open the “Configuration Settings
Screen“ for the applicable configuration. You can change the assigned configuration in the “Processes to Instrument
Details“ area. (You can also change the assigned configuration in the “Bulk Configuration Screen“.)

“Instrument?” Option

This option controls whether the processes will load (or unload) the AppInternals monitoring library when it next
restarts. This “instrumentation” is the mechanism that AppInternals uses to monitor performance.

Note: Before Instrumenting, Manually Enable Instrumentation for Java Processes on the Agent
Before you select any Java processes to instrument, be sure that instrumentation has been enabled for them on the agent
system. If instrumentation has not been enabled, AppInternals will not monitor the processes. The “Instrumentation
Status“ will show as Awaiting Restart, but restarting will have no effect. See “Enabling Instrumentation of Java
Processes“ for details.

 Select the check box in the Instrument? column to start monitoring the corresponding processes. When you
select this option, the analysis server sends the agent detailed options specified by the configuration named in the
Configuration column. (See “Configuration Settings Screen“ for details.)

 Clear the check box to stop monitoring the processes.
Selecting or clearing the check box requires that the processes be restarted on the agent system. The “Instrumentation
Status“ should change to “Awaiting Restart“.

Note: Reinstalling Agent Causes Inconsistent State
When processes are successfully instrumented, the Instrument? option should be checked and the “Instrumentation
Status“ should be “Instrumented“. In some cases, the Instrument? option will be checked but the Status will show as
Running. This is an inconsistent state and means that the processes are NOT instrumented. It is usually caused by the
agent software having been uninstalled and reinstalled on the agent system. To force the processes to be instrumented,
uncheck the Instrument? option and check it again.

Riverbed SteelCentral AppInternals Version 10.0 7

Agent Details Screen

Configuration Status

This column indicates the status of the communication of configuration changes to the agent:

Status Meaning
Synchronized
The analysis server sent the configuration options to the agent and received acknowledgment.
Pending (The configuration status is also considered Synchronized when an agent discovers processes to
Failed instrument and they appear in the list. But the Synchronized status does not appear until the
Instrument? option is selected or cleared.)

The analysis server has not yet sent the configuration options to the agent.

The analysis server sent the configuration options to the agent but either did not receive an
acknowledgment or received an error in response. This status is typically caused by incorrect
entry of “Configuration Overrides“ in the “Configuration Settings Screen“.

Instrumentation Status

This status indicates whether the processes are instrumented (if known) and whether they must be restarted on the agent
system. The status changes whenever you change the ““Instrument?” Option“ or change the corresponding
configuration in the “Configuration Settings Screen“.

Status Meaning
Running
Not Running The processes are running but not instrumented.
Awaiting Restart
The processes are not running.
May Require Restart
The processes are running but require a restart for changes to take effect. Changing the
Instrumented ““Instrument?” Option“ always requires restarting the processes before the changes takes
Not Instrumentable effect.
Mixed • If Instrument? is checked and the status is Awaiting Restart then the process is not
Unknown
currently instrumented. After restarting, the status updates to Instrumented.
• If Instrument? is not checked and the status is Awaiting Restart then the process is

currently instrumented. After restarting, the status updates to Running.
Note: Awaiting Restart may also mean that Java instrumentation is not enabled
For Java processes, if you have not enabled instrumentation as described in “Enabling
Instrumentation of Java Processes“, the instrumentation status will show as Awaiting Restart,
but restarting the affected processes will have no effect until you enable Java instrumentation.

The processes are running and instrumented, but may require a restart for certain changed
settings to take effect. This status almost always means that the processes must be restarted.
Settings that change the status to May Require Restart but that always require a restart are
labeled as Restart required in the “Configuration Settings Screen“ documentation.

The processes are running and instrumented.

This status appears only for Java processes to instrument and means that the Java version is
not supported. Java 1.5 is the earliest supported version.

This status applies only to processes to instrument that represent multiple processes. It means
that individual processes have different statuses (such as Instrumented and Awaiting
restart).

The analysis server could not obtain the status of the processes to instrument (for instance,
because the agent is not running).

8 Riverbed SteelCentral AppInternals Version 10.0

Agent Details Screen

Delete (X)

Click the X icon to remove a processes-to-instrument name from list. This is useful for processes that:
 Are not running
 You know you do not to monitor
 Are not likely to run again on the agent system
If the processes do restart, they will reappear in the list. Deleting processes does not remove any data they may have
generated while instrumented.

Agent Details

This area shows details of the agent and a link to “Download the agent logs and diagnostic files“.

Download the agent logs and diagnostic files

A “diagnostic bundle” is a compressed package of analysis server log files and output from commands and
troubleshooting scripts. Typically, you generate a diagnostic bundle at the request of Riverbed support.
Click this link to generate a diagnostic bundle for the agent and open the “Diagnostic Bundle Screen“, where you can
download it to your local system.

Processes to Instrument Details

When you select a row in the “List of Processes to Instrument“, details for the processes appear in the lower right of
the screen. In addition to displaying details, this area provides configuration settings:
 Change the processes-to-instrument name by clicking Rename. This changes the name throughout the

AppInternals interface. (The name appears in the analysis screens in many places, labeled as
AppDomains/JVMs or Instance.)
Note—Restart Required
Changing the name of the processes to instrument changes the “Instrumentation Status“ to May Require
Restart, but always requires restarting the associated processes.
Note—Renaming ASP.NET Web Applications May Have No Effect
Renaming ASP.NET web applications may not change the name displayed elsewhere in the AppInternals
interface. This includes changing the name of IIS-hosted application pools (such as IIS_DefaultAppPool). When
you rename an IIS application pool (worker process), you change the name (such as IIS_DefaultAppPool) in the
configuration settings screen. You also change the instance name for the default AppDomain. However, the code
run in the default AppDomain of an IIS worker process has only a single responsibility: create an appdomain for
a web application to execute within. Almost all (if not all) of the code that does this is part of the .NET
Framework (System.* classes, for example) and is not instrumented by default. Because of this, you typically will
not see the renamed AppDomain instance for the default appdomain.
 Change the configuration to which this processes-to-instrument name is assigned by selecting the configuration
in the list next to Configuration.

Riverbed SteelCentral AppInternals Version 10.0 9

Agent Details Screen
 Create a new configuration by clicking New to open the “Configuration Settings Screen“ with a new

configuration. New configurations are automatically named config - <month/day/year>. You can rename them in
“Current Configuration“ area of the Configuration Settings screen.

10 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 3 Configurations Screen

This screen lists saved configurations. Each configuration controls what application data that JIDA and the dotNet
sub-agents collect on agents.
The settings for a particular configuration apply only to processes to instrument that are assigned to the configuration.
Until you create additional configurations, all processes to instrument are assigned to the configuration named default
config.
 Click New Configuration to create a new configuration and open the “Configuration Settings Screen“. New

configurations are automatically named config - <month/day/year>. You can rename them in “Current
Configuration“ area of the Configuration Settings screen.
 You can limit the configurations listed by choosing one or more of the criteria to the left. Each criterion limits the
configurations to those that have matching processes to instrument.
 You can also limit the configurations listed by typing a a filter pattern in the text box. The pattern matches
configuration names. Patterns can use an asterisk (*) as a wildcard to match zero or more characters and a
question mark (?) to match a single character. Patterns are case sensitive. The pattern matching takes effect as you
type.
 Sort the list by choosing a Sort by option.
 Click a configuration name to open an existing configuration in the “Configuration Settings Screen“.

Riverbed SteelCentral AppInternals Version 10.0 11

Configurations Screen
12 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 4 Configuration Settings Screen

This screen has settings that control monitoring for a “configuration”. The settings control whether AppInternals
monitors web page performance and what application data that JIDA and the dotNet sub-agents collect on agents. (The
screen also includes settings for various advanced options such as disk usage limits and logging.)

The settings for a particular configuration apply only to processes to instrument that are assigned to the configuration.
By default, all processes to instrument are assigned to the configuration named default config. You change the
assignment for processes to instrument in the “Bulk Configuration Screen“ or in the “Agent Details Screen“.

While settings on this screen control how AppInternals monitors processes to instrument, they do not control whether
they are monitored. To do that, use the ““Instrument?” Option“ in the “Agent Details Screen“ or in the “Bulk
Configuration Screen“.

How Settings Here Control Data That AppInternals Collects

AppInternals collects data from a variety of sources. This screen has settings that affect some of those sources:

 Web page: AppInternals monitors web page performance by collecting data on page loads and (if configured)
AJAX requests in users’ web browsers. This data reflects application performance from the perspective of the
end user.

The “Enable JavaScript Instrumentation (End-User Experience)“ option controls whether AppInternals collects
this data. The “Customize Snippet“ settings control details of that collection.

 Application: AppInternals monitors application performance at a JVM (for Java) or appdomain (for .NET) level.

JIDA and the dotNet sub-agent instrument classes and methods they are configured to monitor. By default, they
collect data as follows:

– For “interesting” methods in application classes. This default is specified by selecting the “Automatically
instrument interesting methods“ option. You can control which application methods are collected by
choosing the “Manually choose packages, classes, and methods to instrument“ option.

– Categories of Java and .NET classes that are typically of interest and that the sub-agents can identify
automatically (for example, database connectivity (Java JDBC or .NET ADO) or web services). These
categories monitor specific classes and methods that are not configurable. However, for troubleshooting
purposes, you can disable collection entirely for some categories in the “Optional Data to Report“ settings.

 Environment: AppInternals monitors key operating system resources metrics such as CPU, memory, and
networking on systems where agents are installed. This monitoring is automatic and requires no configuration.
None of the settings on this screen affect environmental data.

Riverbed SteelCentral AppInternals Version 10.0 13

Configuration Settings Screen

Current Configuration

This area shows details about the configuration:
 “Configuration Name (Rename/Clone/Delete)“
 “x processes to instrument using this configuration.“
 The user that created the configuration
 When the configuration was last modified

Configuration Name (Rename/Clone/Delete)

 Click Rename to rename to rename the configuration. (You cannot rename the default config configuration.)
 Click Clone to create a copy of the configuration. The copy is named originalname - copy. When you click

Clone, the “Agent and Configuration History Screen“ opens.
 Click Delete to delete the configuration. (You cannot delete the default config configuration.) If there are no

processes to instrument assigned to this configuration, then the configuration is simply deleted.
However, if any processes to instrument are assigned to this configuration (as indicated by the message below the
delete button), then those processes are assigned to the default config configuration. A dialog opens so you can
confirm that you want to go ahead with the delete and reassignment operation.
Note that if any of the processes implicitly reassigned to the default config configuration are already
instrumented, they may have to be restarted before any differences in the default config configuration will take
effect.

x processes to instrument using this configuration.

This indicates how many processes-to-instrument names are assigned to this configuration. To see specifically which
names, click the link to open the “Bulk Configuration Screen“ filtered to show those names.

Basic Settings

Enable JavaScript Instrumentation (End-User Experience)

When you select this option, AppInternals generates a JavaScript snippet that it uses to monitor web application
performance from the perspective of end users. When added to web pages, the script provides data to AppInternals
about page response time, traffic, geography, platform type, and other measurements.
This option also causes JIDA and the dotNet sub-agent to automatically add the JavaScript snippet to Web pages that
the jobs assigned to this configuration are monitoring.
 JIDA injects the JavaScript into servlet, JSP, and Web Service pages.

14 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

 The dotNet sub-agent injects the JavaScript into ASP.NET pages. NOTE: This feature does not work in .NET
Version 1.1.

Note: Additional Configuration Required for HTTPS Pages
There is additional configuration for applications that serve pages using HTTPS (secure HTTP). You must supply a
valid certificate in the “TLS Certificate Configuration Screen“. By default, the JavaScript snippet uses a self-signed
certificate that will likely cause errors and prevent generation of end-user data.

View Snippet

Click this button to open a separate dialog that displays the JavaScript snippet. This is useful for the following
purposes:
 Copy the snippet to add to web pages that AppInternals agents are not monitoring.
 Verify that changes you specified in the “Customize Snippet“ options or “Collector Configuration Screen“ appear

as expected.

Customize Snippet

Click this link to display the “Customize Snippet“ options and change behavior of the snippet. Typically, you do not
need to customize the snippet.

Note: Settings in the “Collector Configuration Screen“ also affect all snippets for all configurations.

Automatically instrument interesting methods

By default, AppInternals collects data for most application classes and methods (public only) that it determines are
“interesting”. When instrumentation is enabled, AppInternals automatically detects these classes and methods and
monitors them without any further configuration.
You can override this default behavior by selecting the “Manually choose packages, classes, and methods to
instrument“ option.

What Are Interesting Methods?

AppInternals considers methods “interesting” if they:
 Call another class
 Contain loops
 Are long (a few hundred instructions)
 Are not internal methods (Java or .NET language, internal application server, or AppInternals' own)
 Are .NET events and callback methods (such as btnPurchase_OnClick and Page_OnLoad)

Riverbed SteelCentral AppInternals Version 10.0 15

Configuration Settings Screen

Methods That Are Never Monitored

Keep in mind that AppInternals does not instrument the following methods even if they meet the interesting criteria:
 Any method detected to be a “hotspot”. Such methods incur too much overhead to monitor because they are

called many times and have a very short execution time. See the “Hotspot Detection“ section of “Instrumentation
Techniques and Troubleshooting“ for details.
 Methods that are abstract, native, or constructors.
 Methods that are shorter than 8 bytes in bytecode (Java) or intermediate language (IL, in .NET).
 Methods that make a tail call (see http://en.wikipedia.org/wiki/Tail_call).

Manually choose packages, classes, and methods to instrument

The default automatic discovery and monitoring of interesting application classes and methods typically works without
problem and requires no manual configuration.
The Manually choose packages... option selectively overrides automatic discovery and monitoring. Use this option
to supply custom filters that specify classes and methods of interest and the corresponding level of monitoring that you
want.
Cases where you may need to change the default behavior include:
 You do not want to monitor specific classes and methods that are otherwise automatically reported.
 You want monitor methods that would not be automatically reported. You can increase the monitoring level to

include the following methods:
– Methods that are not “interesting”, as described in “What Are Interesting Methods?“.
– Methods that are private.
 You want to see more details from certain classes or methods.
 Instrumentation causes a problem with your application (see “Troubleshooting Application Problems Caused by
Instrumentation“ for details).
By default, there is single filter that results in monitoring all interesting methods in all classes. (In other words, the
default filter results in the same behavior as the “Automatically instrument interesting methods“ option.)
Each filter specifies:
 “Interesting Only, Always, Never“
 “Class Specification“ that limits which classes the filter applies to
 “Method Specification (Optional)“ that limits which methods the filter applies to
To add a filter, supply the classes and (optionally) methods and click Add.
As AppInternals discovers application methods, it compares them with filters in the list and uses the first class and
method combination that matches. For this reason, the filter list automatically puts more specific filters first, following
these rules:

1) Method lists without wildcards.

2) Method lists with wildcards.

3) Class specifications without wildcards.

4) Class specifications with wildcards.

16 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

5) Filters that are prefixes of other filters follow those filters:

Com.riverbed.client.ui.*
Com.riverbed.client.*
Com.riverbed.*

6) Class specifications that begin with a a wildcard.

7) The default wildcard class specification of *.

Custom Filters May Require Restarting Applications

Whenever you add or modify a custom filter, AppInternals changes the “Instrumentation Status“ for affected processes
to instrument in the “Agent Details Screen“ to May Require Restart.
Typically, you must restart the processes for changes to take effect. The only time you do not is if all the methods that
match the new or changed filters were already instrumented as a result of the monitoring resulting from the default
“Automatically instrument interesting methods“ setting.
You can determine which methods are instrumented by scanning log files as described in “Finding Classes and
Methods That Are Instrumented“. Because that technique itself requires restarting the application, it is usually easiest
to simply restart the processes.

Interesting Only, Always, Never

This setting specifies the level of monitoring for matching classes and methods:
 Interesting Only: monitor only those methods that are interesting, as described in “What Are Interesting

Methods?“.
 Always: monitor the most methods possible. Always does not mean all methods will be monitored. See

“Methods That Are Never Monitored“. Always results in the following additional methods being monitored:
– Methods that are not interesting. Always bypasses the “interesting” methods check described in “What Are

Interesting Methods?“, so monitors any additional methods that check would have excluded.
– Private methods.
 Never: do not monitor any methods.

Class Specification

This setting specifies a class or classes to monitor. Values are case sensitive. You can use an asterisk (*) as a wildcard
character at the beginning and end of the value to potentially specify multiple classes. Wildcards are not allowed within
the value.
Valid:

com.TradeFast.SecureService.StockRequestHandler
com.myco.foo.Bar*
PaintDotNet.SystemLayer
PaintDotNet.Rendering.*
PaintDotNet.*

Not valid (wildcard in middle of the class specification):

com.myco.*.Bar

Riverbed SteelCentral AppInternals Version 10.0 17

Configuration Settings Screen

To see classes and methods that are available to monitor but are not being monitored, use the “Include methods not
instrumented (Restart Required)“ logging option. See “Troubleshooting Missing Classes“ for details.

Superclasses and Subclasses in Class Specifications

If the class specification matches a superclass, AppInternals may report data from methods in its subclasses, even if
the subclass does not match a class specification. This can be confusing, but is expected. For example, consider the
following class specification:

PaintDotNet.SystemLayer*

AppInternals discovers the add_RelinquishFocus method in the PaintDotNet.SystemLayer.ToolStripEx class because
it is interesting and matches the specified filter. The PaintDotNet.Controls.ToolConfigString class derives from
ToolStripEx.

When Paint.NET executes the add_RelinquishFocus method, AppInternals generates trace data for it. However, the
data is reported under the derived class name (the “runtime class” name), PaintDotNet.Controls.ToolConfigString.

Method Specification (Optional)

This setting specifies a comma-separated list of methods to monitor for the classes that match the “Class
Specification“. If you do not supply a value here, the default is to monitor all methods in the class (except for “Methods
That Are Never Monitored“).
Values are case sensitive. The setting allows an asterisk at the beginning and end of any method name within the list:
Valid:

*Amortization,GetSecurities*,GetWeather*

Not valid (wildcard in middle of method name):

GetSecur*Weather

An alternative to specifying a list of methods is to specify multiple filters with the same “Class Specification“, but that
each specify a different method. The following example uses the class specification com.tradefast.*.

Class Method

com.tradefast.* *Amortization
com.tradefast.* GetSecurities*
com.tradefast.* GetWeather*

18 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

Specifying Method Parameters to Report with Transaction Details

You can edit existing filters and specify method parameters whose values you want to be reported. Transaction traces
will include the parameter values for methods that match the classes and methods the filter specifies.
(The “Report Web Tier Parameters“ setting in “Advanced Settings“ also controls method parameter reporting for Web
application classes. This setting is enabled by default and exposes parameter names and values as described here.)
When trace data includes method parameters, you can search for them using the “parameter“ search field in the “Search
Tab“:

The “Call Details Tab“ in the “Transaction Details“ window shows parameter values (and, only for .NET applications,
the parameter name) in its Call Details area. (Click the icon for a row in the Search tab to open the Transaction
Details window.)

Editing a Filter to Specify Parameters

You need to be familiar with the method signature to specify which parameters you want to report in transaction trace
data. Consider the following excerpt from a C# class:

namespace com.riverbed.test.feature.param.multi.args
{

public class MultipleArgTests
{

public void threeString(string eins, string zwei, string drei)
{

.
.
.

Riverbed SteelCentral AppInternals Version 10.0 19

Configuration Settings Screen

The threeString method has three parameters, eins, zwei, and drei. Follow these steps to report those parameter values:
1) Create a filter to monitor the threeString method:
a) Choose Always for the “Interesting Only, Always, Never“.
b) Specify com.riverbed.test.feature.param.multi.args.MultipleArgTests for the “Class Specification“.
c) Specify threeString for the “Method Specification (Optional)“.
d) Click the Add button next to the method specification to create the filter.
2) Click the edit icon ( ) next to the filter you just created. The Edit Filter dialog box opens.
a) Click the Add Reported Parameter link.
b) In the Position setting, specify the parameter you want to report as an integer representing the position of the
parameter in the method signature. 1 identifies the first parameter, 2 identifies the second, and so on. 0
identifies the method return value. You can also specify * as a wildcard for all parameters not covered by
explicitly-specified positions. (Only integers and * are allowed.)
Click Add after specifying each position (ignore the Label setting for now). For this example, you would
specify 1, 2, and 3, and the Edit Filter dialog box would look like this:

c) Click Save in the dialog box to save the changed filter. The Method column for the filter now shows
(Parameters) after the method name to indicate that you configured reporting for some of the method’s
parameters.

3) Click Save in the Configuration Settings screen to save the configuration.

Using The Label Setting

The Label setting overrides the name used to identify the parameter or return value in transaction trace data. This label
appears in the “Call Details Tab“. (The Label value also affects searching using the “parameter“ search field.)
Overriding the default is useful for Java method parameters, which by default the JIDA sub-agent identifies as
p1=<value>, p2=<value>, and so on. Use the Label value to supply a more meaningful name.

20 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

The dotNet sub-agent, unlike JIDA, detects method parameter names and uses them as the default label. You can still
override the default name, but it is typically less useful for .NET parameters.
You can also supply a Label value for return values (Position 0 in the Edit Filter dialog). This value overrides the
default for both Java and .NET, where the return value is identified as retval=<value>.

Specifying Custom Stitching by Appending < or > to a Parameter Label

The > and < syntax uses the parameter label and value for trace file fields that AppInternals relies on to “stitch” related
transactions into a set. In some environments, this enables AppInternals to detect related cross-tier transactions
(transactions running in another JVM or AppDomain) when it otherwise could not.
This syntax is never required and may disrupt cases where automatic detection of related transactions is otherwise
working.
However, this specialized approach can work if you are familiar with the application code and know that the
application passes a unique identifier of some kind between tiers. In such an environment:
 Specify the > syntax in the Label setting for the parameter of the “outbound” method that calls another tier. The

> syntax is not part of the label value. When the method executes, the presence of > causes the sub-agents to write
the SENTREQUESTINJECTEDHEADER field to the trace file and uses the parameter label and value as its
value. For example, the following filter configuration specifies > after the parameter label correlationID:

When the SendMessage method executes, this configuration might generate the following trace file field (visible
in the “Call Details Tab“ in the “Transaction Details“ window):

sentrequestinjectedheader: correlationID=9BC37963C7F4EE68741385057017265

 Specify the < syntax in the Label setting for the corresponding “inbound” method parameter on the other tier.
When the method executes, the sub-agents write the RECEIVEDREQUESTINJECTEDHEADER field to the
trace file and uses the parameter label and value as its value. For example, this configuration:

This configuration might generate the following when the ReceiveMessage method executes:

receivedrequestinjectedheader: correlationID=9BC37963C7F4EE68741385057017265

AppInternals uses these trace fields to identify related transactions. The presence of a common value in the different
trace files allows it to combine the traces as a related set. See “Example: Custom Stitching Using the > < Syntax“ for
a detailed example.

Riverbed SteelCentral AppInternals Version 10.0 21

Configuration Settings Screen

Example: Custom Stitching Using the > < Syntax

This example describes a simple Java client-server application where the client has a SendMessage method and the
server has a ReceiveMessage method with the following signatures:

public void SendMessage(String message)
public void ReceiveMessage(String message)

The client passes a unique value in the SendMessage method’s message parameter each time it calls the method. The
server accepts that value as the ReceiveMessage message parameter value.
The > and < syntax in a parameter label tell JIDA or the dotNet sub-agent to use a parameter as the “stitching” value
that AppInternals uses to detect related transactions:
 The following filter configuration reports the first parameter of the client SendMessage method parameter with a

label of relationIdjava. It also specifies the > option so that JIDA supplies the parameter as the
SENTREQUESTINJECTEDHEADER transaction trace file field:

Click Add and Save to save the filter.
 Similarly, the following filter configuration specifies the < option for the server ReceiveMessage method

parameter. For the server, JIDA supplies the value in the RECEIVEDREQUESTINJECTEDHEADER field.

Click Add and Save to save the filter and click Save at the bottom of the screen to save the configuration settings.

22 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen
AppInternals uses those trace file fields is to identify the separate client and server transactions as related. Using this
approach to override the automatically-supplied stitching value can enable the AppInternals to detect related cross-tier
transactions when it otherwise could not.
The following example shows the results of the successful custom stitching when the application runs. Here is the
“Transaction Details“ window that shows that the transactions on the client (the paramJavaClient sub-agent instance)
and server tiers (paramJavaServer) are related:

The “Call Details Tab“ shows that JIDA used the parameter name and value for the value of the
SENTREQUESTINJECTEDHEADER and RECEIVEDREQUESTINJECTEDHEADER transaction trace fields:

Riverbed SteelCentral AppInternals Version 10.0 23

Configuration Settings Screen

Advanced Settings

Click the Advanced link to display advanced options. Typically, you do not need to change these settings.

Optional Data to Report

Settings in this area control whether AppInternals will instrument and monitor various predefined categories of classes.
As noted in this section, these categories correspond to specific values of the “category“ search field in the “Search
Tab“ or of metrics displayed in various cards in other tabs.
Changing these settings affects monitoring of both Java (the JIDA sub-agent) and .NET (the dotNet sub-agent)
applications.

Interaction of Optional Data Settings with Custom Filters

As described in “Manually choose packages, classes, and methods to instrument“, you can create custom filters that
specify classes and methods of interest and the corresponding level of monitoring that you want.
Custom filters may specify classes and methods that overlap with those that correspond to Optional Data settings. For
example, the System.Data.SqlClient.SqlCommand class is one of those that is monitored by enabling the “Database
(JDBC and ADO) (Restart Required)“ setting.
In general, the custom filter takes precedence. For example:
 If the custom filter specifies Never in the “Interesting Only, Always, Never“ setting but the Database

Connectivity setting is selected, the custom filter takes precedence. In the following example, despite the fact
that the Database Connectivity option is selected, AppInternals will NOT monitor
System.Data.SqlClient.SqlCommand methods, because the filter specifies Never. Other methods covered by the
Database Connectivity setting will be monitored.

24 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

 In the following example, despite the fact that the Database Connectivity option is not selected, AppInternals
WILL monitor System.Data.SqlClient.SqlCommand methods, because the filter takes precedence. The methods
will be reported under the Generic category. Other methods covered by the Database Connectivity setting will
not be monitored.

Thread (Restart Required)

Controls monitoring of thread activity in the .NET CLR (Common Language Runtime) or JVM (Java Virtual Machine)
process. The “Threads Card“ in the “AppDomains/JVMs Tab“ displays metrics controlled by this setting.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Garbage Collection (Restart Required)

Controls monitoring of garbage collection data in the .NET CLR (Common Language Runtime) or JVM (Java Virtual
Machine) process. The “Memory Card“ in the “AppDomains/JVMs Tab“ displays metrics controlled by this setting.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Web Services (Restart Required)

Controls monitoring of Web services. This data corresponds to the Web Service|Web Method value of the “category“
search field in the “Search Tab“.
If the “Report Web Tier Parameters“ setting is enabled, trace data for this category also includes method parameter
values.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

dotNet Sub-Agent

For .NET, AppInternals monitors web services implemented using ASP.NET or Windows Communication Foundation
(WCF).
 Overview of ASP.NET Web services: http://msdn.microsoft.com/en-us/library/ie/t745kdsh.aspx
 Overview of WCF Web services: http://msdn.microsoft.com/en-us/netframework/aa663324

Riverbed SteelCentral AppInternals Version 10.0 25

Configuration Settings Screen

Specifically, the dotNet sub-agent calculates metrics and transaction trace data based on calls to the following classes
and methods:
 Calls to the ProcessRequest method in the System.Web.HttpRuntime class and classes that implement the

System.Web.IHttpHandler interface.
 Calls to the BeginProcessRequest and EndProcessRequest methods in classes that implement the

System.Web.IHttpAsyncHandler interface.

JIDA Sub-Agent

For Java, AppInternals monitors Web services implemented using a number of common frameworks. For the following
Web service implementations, JIDA injects special SOAP headers that reliably identify cross-tier transactions. While
AppInternals can detect cross-tier transactions for other Web service implementations, it is more effective for the
supported implementations listed here:
 Apache Axis (overview: http://axis.apache.org/axis/)
 Apache Axis2 Version 1.2 or later (overview: http://axis.apache.org/axis2/java/core/)
 JAX-RPC for WebLogic (overview: http://docs.oracle.com/cd/E12840_01/wls/docs103/webserv_rpc/intro.html)
 Metro (overview: http://www.oracle.com/technetwork/java/index-jsp-137004.html)
 Spring-WS 1.0 (overview: http://static.springsource.org/spring-ws/sites/1.0/)
 Spring-WS 2.0 (overview: http://static.springsource.org/spring-ws/sites/2.0/)

Database (JDBC and ADO) (Restart Required)

Controls monitoring of database connections. This data corresponds to the ado and jdbc values of the “category“
search field in the “Search Tab“.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

dotNet Sub-Agent

For .NET, AppInternals monitors an application's database connections and SQL statements through ADO.NET
(ActiveX Data Objects for .NET) classes that implement various System.Data interfaces.
See the following links for more details:
 Overview of ADO.NET:

http://msdn2.microsoft.com/en-us/library/h43ks021(VS.80).aspx
 Reference material on the System.Data interfaces:

http://msdn2.microsoft.com/en-us/library/system.data.aspx

26 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

The dotNet data adapter collects data based on calls to the following classes and methods:
 Calls to classes that implement the System.Data.IDbConnection interface. The dotNet data adapter monitors calls

to these methods:
– BeginTransaction()
– BeginTransaction(System.Data.IsolationLevel)
– Close()
– CreateCommand()
– Finalize()
– Open()
 Calls to the CreateConnection() and CreateNonPooledConnection() methods in classes derived from the
System.Data.ProviderBase.DbConnectionFactory class.
 Calls to the Commit() and Rollback() methods in classes that implement the System.Data.IDbTransaction
interface.
 Calls to classes that implement the System.Data.IDbCommand interface. The dotNet data adapter monitors calls
to these methods:
– ExecuteNonQuery()
– ExecuteReader()
– ExecuteReader(System.Data.CommandBehavior)
– ExecuteReader(System.Data.CommandBehavior, System.String)
– ExecuteScalar()
– Prepare()
– Cancel()
 Calls to the Read() and Close() methods in classes that implement the System.Data.IDataReader interface. These
methods expose details of database result-set row traversal operations. Because these operations are potential
performance problems, instrumenting these methods provides additional visibility in transaction traces.

JIDA Sub-Agent

For Java, AppInternals monitors SQL statement execution from classes that implement one of the following JDBC
interfaces:
 java.sql.Driver
 java.sql.Connection
 java.sql.CallableStatement
 java.sql.PreparedStatement
 java.sql.Statement
 javax.sql.DataSource

Riverbed SteelCentral AppInternals Version 10.0 27

Configuration Settings Screen

 Calls to the following methods in classes that implement the java.sql.ResultSet interface.
– next()
– previous()
– first()
– last()
These methods expose details of database result-set row traversal operations. Because these operations are
potential performance problems, instrumenting these methods provides additional visibility in transaction traces.

SQL Bind Variables (Restart Required)

Enables exposure of the names and values of “bind variables” in prepared SQL statements or stored procedures.

Note: Do Not Enable with Sensitive Data
Use this option only when variables do not contain sensitive data. The variable names and values are not encrypted.

Unless this option is enabled, transaction trace data shows SQL statements with variable names but not values. For
example, the following transaction trace shows the variable “studentname”, but it does not show the variable’s value:

UPDATE scott.student SET address1=:address1, city=:city, zipcode=:zipcode,residenceState=:state
WHERE studentName=:studentname

If you enable this option, the trace data will include the variable name (or position in the SQL statement), and its
corresponding value. These values appear in the “Call Tree“ section of the “Transaction Details“ window.
The following example shows the contents of the SQL Bind Variable column, with bind variables and values for the
previous SQL example:

@city:Nashua
@zipcode:03063
@studentname:Charles Kao
@address1:15 North Southwood Drive
@state:NH

Optional Data to Report (Java)

Changing these settings affects monitoring only of Java applications by the JIDA sub-agent.

Java Naming and Directory Interface (JNDI) (Restart Required)

Controls monitoring of the Java Naming and Directory Interface (JNDI). This data is only available when JIDA
monitors an application that accesses one or more JNDI service providers. This data corresponds to the jndi value of
the “category“ search field in the “Search Tab“.
By default, JIDA automatically discovers and collects data for each JNDI context that is opened.
Specifically, JIDA monitors classes that implement (or inherit from a class that implements) the javax.naming.Context
or javax.naming.directory.DirContext interfaces. JIDA instruments the following methods that correspond to JNDI
naming operations:
 list
 listBindings

28 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

 lookup
 lookupLink
 bind
 rebind
 unbind
 createSubcontext
 destroySubcontext
For an introduction to JNDI naming operations, see the following URL:
http://download.oracle.com/javase/jndi/tutorial/basics/naming/index.html
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Enterprise JavaBeans (EJB) (Restart Required)

Controls monitoring of JavaBeans. This data corresponds to the ejb values of the “category“ search field in the “Search
Tab“.
By default, JIDA collects data for all application classes that implement an entity, session, or message bean:
 Entity and session beans: JIDA collects metrics for classes that implement (or inherit from a class that

implements) the javax.ejb.EntityBean or javax.ejb.SessionBean interfaces. Specifically, JIDA collects metrics for
calls to methods in these classes that are public, not abstract, not native, and not a constructor.
 Message beans: JIDA collects metrics for classes that implement (or inherit from a class that implements) both
the javax.ejb.MessageDrivenBean and javax.jms.MessageListener interfaces. Specifically, JIDA collects metrics
for calls to the MessageListener.onMessage method.
 For EJB 3.0, JIDA discovers metrics for classes with the corresponding entity, session, or message bean metadata
annotations.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Java Message Service (JMS) (Restart Required)

Controls monitoring of Java Message Service classes. JMS data provides information on Java Message Service (JMS)
clients. This data corresponds to the jms value of the “category“ search field in the “Search Tab“.
JIDA generates metrics and transaction trace data for calls to methods in each JMS class and for each JMS topic and
queue. The values for metrics for JMS classes overlap those generated for topics and queues. That is, statistics for
messages reflected in data for a particular topic or queue will also be reflected in data for one or more JMS classes.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Remote Method Invocation (RMI) (Restart Required)

Controls monitoring of remote method calls by instrumenting classes that implement the java.rmi.Remote interface.
This data corresponds to the rmi value of the “category“ search field in the “Search Tab“. Instrumenting these classes
improves detection of cross-tier transactions (“stitching”).

Riverbed SteelCentral AppInternals Version 10.0 29

Configuration Settings Screen

More details on Java RMI:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/index.html
Documentation for the Remote interface:
http://docs.oracle.com/javase/7/docs/api/java/rmi/Remote.html
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Portlets (Restart Required)

Controls monitoring of portlets. This data corresponds to the portlet value of the “category“ search field in the “Search
Tab“.
Portlet metrics and transaction trace data provide information on Java portlets that comply with Java Specification
Request (JSR) 168. The specification defines a set of standard Java APIs for portal and portlet vendors. A portlet is
similar to a servlet.
See the following links for more information on portlets:
 JSR 168: http://www.jcp.org/en/jsr/detail?id=168
 Oracle documentation for Java portlets: http://docs.oracle.com/cd/E15919_01/wlp.1032/e14244/javaportlets.htm
 WebSphere support for Java portlets:

http://www-01.ibm.com/support/knowledgecenter/websphere_iea/com.ibm.iea.was_v6/was/6.1/Architecture/W
ASv61_PortletContainer/player.html
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Servlets (Restart Required)

Controls monitoring of Servlets and JavaServer Pages (JSPs). This data corresponds to the servlet and jsp values of
the “category“ search field in the “Search Tab“.
JIDA instruments classes that implement the service method of the javax.servlet.Servlet interface on the target
application. (In almost every case, the specific class that JIDA instruments is javax.servlet.http.HttpServlet.) JIDA
calculates metrics for the service method only.

Note: Although JIDA instruments only servlet classes that implement the service method, it will report data for objects
instantiated from subclasses of those classes. This means you may see metrics for such servlet subclasses even though
they are listed as not instrumented in the JIDA log file.

Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

30 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

OSGi (Restart Required)

Controls whether JIDA modifies the org.osgi.framework.bootdelegation property of the application during startup.
This modification is required for JIDA to monitor applications that use the Open Services Gateway initiative (OSGi)
framework. See the following link for more information about the property:
http://wiki.osgi.org/wiki/Boot_Delegation
When this option is selected, JIDA adds com.riverbed.* to the property when it starts with OSGi applications. Clearing
the OSGI option will prevent JIDA from starting with OSGi applications, or, if it starts, not monitor all classes it is
configured to monitor. Use this argument at the direction of Riverbed support to troubleshoot problems.
Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

AppDomain Blacklist/Whitelist

These settings supplement the “Modify AppDomains Dialog“ in the “Agent Details Screen“ and provide more flexible
configuration of which AppDomains you monitor. These settings apply only to .NET processes.

 Choose Exclude or Include to specify a “blacklist” or “whitelist”, respectively, of AppDomains.
 Specify a comma-separated list of AppDomain names. Names are not case sensitive. You can use an asterisk (*)

as a wildcard character anywhere in each name to match zero or more characters.
AppInternals discovers new AppDomains as they start. For processes assigned to this configuration, it compares
AppDomain names with the list. If the name matches an Exclude entry, it will not be instrumented. If it matches an
Include entry, it will. The AppDomains appear in the “Modify AppDomains Dialog“ with the appropriate setting.
The default for these settings is an empty Exclude list. This results in automatically instrumenting all AppDomains as
they are discovered (provided the process itself is instrumented). Use this setting when you want to control
instrumentation of AppDomains that are not currently running:
 Some .NET environments automatically create many transient AppDomains that are not interesting to monitor

(and which would cause excessive overhead if they were instrumented). In this case, specify Exclude and values
that will match the unwanted AppDomains. When the matching AppDomains run, they appear in the “Modify
AppDomains Dialog“ but with the Include? setting not checked. (If the AppDomain matches a wildcarded string,
the Include? setting is disabled.)
 You may want to suppress automatic instrumentation and monitor only a known set of AppDomains. In this case,
specify Include and the names of the AppDomains you are interested in. Only matching AppDomains will
appear in the “Modify AppDomains Dialog“ with the Include? setting checked. (If the AppDomain matches a
wildcarded string, the Include? setting is disabled.)

Riverbed SteelCentral AppInternals Version 10.0 31

Configuration Settings Screen

Keep in mind that changes you make in these settings may affect the Include? setting in the “Modify AppDomains
Dialog“:

Any Exclude entry that matches a name in the dialog list will cause the Include? setting for the matching AppDomain
to be unchecked (and disabled if it matches a wildcarded Exclude entry). Similarly, any AppDomain that does NOT
match an Include entry will have its check box unchecked (and possibly disabled).

Logging

These settings control the level of detail in log files. Agent and sub-agent log files reside in the
<installdir>/Panorama/hedzup/mn/log directory on the agent system.
 Log file names for the dotNet sub-agent start with the prefix DA-dotNet.
 Log file names for the JIDA sub-agent start with the prefix DA-JIDA.

Verbose logging

Writes messages about application classes that the sub-agents will instrument, along with additional informational
messages. When you enable verbose logging, the dotNet or JIDA sub-agent write a message to the log similar to the
following:

05/21/2015 03:31:19 PM, dotNet , 6516 , INFO , Configuration change:
logging.verbose = true

You do not need to restart the application for verbose logging setting to take effect. However, many of the interesting
messages are written out only when application starts, so if you want to see them, you do need to restart.

Among the additional messages written to the log are the following:

 Which discovered classes will be instrumented when they run. For example, for the dotNet sub-agent:

05/21/2015 03:55:48 PM, dotNet , 7060 , INFO , Will instrument

System.Web.UI.LiteralControl.Render:hasthis System.Void(System.Web.UI.HtmlTextWriter) with

com.altaworks.da.http.LiteralControl.__AW_Render

For the JIDA sub-agent:

05/21/2015 04:25:36 PM, JIDA , 2200 , INFO , Will instrument

class: java.io.PrintWriter - it is an instance of special class

 When classes are actually instrumented (they must run before they are instrumented).

For example, for the dotNet sub-agent:

05/21/2015 03:56:07 PM, dotNet , 6216 , INFO , Instrumenting

System.Web.UI.LiteralControl.Render with com.altaworks.da.http.LiteralControl.__AW_Render

32 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

For the JIDA sub-agent:

05/21/2015 04:25:36 PM, JIDA , 2200 , INFO , Instrumented (metrics

trace) servlet print writer class java.io.PrintWriter with superclass java.io.Writer

These messages are useful to determine which classes are instrumented by default, as described in “Finding Classes
and Methods That Are Instrumented“.

Include application exceptions

Writes any exceptions from the .NET or Java application to the corresponding sub-agent log file. This option is useful
primarily to diagnose startup problems with the data adapter. Use this option only at the direction of Riverbed support.

When you enable this option, the dotNet or JIDA sub-agent write a message to the log similar to the following:

05/22/2015 12:55:07 PM, dotNet , 7948 , INFO , Configuration change:
application.exception.logging.report = true

05/22/2015 12:06:37 PM, JIDA , 3132 , INFO , Application exception
logging changed to enabled

The data adapter writes the Logging Application Exception informational message before each application exception
in the log. For example:

05/22/2015 01:04:06 PM, dotNet , 7704 , INFO , Logging Application Ex

ception:

<==

System.Data.SqlClient.SqlException in thread 39820352 (00001e18) app domain /LM/W3SVC/1/ROOT/DB

Query-1-130767728543866252

message: <unknown>

hresult: 00000000 at:

System.Data.SqlClient.SqlConnection::OnError + 0xe0

System.Data.SqlClient.TdsParser::ThrowExceptionAndWarning + 0xf5

System.Data.SqlClient.TdsParserStateObject::WriteSni + 0x16c

.

.

.

==>

Include methods not instrumented (Restart Required)

Writes the name of each discovered method that is not instrumented and the reason why it was not instrumented. This
option also implicitly enables “Verbose logging“ and makes log files grow very fast. When you enable this option, the
dotNet or JIDA sub-agent write a message to the log similar to the following:

05/21/2015 04:25:35 PM, JIDA , 5976 , INFO , AwProfile option
logging.not.instrumented: true

Here is an example of messages that the JIDA sub-agent writes when this setting is enabled:

05/21/2015 04:25:36 PM, JIDA , 2200 , INFO , Not instrumenting
, INFO , Not instrumenting
java.io.PrintWriter::append - size is only 6 bytes

05/21/2015 04:25:36 PM, JIDA , 2200

java.io.PrintWriter::write - method code not interesting

These messages are useful to find classes and methods that you want to specify in “Manually choose packages, classes,
and methods to instrument“ settings to create custom filters. They maybe those that you really do want instrument, as
described in “Troubleshooting Missing Classes“, or that you want to make sure are never instrumented.

Changing this setting changes the “Instrumentation Status“ to May Require Restart, but always requires restarting
the processes assigned to this configuration.

Riverbed SteelCentral AppInternals Version 10.0 33

Configuration Settings Screen

UNIX File Creation Permissions

These settings apply only to the JIDA sub-agent on UNIX. They control the UNIX file permissions for transaction
trace files and their parent directories. When the JIDA sub-agent monitors a Java process, the user account that starts
the Java process being monitored creates and owns the following files:
 The continuous/ directory in the <installdir>/Panorama/hedzup/mn/captures/ directory.
 The subdirectories and transaction trace files below the continuous/ directory.

Group

By default, the directories and files are created with group permissions. This default excludes access to any account
that is not in the same group as the user account that starts the Java process that JIDA is monitoring. Other users can
not read the files.
This default behavior will cause problems if the AppInternals administrative account is not in the same group as the
user that starts the Java process that JIDA is monitoring. In this case, the agent (the dsa process) can not read the trace
files and they are never copied to the analysis server.

Others

Choose Others to relax the permissions so that any user can read the directories and transaction trace files. This is less
secure but avoids the issue of the dsa process not being able to read trace files.
If you change the setting to Others from Group before starting any Java processes with JIDA monitoring, all
directories and trace files will be created with read permissions for others.
However, if you change the setting after starting a Java process with JIDA, the continuous/ directory and its children
will already have been created with the more restrictive read permission for group members. In this case, AppInternals
will attempt to change the permissions on the subdirectories and trace files, but may not succeed. If this happens, JIDA
writes an error to its log file and you will have to manually change the permissions.

Follow umask Setting

Choose Follow umask Setting to stop JIDA from applying any permissions to the transaction trace files and parent
directories. Instead, it relies on the umask setting for the user that started the Java application. The user file-creation
mode mask (umask) determines the default file permission for new files and directories. See the following link for
more details:
http://en.wikipedia.org/wiki/Umask

Transaction Tracing

These settings control various aspect of transaction trace monitoring.
Here, term "transaction" refers to a stream of calls within a single thread of execution. The first transaction in a trace
file starts with the outermost method call that JIDA or the dotNet sub-agent detects after tracing begins. It ends with
the matching completion for that call. Subsequent tracing transactions start with the outermost call in the thread and
end with the matching completion.

34 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

Enable Socket-Level Tracking of Cross-Tier Transactions

Note: Feature Not Implemented!
This option has no effect in the current release. Socket-level tracking is not available.

Enables socket-level tracking for tracking cross-tier transaction activity. Cross-tier activity occurs when one
application thread--"transaction"--calls another transaction running in another Java or .NET instance (JVM or CLR
processes). Cross-tier transactions can span multiple systems.
When enabled, cross-tier transaction tracking adds identifiers to trace files. These identifiers allow the Transaction
Trace Warehouse to combine transactions from multiple systems into a single view.
By default, AppInternals uses HTTP header tracking. This technique injects a unique custom header on client HTTP
requests. The presence of this header on each side of each request and response allows a transaction trace to be
combined across tiers.
Socket-level tracking generates identifying information in both sender and receiver transaction trace files for
components that are exchanging socket-based network messages. Enable this option for applications that communicate
exclusively using TCP/IP sockets.

Report Web Tier Parameters

Enables or disables parameter reporting for specific categories of classes. Select or clear the check box to enable or
disable parameter reporting. When enabled, this setting causes method parameter names and values to appear in the
“Call Details Tab“ in the “Transaction Details“ window. (See “Specifying Method Parameters to Report with
Transaction Details“ for more details.)
When this option is enabled, transaction traces include the parameter trace field for Web applications classes:
 EJBs (Java)
 RMI (Java)
 Web (.NET)
 Web Services (Java and .NET)
See “Optional Data to Report“ and “Optional Data to Report (Java)“ for details on which classes this option applies to.

Parameter blacklist

Accepts a "blacklist" of parameter names whose values contain sensitive data. Values of parameters specified here will
be suppressed in transaction traces. The parameter names are still included in the trace data and appear as usual in the
AppInternals interface, but the values are replaced by the string blacklisted_in_config.
Add names of parameters whose values you want to suppress:
 Separate names with commas.
 Values are not case sensitive (password is the same as PASSWORD).
 Use * to match one or more characters (*pass*).
 The list cannot exceed 257 characters.
This blacklist applies only to parameter reporting enabled via the “Report Web Tier Parameters“. It has no effect on
parameter reporting enabled via custom filters as described in “Specifying Method Parameters to Report with
Transaction Details“.

Riverbed SteelCentral AppInternals Version 10.0 35

Configuration Settings Screen

In addition to any parameter names specified here, there is a default blacklist of parameters names that are likely to
contain sensitive data (for example, *pass*). Both JIDA and the dotNet sub-agents automatically suppress reporting
of values for these parameters, even if the Parameter blacklist text box is empty. The Parameter blacklist text box
is used to add to this default list.

HTTP Cookies/Headers

These settings specify the names of HTTP headers and cookies that JIDA or the dotNet sub-agents will include in
continuous and snapshot traces.
By default, these settings are empty, and the data adapters do not write any header and cookie data. This data can be
verbose and add substantially to the size of transaction trace files and the disk activity to write them.
Specify a comma-separated list of cookie or header names whose data you want to include in traces. Use an asterisk
(*) as a wildcard character to match one or more characters in a name or by itself to match all names. For example:
HTTP Headers Host,Accept*
HTTP Cookies *SessionId
The sub-agents compare the lists with header and cookie names in HTTP pages they are monitoring. For matching
names, they write the names and values to the trace file.
To see what cookies and headers are available, use browser tools to examine pages directly. Alternatively, specify *
for both settings to see all cookies and headers in traces, then refine the setting to include only those of interest.

Transaction Duration

The Maximum call duration setting specifies the longest call sequence (in minutes) that AppInternals will consider
a single transaction when generating transaction trace data. This limit allows AppInternals components to handle
long-running transactions. In most cases, you should not have to change this setting.
In general, JIDA and the dotNet sub-agents determine the start and end of transactions by monitoring the method call
stack. A transaction starts with the outermost method call that JIDA or the dotNet sub-agent detects after tracing
begins. It ends with the matching completion for that call. In between, the call stack increases and decreases in depth
as methods call other methods and return.
The following figure shows a simple case where the call stack depth increases to 3:

When the call stack depth returns to zero, the data adapters mark the transaction as complete. The next method call
begins a new transaction, and the AppInternals can store the data about the completed transaction.
This technique works in most cases, but not when transactions run indefinitely. Examples where transactions can run
indefinitely include:

36 Riverbed SteelCentral AppInternals Version 10.0

Configuration Settings Screen

Thread pools: The application uses thread pools that implement a method that runs for the lifetime of the application.
If the sub-agents monitor such a method, they will never detect the end of any transaction it is involved in.

Stuck calls: Because of a problem, a method call never completes. In this "stuck call" case, the call stack depth
increases to a certain point and never decreases.

The sub-agents use the value of the Maximum call duration setting to handle such cases:
 In the thread-pool case, once the maximum duration elapses, the sub-agents adjust the call-tree depth to zero.

This ends the transaction and effectively excludes the thread-pool method from the call hierarchy.
 In the stuck-call case, the sub-agents include a "did not finish" indicator in the trace data along with detail about

the stuck method and how long it was stuck.

Disk Limits

Maximum disk used

Minimum disk free

Both these settings limit the disk space that continuous trace files can use:
If Maximum disk used is exceeded, AppInternals deletes the oldest files in the subdirectory for the processes on the
agent system (<installdir>\Panorama\Hedzup\mn\userdata\captures\continuous\<hashIDforProcesses>).

Riverbed SteelCentral AppInternals Version 10.0 37

Configuration Settings Screen

If the available disk space falls below Minimum disk free, AppInternals stops continuous tracing for the processes.
To resume continuous tracing, you must change the setting or delete files so the available space complies with the
setting.
Note that continuous trace files remain on the managed node even after they are copied by the analysis server. Trace
files accumulate and consume disk space until they exceed the Maximum disk used setting.
Together, the Maximum disk used and Minimum disk free settings effectively specify a buffer to limit continuous
trace disk usage.

Maximum write rate

Limits the rate at which AppInternals will write data to continuous trace files. This setting limits the processing load
imposed by the tasks on the agent system. Similarly, it also limits the network load when the analysis server copies
trace files.
AppInternals uses two techniques to limit continuous trace disk throughput:
 Exclude short method calls
 Omit less-interesting fields for each transaction
If the data rate exceeds the limit specified by this setting, AppInternals omits the shortest method calls (1 millisecond
or less) and least-interesting fields (initially, bytes sent and received) from the data it writes. If the rate continues to
exceed the limit, AppInternals omits longer method calls and additional fields until the rate complies with the specified
limit.

Configuration Overrides

Do not use this setting unless directed to do so by Riverbed technical support. It accepts internal JSON properties and
values that will be sent to the processes assigned to this configuration. AppInternals checks for valid JSON in this field
and disables the Save button if the JSON is not valid. However, there is no other validation. Supplying invalid property
names, values or format will cause unpredictable results.

38 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 5 JavaScript Snippet

When you select the “Enable JavaScript Instrumentation (End-User Experience)“ option in the “Configuration Settings
Screen“, AppInternals generates a JavaScript snippet that it uses to monitor web page performance from the
perspective of end users.

Note: Additional Configuration Required for HTTPS Pages
There is additional configuration for applications that serve pages using HTTPS (secure HTTP). You must supply a
valid certificate in the “TLS Certificates Configuration Screen“. By default, the JavaScript snippet uses a self-signed
certificate that will likely cause errors and prevent generation of end-user data.

Customize Snippet

When you click the “Customize Snippet“ link in the “Configuration Settings Screen“, the screen displays tabs with
specialized settings for customizing the JavaScript snippet.
Typically, you do not need to change these settings.

Library Location

This option changes the server that hosts a JavaScript instrumentation library required by AppInternals to monitor web
page performance.
 Served from the cloud

This option serves the library from the cloud (an Akamai content delivery network (CDN) server). This option is
fast and fault tolerant, and keeps the footprint as light as possible. The library is automatically updated as
necessary.
 Served from your collector
This option serves the library from the analysis server system.
 Self-served
This option serves the library from a web server you specify, typically the same server that hosts the web
application you want to monitor. Hosting the library in the same application server eliminates a dependency on
another server.

Riverbed SteelCentral AppInternals Version 10.0 43

JavaScript Snippet

When you select this option, configuration instructions for downloading and hosting the library appear in the
dialog window. Copy the downloaded library from the browser window where it downloaded and write it to a file
that is served by your web server. Then specify the served file location in the Location setting.
If you enable collection of “AJAX“ data, be sure to download the corresponding library.

Page Tags

Page tags are optional variables in the JavaScript snippet that you can use to collect additional data available from web
pages being monitored. Use page tags to collect any data of interest, such as a session ID or a shopping cart value. This
data will be collected in addition to the web page performance data that AppInternals collects automatically.
Page tags are exposed in the analysis server web interface as follows:
 As the “Page Tags“ transaction type definition criterion in the “Define a Transaction Type Screen“
 As the “pageload.time.backend“ and “pagetag.1, pagetag.2, and pagetag.3“ search fields values in the “Search

Tab“
To add page tags to the JavaScript snippet, select the Add page tags to snippet with the following values option and
supply values for at least one of the tags. Page tags accept the same types of values (quoted strings, variables, and
function calls) as the username variable. See “Add a username variable to snippet“ for details.
For example, a page tag value can be a function call that returns a value of interest. As a simple example, consider a
JavaScript function, getBrowserWidth(), that returns the browser window width:

<head>
<script>

function getBrowserWidth() {
return window.innerWidth+"";

}
</script>

To add a call to this function as a page tag value:
 In the Page Tags tab, select the Add page tags to snippet with the following values option.
 Supply a call to that function as one of the page tag values (Page Tag 1 in this example). You can combine text

strings, enclosed in quotes, with the function call:

'Window width = ' + getBrowserWidth()

 Click View Snippet to verify that the tag1 value was added as expected:

<script>
if(!OPNET_ARXS){

var OPNET_ARXS={startJS:Number(new Date()),
clientId:'AABEAC9A913D87C8',appId:-1,
collector:'dev.collect-opnet.com',
collectorHttpPort:8100, collectorHttpsPort:8900,
sv:'0302',
tag1:''Window width = ' + getBrowserWidth()'};
(function(){
.
.
.

 Click Save to save the configuration.

44 Riverbed SteelCentral AppInternals Version 10.0

JavaScript Snippet

Note that the function must have the value available before the page loads. In this example, the function immediately
follows the web page <HEAD> tag and precedes the AppInternals JavaScript snippet:

<head>
<script>

function getBrowserWidth() {
return window.innerWidth+"";

}
</script>
<script>
if(!OPNET_ARXS){

var OPNET_ARXS={startJS:Number(new Date()),
clientId:'AABEAC9A913D87C8',appId:-1,
collector:'dev.collect-opnet.com',
collectorHttpPort:8100, collectorHttpsPort:8900,
sv:'0302',
tag1:''Window width = ' + getBrowserWidth()'};
(function(){
.
.
.

Data Collection

To avoid exposing potentially sensitive data, you can prevent AppInternals from collecting certain information. Clear
the options for the data you do not want to collect:
 Page title (text defined in the page’s title tag)
 URL query string (all text following, and including, the first ? character)
 URL fragment (all text following, and including, the first # character)
Note that changing these options might affect any previously defined “Transaction Types“ and the order that they are
matched.

User Tracking

Disable user tracking by cookie

By default, AppInternals anonymously tracks users (within the instrumented site only) by placing a cookie on the
user’s machine. Clear the setting to turn off this behavior.
Even if you disable user tracking by cookie, AppInternals still collects the IP address for each page view. AppInternals
uses IP address to determine the geographical location, company name, and ISP.

Add a username variable to snippet

If web application pages have access to the name of the browser user, you can configure the JavaScript snippet to
collect the user name along with web page performance data. If configured, the user name is exposed in the analysis
server web interface as the “username“ search field value in the “Search Tab“ and the User column in the search results
table (if enabled)
Select the Add username variable... option and supply a value for the variable as follows.
 A hard-coded string enclosed in single or double quotation marks. For example:

'john.doe'

Riverbed SteelCentral AppInternals Version 10.0 45

JavaScript Snippet

"jane.doe"

 A variable reference. For example:

username_var

 A function call that returns the user name. For example:

myJSLib.getUsername()

 A combination of the above. For example, a hardcoded string and a function call:

'Window width = ' + getBrowserWidth()

After you provide a value, click View Snippet to verify that the username value was added as expected. Click Save
to save the configuration.
The variable or function call can be processed either via server-side scripting such as ASP or JSP or client-side
scripting such as JavaScript. If processed on the client side, the value must be available before the page loads. The
maximum length of the value is 64 characters.

AJAX

This option enables collection of data for AJAX (Asynchronous JavaScript and XML) transactions. AJAX refers to a
group of related web technologies that applications use to communicates with a server in the background, without
interfering with the current state of the page.
This option is disabled by default. Enabling AJAX transactions increases the volume of web page performance data.
By default, when you enable collection of AJAX data, you also enable the following options:
 Extend page load time to include initial AJAX transactions

An “initial AJAX transaction” is a specially-calculated delay component that represents the impact of AJAX
transactions on the response time of a page view. Typically, such transactions must complete before the user can
interact with the page. AppInternals detects initial AJAX transactions based on proprietary algorithms. This
option adds the time for initial AJAX transactions to the calculation of page load time.
 Synchronously load JavaScript library for AJAX pages (Strongly recommended)
For non-AJAX transactions, AppInternals loads the JavaScript library asynchronously to avoid any delay to web
pages. However, to capture all AJAX transactions (specifically, early calls before the JavaScript snippet loads),
AppInternals must load the library synchronously. Leave this option selected to capture all AJAX transactions.
If you customized the “Library Location“ to use the “Self-served“ option, make sure that the self-served location serves
the JavaScript library with AJAX support.

Advanced Options

Use this tab at the direction of Riverbed support to add one or more variable names and values to the JavaScript snippet.
Supply variable names and values as a comma-separated list. Enclose string values in single or double quotes:

name1 : "string1", name2 : 1234 , name3 : true

Click View Snippet to verify that the variables were added as expected. Click Save to save the configuration.

46 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 6 Bulk Configuration Screen

This screen provides controls to change multiple processes to instrument in a single operation. You can:

 Reassign the configuration that controls details of monitoring the processes to instrument. (See “Configuration
Settings Screen“ for details.)

 Start or stop instrumentation.

Settings Area

This area contains settings that filter which processes are displayed in the list, and buttons to perform actions on
selected processes in the list.

Filters

This area contains settings that filter which processes are displayed in the “List of Processes to Instrument“.
Click Clear All to remove all of the filter settings.

Setting Purpose
Agent
Supply a pattern to match one or more agent names. Patterns can use an asterisk (*) as a
Processes to Instrument wildcard to match zero or more characters and a question mark (?) to match a single
Configuration character. Patterns are case sensitive.
Instrumented? The pattern takes effect when you press ENTER, TAB, or click in another area.
Status
Supply a pattern to match the names of one or more processes to instrument. The behavior
is the same as for “Agent“.

Choose a configuration to match from the list. (You create new configurations in the
“Configurations Screen“.)

Choose whether the list should include only those processes to instrument that are
instrumented or not instrumented.

Choose a status for the processes to instrument to match from the list. See “Instrumentation
Status“ for details on what the different statuses mean.)

Riverbed SteelCentral AppInternals Version 10.0 49

Bulk Configuration Screen

Actions

This area contains buttons that perform various actions on selected rows in the “List of Processes to Instrument“.
Until you select one or more rows in the table, most buttons in this area are disabled.

Button Effect
Selects or clears selection on all rows displayed in the “List of Processes to Instrument“.
Select All
Deselect All Assigns the configuration you choose from the list to selected rows.
Instruments or stops instrumenting selected rows.
Reassign

Instrument
Stop Instrumenting

List of Processes to Instrument

Column Meaning
Selected (check box)
Agent Select the check box to select the row so it is affected by the “Actions“ you choose.
Processes to Instrument
Configuration The name of the agent on which processes are running. Click the link to open the “Agent
Details Screen“ for that agent.
Instrument?
The the processes-to-instrument name. This is the same as the ““Processes to Instrument”“
Status in the “Agent Details Screen“.

The name of the “configuration” with settings that control what application data that JIDA
or the dotNet sub-agent collects for the processes-to-instrument name. Click the name to
open the “Configuration Settings Screen“ for the applicable configuration.

Whether to start monitoring the corresponding processes. This is the same as the
““Instrument?” Option“ in the “Agent Details Screen“. Selecting the check box takes effect
immediately.

The instrumentation status for the corresponding processes. This is the same as the
“Instrumentation Status“ in the “Agent Details Screen“.

50 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 7 Agent and Configuration History
Screen

This screen lists a variety of events relating to agent configuration, including the following:

Event Description

Created a new configuration Changes to configurations that control what application data that JIDA and the dotNet
Modified a configuration sub-agents collect on agents. Any time you create, modify, or delete a configuration in
Deleted a configuration the “Configurations Screen“ or “Configuration Settings Screen“, AppInternals creates a
corresponding entry in this screen.
Discovered a new Agent
Connection by a new agent to the analysis server. (The new agent appears in the “Agent
Discovered new processes List Screen“.)
to instrument
Discovery by an agent of new processes to instrument. (The processes appear in the
Agent Details screen.)

Removed processes to Removal of processes to instrument (using the “Delete (X)“ option in the Processes to
instrument Instrument list in the Agent Details screen).

Instrumented processes Instrumentation and “uninstrumentation” of processes to instrument (using the
Uninstrumented processes ““Instrument?” Option“ in the Processes to Instrument list in the Agent Details
screen).

Entries show the related configuration name (click the name to open the “Configuration Settings Screen“) or agent (click
the name to open the “Agent Details Screen“), the number of processes affected, and the status of the operation that
triggered the event.

Configuration and instrumentation changes require the analysis server to send changed configuration options to the
agent. If any of the affected processes do not receive the changes, the status appears as Failed or x Failures.
Click the status value to open a dialog to re-try the operation.

Riverbed SteelCentral AppInternals Version 10.0 51

Agent and Configuration History Screen
52 Riverbed SteelCentral AppInternals Version 10.0

CHAPTER 8 Alert Configuration Screen

Overview

Settings on this screen specify conditions that control when AppInternals sends email alerts. Evaluation of the
conditions specified here are triggered when any threshold violation occurs.
 “Environmental Alerts“ reflect CPU usage threshold violations
 “Transactional Alerts“ reflect response time threshold violations
The alert conditions moderate the number of alert messages that result from threshold violations.
AppInternals evaluates conditions specified every minute and triggers an alert when the conditions are met. Addresses
specified in “Email Recipients“ receive alert messages.
Alerts clear after the first minute that conditions are no longer met.

Enable Alerts

Clear this setting to disable all alerts and related email messages.

Environmental Alerts

Environmental alerts are based on major and minor environmental threshold violations. These thresholds are
configured in the “Environmental Thresholds“ dialog (accessed from the “Threshold Overview Screen“) and are based
on the CPU usage of servers that AppInternals monitors.
The settings here specifies the interval over which a threshold violation must persist before AppInternals triggers an
alert. If either a major or minor environmental threshold violation continues for the specified number of minutes,
AppInternals triggers the alert.

Riverbed SteelCentral AppInternals Version 10.0 53

Alert Configuration Screen

Transactional Alerts

Transactional alerts are based on evaluating the count of major and minor transactional threshold violations. These
thresholds are configured in the “Transactional Thresholds“ dialog (accessed from the “Threshold Overview Screen“)
and are themselves based on the response time of transactions that match a specific transaction type.
The settings provide flexibility to generate alerts for behavior that represents a problem without triggering “alert
storms” of unnecessary warnings. There are three groups of settings:
 “Transaction Type Priority“
 “Threshold Violation Conditions“
 “Dampening“
AppInternals generates an alert when conditions specified by all groups are met. This means you must select at least
one check box in “Transaction Type Priority“ and in “Threshold Violation Conditions“ settings to generate a
transactional alert. Otherwise, transactional alerts are effectively disabled.
See “Transactional Alert Example“ for an example of how the conditions interact with each other and with threshold
and transaction type definitions.

Transaction Type Priority

These settings limit alerts to transaction types of the selected priorities. You specify a transaction type’s priority in the
“Priority“ setting of the “Define a Transaction Type Screen“.
Select the transaction type priorities you want to be eligible to trigger alerts.

Threshold Violation Conditions

Settings in this area specify conditions that transactional threshold violations must meet in order to trigger an alert. If
any of the selected conditions are met, AppInternals triggers the alert.
You specify transactional thresholds in the “Transactional Thresholds“ dialog (accessed from the “Threshold
Overview Screen“). Each threshold specifies a transaction type and response time values that trigger a minor or major
threshold violation any time a matching transaction meets or exceeds them.
AppInternals counts the number of transactional threshold violations for each transaction types every minute. It uses
these counts to evaluate the conditions specified here.

Percentage of Transactions with Minor/Major Violations

These values specify the percentage of all transactions matching a particular transaction type that must be in violation
to potentially generate an alert. There is a single setting that applies to either minor or major violations. Lower values
lead to more alerts.
Each minute that the percentages are exceeded counts towards the consecutive minutes interval specified in the
“Dampening“ settings.

Apdex Score

Select this option and specify the lowest acceptable Apdex score. AppInternals triggers an alert if the Apdex score goes
below that value. The Apdex score provides an indicator of major and minor transactional threshold violations in a
single value.

54 Riverbed SteelCentral AppInternals Version 10.0