Verify that App Services slot swaps are being detected in Web SDK #872
Comments
|
See PR Azure/azure-webjobs-sdk#1382 for further detail. |
Add heartbeat provider for Azure App Services (in particular, Web Apps) that will add some infrastructure-identifying properties. - Solves issue #648, #868, and #872. - Both `AzureWebAppRoleEnvironment` and `AppServiceHeartbeatTelemetryModule` need to update their telemetry cache whenever the environment chances (ie, slot swap). `AppServiceEnvironmentVariableMonitor` solves this. - Keep the value of WEBSITE_SITE_NAME and other App Services values current during runtime - Merge PR #870 and #869, regarding heartbeat providers for App Services - Ensure adequate testing is added, update current Env Var tests to be testable in a parallel environment - `EnvironmentVariableMonitor` only updates the environment variables at set intervals, its subscribers only update when they need to. - Disable monitor if we don't detect that we are in Azure App Service environment, and on SecurityExceptions, disable the monitor altogether
|
@d3r3kk will you be able to test this next week? |
|
Will investigate by EOD tomorrow. |
Environment values investigationCan we use the environment to detect slot-swaps in Application Insights? tl;dr No, we cannot. The environment variables on the host are not propagated to the process after a slot swap. Findings at RuntimeWhat does the environment say in a demo app?The environment variables are not updating how we need them to, in order to detect slot - swaps. Here's the variables in the 'dev slot' when I deploy my app into the DEV environment in my release definition in VSTS:
And here's the values again after swapping the slots, my demo app is now in the 'production' slot:
Notice that the WEBSITE_HOSTNAME is the url to the dev slot of the site I created, and that no value changed at all. Peek Under the HoodWhat is very odd to me, is that the underlying system seems to have different values for these variables! Here's the values from both of the slot's kudu site, from the Environment Variables section:
SummarySo our current attempt to fix up this issue, inspired in part by the Azure Functions team's use of a special environment variable 'WEBSITE_SLOT_NAME' didn't pan out. No environment variable is currently giving us any indication of the slot the app is running in, and we will have to use some other method to detect when this happens. TODOAsk the Antares team if they plan on supporting the update of the environment variables we want to rely on for this. If environment variable updates won't get updated: Remove the Environment variable monitor & subscription model, and investigate further to find a better way to detect slot swaps. Perhaps using request headers or some other more definitive way exists (we could repurpose the environment variable monitor to be a request-header-value monitor). |
|
Note that this does not impede the app2infra scenario for Web Apps. |
There is some concern that slot swap detection is not reliable in the Web SDK for App Services. We have seen evidence that the slot swap was not being detected properly in Azure Functions, and we must ensure that other App Services (Web Apps, for instance) are not affected in the same way.
See comments in PR #870 regarding the use of WEBSITE_HOSTNAME for further insight & details.
Repro Steps
Actual Behavior
TO BE VERIFIED
Expected Behavior
The nodeName property of application insights telemetry will update to reflect the correct slot name within 30 seconds of the slot change.
Version Info
SDK Version : latest beta.
.NET Version : 4.5 (.NET full framework) or 1.3 (.NET Standard)
Hosting Info (IIS/Azure WebApps/ etc) : WebApps
The text was updated successfully, but these errors were encountered: