.NET Agent Transaction Tracer Options

You can configure various aspects of .NET Agent transaction tracing.
You can configure .NET Agent transaction tracing.
Controlling Transaction Trace Sampling
By default, agents trace each normalized unique URL in an application once per hour, to provide a sampling of transaction behavior. This sampling enables historical analysis of potentially problematic transaction types without explicitly running transaction traces.
Transaction trace sampling is enabled by default. You can disable the behavior by uncommenting the following property in the agent profile, IntroscopeAgent.profile:
Uncomment and set to false to disable transaction trace sampling.
You can configure the number of transactions that are sampled per interval and the interval period.  Uncomment these properties in the agent profile.
These configurations are typically performed in the Enterprise Manager. Configuring the following properties in the agent profile overrides any configuration that is made in the Enterprise Manager.
Uncomment and set the number of transactions that are sampled per interval. The default is 1.
Uncomment and set how long the sample interval is in seconds. The default is 120 seconds.
Transaction Trace component clamp
A clamp property (set by default to 5,000 components) limits the size of traces. When this limit is reached, warnings appear in the log, and the trace stops.
The clamp allows you to limit a component-heavy transaction the grows beyond expected component counts. For example, when a component executes hundreds of object interactions and backend SQL calls. Without the clamp, Transaction Tracer views the interactions and SQL calls as one transaction, continuing infinitely. Without a clamp in place in certain extreme situations, the CLR can run out of memory before the trace completes.
Find the property for clamping transactions in the IntroscopeAgent.profile file:
Traces exceeding the introscope.agent.transactiontrace.componentCountClamp are marked with an asterisk, and have a tool tip.
When the clamp is set too low, you might encounter Performance Monitoring (PerfMon) or LeakHunter exceptions when your applications start. In this situation, restart your managed .NET applications.
Configuring Component Stall Reporting
An application performance management stall happens when there is no response from probed components for a defined period. By default, the agents detect this condition and report stall metrics.
Each time the agent checks for stalls, all the topmost instrumented components on the method stack are checked. When a component is stalled, a stalled metric and a stall snapshot are created. A stall metric is also created for each component that subscribes to downstream monitoring.
The stall metrics are created first for the topmost instrumented components on the method stack. These metrics are created for the components that take longer than the introscope.agent.stalls.thresholdseconds value.
Downstream Subscriber Component Stalls
A component that subscribes to downstream monitoring is stalled when it calls a stalled downstream component.
By default, the following components subscribe to downstream stall monitoring:
A frontend component calls a Web service, which calls a backend component that is stalled.
Frontend--> Web service-->Backend
The stall metrics are created for the backend, the web service, and the Frontend components because all of them subscribe to downstream monitoring by default.
Upstream Inherited Component Stalls
The stall checker first examines the top member of the component stack to see if it is stalled. If the top component is not stalled, the stall checker looks for stalled parent components. When a parent is stalled, a stall metric is created for that component and each upstream parent in the stack.
If a component M1() calls multiple components M2() that each take only a few seconds, a stall metric could be reported for M1().
The stall threshold is set at 15 seconds. Method M1() calls method M2() in a loop 100 times. M2() never stalls because it takes only 2 seconds to respond each time. However, M1() is eventually stalled.
Disable the Capture of Stalls as Events
By default, the agent captures transaction stalls as events in the Transaction Event database, and generates stall metrics from the detected events. Stall metrics are generated for the first and last method in the transaction. Users can view stall events and associated metrics in the Historical Event Viewer.
Generated stall metrics are always available, but stall events are only visible when ErrorDetector is installed. Stalls are stored as ordinary errors, and are visible in the Errors Tab View and in the Live Error Viewer. You can also view stalls in the historical query viewer by querying for
. Stalled transactions are reported as Errors in the Live Error Viewer and under the
tab. Stalled transactions are not reported as Errors in the transaction Trace window when traced using
Errors matching *
criteria because this behavior is the designed behavior.
To disable the capture of stalls as events, change the stall threshold, or change the frequency with which the .NET agent checks for stalls, use the following properties:
  • introscope.agent.stalls.enable -- Controls whether the agent checks for stalls and creates events for detected stalls.
  • introscope.agent.stalls.thresholdseconds -- Specifies the minimum threshold response time when a transaction is considered stalled.
  • introscope.agent.stalls.resolutionseconds -- Specifies the frequency that the agent checks for stalls.
Support for stall tracers in PBDs is deprecated when you disable the capture of stalls as events.