Use Tracers to Mark .NET Application Frontends and Backends

Introscope Blame technology tracks the performance of .NET applications to enable you to view metrics at the front and backends of your applications. This capability, referred to as Boundary Blame, allows users to triage problems in the application frontend or backend.
apmdevops106
Introscope Blame technology tracks the performance of .NET applications to enable you to view metrics at the front and backends of your applications. This capability, referred to as Boundary Blame, allows users to triage problems in the application frontend or backend.
You can use tracers to explicitly mark the frontends and backends in your application.
Frontend and backend metric information is also used to display information about your applications in the Map.
Blame tracers
Introscope provides tracers for capturing front and backend metrics: FrontendTracer and BackendTracer. These tracers explicitly mark a frontend and backend, respectively.
You can use FrontendTracer and BackendTracer to instrument your own code, such as code that accesses a backend, to cause Introscope to capture and present metrics for custom components.
If no FrontendTracer is configured, the first component in the blame stack will be the default frontend. If no BackendTracer is configured, Introscope will infer a backend -- any component that opens a client socket will be a default backend if none is explicitly marked.
To prevent specific classes from being marked as frontends, you can specify the PBD parameter is.frontend.unless.
It is useful to use a BackendTracer to assign a desired name to an item that Introscope detects as a backend or to mark custom sockets that Introscope does not instrument.
FrontendTracer and BackendTracer are instances of a BlamePointTracer, which provides metrics such as average response time, per interval counts, concurrency, and stalls. A BlamePointTracer can be applied to "middle" components for a more granular Blame stack. A BlamePointTracer, however, does not populate Errors Per Interval metrics in the Introscope Investigator.
Blame tracers in standard PBDs
Two of the standard PBDs provided with Introscope and the .NET agent, dotnet.pbd and sqlagent.pbd, implement Boundary Blame tracing:
  • PageInfoTracer in the dotnet.pbd is an instance of a FrontendTracer.
  • SQLBackendTracer in the sqlagent.pbd is an instance of a BackendTracer.
Custom FrontendMarker directive
The PBD parameter is.frontend.unless
 
enables some classes instrumented by the FrontendMarker (or its subclasses, such as PageInfoTracer) to not be marked as 
a f
rontend component. The parameter should be set as a comma-separated list of absolute class names. This may be useful when the initial component is a generic 'dispatcher' which forwards the request to a more specific component designed to handle the type of request received. The second component would therefore be a better frontend marker. The default is an empty list. PBD parameters are not dynamic, so a restart of the instrumented application server is required if the value of this parameter is changed.
Class names should only be separated by a comma,
not
spaces. Use of spaces will invalidate the SetTracerParameter directive.
Any classes designated in the parameter list that are instrumented by the tracer to which this parameter is applied will not be designated as frontends and will not generate metrics under the Frontends node in the Introscope Investigator.
For example, to prevent the classes ASP.index_aspx, and Fib.CalculatorController from being treated as frontends in the package com.ABCCorp, that are instrumented with a FrontendMarker named PageInfoTracer, you would use the following PBD directive:
SetTracerParameter: PageInfoTracer 
is.frontend.unless
 ASP.index_aspx,Fib.CalculatorController