.NET/.NET Core Agent
The .NET agent is an application management solution for .NET application. The .NET agent monitors mission-critical .NET applications running in a Microsoft Common Language Runtime (CLR) environment. The agent, provides visibility to the component level.
.NET Agent Overview
In aAfter you install and configure the .NET agent, the applications that run on your system are automatically instrumented at startup.
DX APMdeployment, an agent collects application and environment metrics and relays them to the Enterprise Manager. An application that reports metrics to an agent is referred to as an instrumented application.
The following illustration shows a simple
DX APMdeployment in which .NET applications connect to SQL server databases. Each application server hosts a .NET and a SQL agent. The agents monitor the application activity and report metrics to the Enterprise Manager. Larger, more complex deployments can have more agents and multiple Enterprise Managers. You view metrics using Team Center or Workstation.
By default, only ASP.NET applications that are deployed using Microsoft Internet Information Services (IIS) and active on a system are instrumented. You can also instrument standalone .NET executables or instrument only a subset of applications.
The instrumentation process, performed by tracers, is defined in ProbeBuilder Directive (PBD) files. The directives in PBD files identify the application components to monitor. Tracers identify the metrics that an agent collects for those components as they run in the CLR. The .NET agent then sends this metric information to the Enterprise Manager.
The Enterprise Manager stores the metrics reported by multiple agents. You can use Team Center or Workstation to monitor application activity, investigate performance issue sources, and diagnose problems.
The .NET agent dynamically loads instrumentation without requiring application restarts. Here are some examples:
- You can instrument a specific method that does not already match an existing probe definition. Specifically, you can instrument asynchronous MVC methods without requiring a restart.
- DX APMcan reevaluate methods and modify instrumentation when you take these actions:
- Place a new .pbd file into thehotdeployfolder
- Change or remove an existing .pbd file.
Model View Controller (MVC) Support
The .NET agent supports monitoring of MVC-framework applications, allowing you to perform these tasks:
- Use standard URL groups, and business transaction recording and decoding functionality
- Monitor the performance of individual MVC controllers and actions
- View MVC controllers as generic frontends in Team Center and WorkstationMetrics display under MVC | Controllers | <controller_name> in Workstation.
- Receive an alert set on the aggregated metrics under each controllerThe metric grouping and alerts are:
- MVC Controller Errors
- MVC Controller Response Time
- View the MVC\|Controllers\|[^|]+:Average Response Time \(ms\) differential analysis metric.
- View the .NET Version metric.The Metrics Tree location varies based on the ASP.NET MCV view (see next paragraph). The metric value displays the .NET/.NET Core version. For example, when you select the .NET Version metric at this location in the Metrics Tree:
this information displays at the bottom of the Metric Charts area:SuperDomain | .NET Process | <Process Name> .NET VersionSuperDomain | .NET Process | <Process Name> | .NET Version: 3
- Business Transactions matching for MVC
ASP.NET MVC provides these components:
- View engines, which are.templates for using varied web application presentation-layer syntaxes. The .NET agent monitors various ASP.NET Razor view-engine templates, providing Razor view engine performance metrics.Notes:
- MVC application Areas, which organize web projects by creating workable sections. The .NET agent monitors MVC Areas performance.
- Note:MVC Areas performance metrics reporting is disabled by default. You can enable the metrics reporting.
MVC-framework application metrics display in Team Center, as shown in the graphic.
Web API Support
The .NET agent supports monitoring of Web API-based application transactions to help you determine which tier is the bottleneck for a problematic transaction.
Supported Web API Versions
We support these versions of the Microsoft ASP.NET Web API:
- Microsoft ASP.NET Web API 4.0.30506
- Microsoft ASP.NET Web API 5.0.0
- Microsoft ASP.NET Web API 5.2.3
The .NET agent supports monitoring of Web API-framework applications, allowing you to perform these tasks:
- Use standard URL groups, and business transaction recording and decoding functionality
- Monitor the performance of individual Web API controllers and actions
- View Web API controllers as generic frontends in Team Center and Workstation Metrics display under WebAPI | Controllers | <controller_name> in Workstation.
- Receive an alert set on the aggregated metrics under each controller. The new metric grouping and alerts are:
- WebAPI Controller Errors
- WebAPI Controller Response Time
- View the WebAPI\|Controllers\|[^|]+:Average Response Time \(ms\) differential analysis metric
- Business Transaction matching support for Web API
Web API metrics display in Team Center, as shown in the graphic.
.NET Agent Monitoring in Your Application Environment
In your deployment, you install the .NET agent on each computer that runs an application you want to monitor. After the installation, the Microsoft Internet Information Service (IIS) controls the .NET agent. Until IIS receives a user request for an application, the .NET agent is not active. When the application code (.aspx, .asmx, for example) is exercised, the .NET agent starts and the NativeProfiler instruments the code.
How IIS Controls the .NET Agent
By default, the .NET agent only monitors applications that IIS manages and applications that are running under the IIS worker process. The following steps summarize how IIS controls the .NET agent and the instrumentation process when a .NET application starts.
- IIS receives a user request for an application.
- IIS starts the .NET worker process.
- The requested .NET application starts.
- The Common Language Runtime (CLR) starts the NativeProfiler.
- The NativeProfiler loads the .NET agent from the Global Assembly Cache (GAC).
- The .NET agent reads the IntroscopeAgent.profile to determine the PBL and PBD files to use for instrumentation.
- TheNativeProfiler uses the information in the PBL and PBD files to insert probes into the bytecode. The probes collect the appropriate metrics from application components. The application is instrumented.
- The instrumented application starts reporting metrics to the .NET agent.As long as the IIS worker process is running, the agent collects metrics and reports them to the Enterprise Manager. If the instrumented application stops experiencing user activity for a timeframe, the IIS worker process stops the application process. If IIS stops the application process, it effectively stops the .NET agent until user activity resumes.
Standalone applications that do not use ASP.NET can also be instrumented when the .NET agent is configured to do so. The IIS process for controlling the .NET agent is similar for standalone applications. However, steps 1 and 2 are skipped because the Windows operating system can bootstrap standalone applications.
.NET Agent Instantiation and the IIS Worker Process
You install a .NET agent on each system that hosts the managed .NET applications you want to monitor. At .NET agent startup, one agent instance is created for the CLR default domain. In addition, one .NET agent instance is created for each application running in the CLR.
This illustration shows a managed ASP.NET application. The application has one IIS worker process in each domain in which one .NET agent has been started:
This illustration shows the situation where multiple .NET applications are grouped in an IIS application pool. The application pool share a single worker process. The default domain has one .NET agent. Each application in the application pool also has a NET agent.
For scalability reasons, some organizations can assign multiple worker processes to a single application. Therefore, one .NET agent instance is created for the default domain. More domains are created for each worker process that is associated with the application. The following illustration shows the most common configuration.
When there are multiple worker processes, multiple .NET agents are associated with a single managed application. In this situation, configure those agents as a virtual agent. The configuration enables metrics from multiple physical .NET agents to be aggregated.
.NET Agent Instance in the Default Domain
A .NET Agent is always created for the CLR default domain. By default, the .NET Agent for the default domain does not connect to the Enterprise Manager. Therefore, the .NET agent does not appear as a node in the Metrics Tree in Workstation. However, you can configure the .NET Agent for the default domain to connect to the Enterprise Manager if necessary. For more information, see the agent property in Default domain configuration.