Microsoft Docs: App Service Overview
Azure App Service is a PaaS offering in Azure and provides hosting of web applications and sites as well as a Site Control Manager (SCM, also known as Kudu that provides administrative and management capabilities.
In addition, there exists a notion of Site Extensions which provide powerful customizable behaviors for the web app. This customization is done through a mechanism in IIS called xdt transformations.
App Services are hosted by Azure VMs with both Windows and Linux flavors. Currently, only App Service on Windows supports Site Extensions.
The CLR Instrumentation Engine is currently shipped in the form of a Preinstalled Site Extension on every Azure App Service instance.
A private site extension is a nuget package that can be manually installed by the site owner from the site extension gallery in Kudu into the %HOME%\SiteExtensions folder. Once installed, the binaries and files of the private site extension can be manipulated and modified easily.
A preinstalled site extension is a folder that is shipped directly by the Kudu team into the %ProgramFiles(x86)%\SiteExtensions folder on every Azure App Service machine and is enabled through the Azure App Service Application Settings. These files are restricted to read-only access and cannot be modified.
When a private site extension is installed or a preinstalled site extension is enabled, the applicationHost.xdt file in that site extension is consumed by the web app process during startup. This xdt file transforms the application's web.config like providing environment variables. Some site extensions also provide an scmApplicationHost.xdt file which is consumed by and transforms the Kudu process.
Details for CLR Instrumentation Engine environment variables can be found at Environment Variables.
In order to enable the CLR Instrumentation Engine preinstalled site extension, go to your Azure App Service resource in the Azure Portal and add the below setting to the Application Settings (Currently there's a bug where different components set the key with different casings and producing 409 conflict errors):
| Key | Value |
|---|---|
InstrumentationEngine_EXTENSION_VERSION |
~1 |
This will enable the latest version 1.x of the CLR Instrumentation Engine preinstalled site extension. Please see Kudu Site Extensions for details on how the version values work.
Please note that applicationHost.xdt files for enabled preinstalled site extension are processed before any private site extension.
If you ship a private site extension and want to use Instrumentation Engine cooperatively, the following environment variable in Azure App Service will be enabled in ANT91 (2020, late-Oct/early-Nov):
MicrosoftInstrumentationEngine_LatestPath = D:\Program Files (x86)\SiteExtensions\InstrumentationEngine\[LATEST VERSION]
Where [LATEST VERSION] represents the latest available version of the InstrumentationEngine preinstalled site extension.
In the private site extension's applicationHost.xdt, you can leverage this environment variable in the following way, note that each of these are set as InsertIfMissing to avoid conflicts if the InstrumentationEngine preinstalled site extension is enabled.
<!-- .NET Framework -->
<add name="COR_ENABLE_PROFILING" value="1"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="COR_PROFILER" value="{324F817A-7420-4E6D-B3C1-143FBED6D855}"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="COR_PROFILER_PATH_64" value="%MicrosoftInstrumentationEngine_LatestPath%\Instrumentation64\MicrosoftInstrumentationEngine_x64.dll"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="COR_PROFILER_PATH_32" value="%MicrosoftInstrumentationEngine_LatestPath%\Instrumentation32\MicrosoftInstrumentationEngine_x86.dll"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<!-- .NET Core -->
<add name="CORECLR_ENABLE_PROFILING" value="1"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="CORECLR_PROFILER" value="{324F817A-7420-4E6D-B3C1-143FBED6D855}"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="CORECLR_PROFILER_PATH_64" value="%MicrosoftInstrumentationEngine_LatestPath%\Instrumentation64\MicrosoftInstrumentationEngine_x64.dll"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="CORECLR_PROFILER_PATH_32" value="%MicrosoftInstrumentationEngine_LatestPath%\Instrumentation32\MicrosoftInstrumentationEngine_x86.dll"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
We also recommend enabling Error logging. These will report to D:\Home\LogFiles\EventLog.xml.
<add name="MicrosoftInstrumentationEngine_LogLevel" value="Errors"
xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
The CLR Instrumentation Engine is not shipped as a standalone private site extension. Instead it is currently available as part of the Application Insights private site extension and will be enabled as part of the Application Insights applicationHost.xdt file.
In order for the Instrumentation Engine to pick up your instrumentation method, you will need to declare environment variables that point to a *.config file which references your instrumentation method assembly.
Please see Configuration for details about the config file and environment variables.
Please see Build to build the CLR Instrumentation Engine binaries locally.
If you would like to test your changes in your Azure App Service, it is recommended that you either install the Application Insights private site extension and patch or create a custom private site extension with an applicationHost.xdt file that enables the required environment variables. You will not be able to patch the preinstalled site extension.
Ensure that the CLR Instrumentation Engine preinstalled site extension is not enabled when working with private site extensions.
Microsoft Docs:
Azure Virtual Machine (VM) and Virtual Machine Scale Sets (VMSS) are IaaS offerings in Azure that provide users with a virtualized computer running in Microsoft's Azure datacenter. The level of customization and control for VM/VMSS is much greater than App Service, meaning a wide variety of applications and types of apps can be hosted.
Azure VM and VMSS support a notion of extensions, such as the Remote Debugging Extension and the Azure Diagnostics Extension
Although Azure VM and VMSS host both Windows and Linux OS images, CLRIE distributions currently only target Windows images.
CLRIE is deployed in the Azure Diagnostics Extension (commonly referred to as the Windows Azure Diagnostics or "WAD" extension). The Visual Studio Snapshot Debugger and Time Travel Debugging features leverage CLRIE by deploying and configuring WAD.
Since CLRIE is also packaged in an MSI/MSM, there are tasks to move WAD to install the MSI/MSM rather than shipping CLRIE dlls directly, which will help further the cooperation model by allowing users to use Microsoft products and features alongside 3rd party profiling tools and extensions.
Microsoft Docs: AKS Overview
AKS provides a managed Kuberentes cluster in Azure. Kubernetes is a container-based distributed platform for providing reliable and fault-tolerant infrastructure.
Currently, CLRIE is leveraged by Visual Studio Snapshot Debugger on AKS Linux (Alpine & Ubuntu) Docker Containers and requires manual configuration by users. More details can be found at vssnapshotdebugger-docker repo on GitHub.
Application Insights is supported in numerous configurations across a multitude of Azure platforms with various features, some of which leverage CLRIE and some do not.
See Application Insights Overview
Also refer to Application Insights extension design specs
The Visual Studio Snapshot Debugger allows users to set snappoints and logpoints (similar to breakpoints) in order to generate snapshots or on-demand logging against their production applications with minimal impact.
See Debug a live Azure app for more details.