Removing the appinsights profiler from a app service plan

Question

I'm currently experimenting with the new beta asp.net core app insights profiler.

However I see the error message:

2019-02-11T11:36:22 PID[6036] Information 02-11 11:36:22 Error: Unexpected exception in agent main process. Details: Microsoft.ServiceProfiler.Utilities.AppIdNotFoundException: Unable to find AppId for iKey

In the diagnostic logs.

Asking the question on github https://github.com/Microsoft/ApplicationInsights-Profiler-AspNetCore/issues/36, I was kindly informed that it's likely due to the old profiler becoming active and given some hints upon how to disable it.

Setting APPINSIGHTS_PROFILERFEATURE_VERSION to disabled unfortunately didn't work for me (though might be due to my particular ARM template setup).

Instead disabling via Kudu was what helped me (as I need to do it as part of a release pipeline):

score 1 · Answer 1 · answered Feb 13 '19 at 21:17

1

ApplicationInsightsProfiler2 webjob is installed by an old Application Insights Site Extension. To properly remove it you need to remove the ApplicationInsights extension from the "Extensions" blade inside the App Service page.

If that doesn't work (you don't see the ApplicationInsights extension) it's possible the uninstall failed silently but the bits are still there so you'd have to manually remove it by following the steps here.

The GitHub comment is referring to the new enablement flow (from the "Application Insights" blade inside the App Service page) that installs a web job called "ApplicationInsightsProfiler3". If you only have this web job, turning it off from the Application Insights UI will work - you don't need to manually set App Settings.

answered Feb 13 '19 at 21:17

Claudiu Guiman

837
5
18

Thanks Claudiu, that's good to know, I did see mentions of v3 in the docs which intrigued me... In theory the resource group was new without the extension installed, perhaps it was installed by accident via the portal. Are there particular enablement flows for v2 I need to be wary of? I'm looking to automate disabling of old profilers, would you suggest in my powershell changing ApplicationInsightsProfiler2 to 3? Or is disabling the webjobs / extensions during release a foolhardy endeavour as they could be enabled by accident in the portal anyway? – Alex KeySmith Feb 14 '19 at 10:10
The old extension can only be enabled if you: 1. install it from the "Extensions" blade 2. install it with an ARM template 3. use an old version of VisualStudio (< 15.9.2) and check "enable extension" when deploying. The new enablement (You might see people refer to it as preinstalled site extension) is done only from the "ApplicationInsights" blade or from new versions of VS (>=15.9.2) and results in a bunch of App Settings being written (one of which is the APPINSIGHTS_PROFILERFEATURE_VERSION). – Claudiu Guiman Feb 14 '19 at 14:53
I wouldn't worry too much if the web job is still there. You can always disable it (read as it still runs, but it doesn't send any data) APPINSIGHTS_PROFILERFEATURE_VERSION = disabled – Claudiu Guiman Feb 14 '19 at 14:54
Thanks for the detailed comment, that's useful to know about how the extensions are enabled. I suppose for me it was adding quite a bit of noise in the logs as it couldn't find "APPINSIGHTS_INSTRUMENTATIONKEY". I did try version = disabled, but understanding more now, it sounds like the webjob kept running and looked for the key, but even if the key were there the "disabled" flag would of meant it wouldn't send anything. I wonder if to use a resource write lock to stop accidental enabling of the runtime extension / old profiler... but perhaps a question for another day. – Alex KeySmith Feb 14 '19 at 17:00

score 0 · Answer 2 · answered Feb 13 '19 at 11:18

I used the following powershell, after digging into the kudu wiki and replacing a few elements with newer techniques.

It composes a "http basic authentication" string using the publishing credentials acquired from the site and then uses this to issue a DELETE request to the kudu api.

Notably if you were using Powershell 6, you wouldn't need to compose the Basic authentication string, as powershell 6's Invoke-RestMethod can do this for you.

function Get-KuduSiteBasicAuthString
{
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        $ResourceGroupName,

        [Parameter(Mandatory = $true)]
        $Name
    )

    $response = Get-AzureRmWebAppPublishingProfile -ResourceGroupName $ResourceGroupName -Name $Name

    $publishingCredentials = [xml]$response

    $username = $publishingCredentials.publishData.publishProfile[0].userName
    $password = $publishingCredentials.publishData.publishProfile[0].userPWD

    $credentialsString = "{0}:{1}" -f $username, $password

    $credentialsAsByteArray = [Text.Encoding]::ASCII.GetBytes($credentialsString)

    "Basic {0}" -f [Convert]::ToBase64String($credentialsAsByteArray)
}

$ResourceGroupName = "your resource group name"
$ApplicationName = "your app name"

$kuduAuthString = Get-KuduSiteBasicAuthString -ResourceGroupName $ResourceGroupName -Name $ApplicationName

$apiUrl = "https://" + $ApplicationName + ".scm.azurewebsites.net/api/continuouswebjobs/ApplicationInsightsProfiler2"
Invoke-RestMethod -Uri $apiUrl -Headers @{ 'Authorization' = $kuduAuthString } -Method Delete -Verbose

Removing the appinsights profiler from a app service plan

2 Answers2