Application Insights Integration with Function Apps in Azure Government or other Clouds

The use of the APPLICATIONINSIGHTS_CONNECTION_STRING in Azure Functions is now built into the runtime. Note my examples are for Azure US Government cloud but this can ultimately be used in any cloud with the correct endpoints specified.

********Update 4/28/2020********
The Application Insights product team updated the certificate so you can now use the following connection string format without having to add any additional configurations for LiveStream. This configuration only works with V2 and V3 function apps. Here’s the work-item tracking V1 integration.
https://github.com/Azure/azure-webjobs-sdk/issues/2284

Name: APPLICATIONINSIGHTS_CONNECTION_STRING
Value: InstrumentationKey=xxxxx;EndpointSuffix=applicationinsights.us;

How to Configure the settings

The option for a connection string is available in the Azure Portal under the overview blade of the Application Insights resource. Create a new app setting or entry in the localsettings.json for local development with the name APPLICATIONINSIGHTS_CONNECTION_STRING and the value below. My example is for US Government Cloud. Also note you’ll need to add the last entry in the connection string for LiveEndpoint:

InstrumentationKey=xxxxx;EndpointSuffix=applicationinsights.us;

InstrumentationKey=xxxxx;EndpointSuffix=applicationinsights.us;LiveEndpoint=https://quickpulse.applicationinsights.us/;

Ref:
Connection String Overrides: https://docs.microsoft.com/en-us/azure/azure-monitor/app/sdk-connection-string?tabs=net#connection-string-with-explicit-endpoint-overrides
Cloud override values: https://docs.microsoft.com/en-us/azure/azure-monitor/app/custom-endpoints#regions-that-require-endpoint-modification

No longer relevant but an interesting scenario………Troubleshooting Steps Leading up to the Solution

When the version of the Azure Function Runtime supporting the AI connection string was released to the Azure Government Cloud it allowed customers to not have to rely on dependency injection to integrate their app with application insights in the Government Cloud. For customers using any other language they would either have to use “hacky” workarounds with DI or rely on AI in the Public Cloud.

After the release, everything worked out of the box besides Live Stream (both locally and when deployed). Its not a deal breaker for all customers that it didn’t work, but it limits the ability to get a quick overview of how the function is running without querying multiple tables or viewing multiple graphs.

Troubleshooting Steps:

1. The majority, if not all, of all application insights data is sent via HTTP client. So the easiest way to debug HTTP requests is using Fiddler. In Fiddler, there were no requests from the func.exe process to live.x.us or quickpulse.x.us (x being any domain) as mentioned in the documentation. Therefore its assumed that no data bound for the Live Metric Stream is leaving the machine.
   
2. Remote debugging: In order to remote debug the AI SDK (which is open source) the version of the AI SDK associated Azure Function Core Tools could be found in the the C:\Users\xxx\AppData\Local\AzureFunctionsTools\Releases\ directory. Next the solution had to be compiled in debug mode and subsequently drop the debug versions of the dlls + respective PDB files in the bin directory of the core tools. Lastly in the AI SDK I identified where the Quickpulse client was being created. The same exercise can be done within an Azure Function App in Azure by using a private site extension which would include the debug versions of the respective AI SDK dlls+PDB files.
   
3. Next I fired up the runtime, attached the debugger the func.exe process, and set the breakpoint in the QuickPulseServiceClient.cs. Lo and behold an SSL exception “The SSL connection could not be established” with the inner exception of “The remote certificate is invalid according to the validation procedure”.
   
   In looking at the endpoint live.applicationinsights.us we can see the DNS name resolves to the correct IP but the certificate being returned is for live.applicationinsights.azure.us and there is no SAN for that domain.
   
   
   
   
   
   
4. Since the issue was now identified, the next step was confirm how to modify the SDK from using live.applicationinsights.us to live.applicationinsights.azure.us or the documented way of using quickpulse.applicationinsights.us. This proved pretty simple based on the following documentation. The last step needed was to override the default setting live.suffix to the exact URL desired by appending LiveEndpoint=https://custom.com to the end of the connection string.

So the conclusion of this exercise came down to one small change to the connection string to force the Live Metric Stream to use the correct URL.