If you use Azure Web App Deployment Slots then you may have noticed that sometimes the swap action may take a while to complete. This may happen when an application that is being swapped into production has a long warmup/initialization phase. It has to be warmed up on every VM in an App Service Plan and that sometimes takes minutes (more detailed description of what happens during the swap can be found in Most common deployment slot swap failures and how to fix them). This blog post explains how to see the progress and the result of the swap operation in the Azure Activity Log.
To see the swap operation events use the Activity log view in the Azure Portal:
Here is an example of how the swap events look like:
- ApplySlotConfig – this is logged when slot settings from production slot have been applied to a webapp in the staging slot
- StartSlotWarmup – this is logged when starting to initialize the webapp in the staging slot
- EndSlotWarmup – this indicates that the webapp initialization has completed
- SlotSwap – this is logged when the webapp from the staging slot has been swapped into production slot.
If there was a failure while swapping the slots then the events will look like below. The event description will have explanation of why the failure occurred.
If you use PowerShell then you can get the swap related events by using this command:
Get-AzureRmLog -ResourceGroup slotswaptest -StartTime 2018-03-07 -Caller SlotSwapJobProcessorThis will produce an output as below:
(For more information on how to get Activity Log events via Powershell refer to View activity logs to audit actions on resources)
If you prefer to call the Azure API’s directly (or by using ARMClient tool) then you make a request like below:
ArmClient.exe GET "//providers/microsoft.insights/eventtypes/management/values?api-version=2015-04-01&$filter=eventTimestamp ge '2018-03-07T00:00:00Z' and eventTimestamp le '2018-03-08T23:00:00Z' and resourceGroupName eq 'slotswaptest'"In the response look for events that have Caller property set to “SlotSwapJobProcessor“.
Nice article, but has nothing to do with IIS and yet it’s on the front page news of IIS.net?
@EZ, I’ve contacted iis.net to modify the RSS rules they use for aggregation. Thanks for letting me know.
Not seeing these Activity Log items for slot swaps any more. All we see are “Microsoft.Web/sites/slots/write”
Hi Duncan. Thanks for letting me know. Looking into this.
Found the bug that caused this. It will be fixed within next week. Thanks again for reporting this!
Thanks. Wondering if it fixes the monitoring the swap operation using the technique here https://github.com/projectkudu/AzureResourceExplorer/issues/52 – we get the OperationId back from MSDeploy (“Info: Finished publishing with auto-swap enabled: SlotName=production, OperationId=ca4e59c0…”) and use this to ping “/operations/{OperationId}” and get 202 Accepted until the swap is complete and we get 200 OK. This stopped working around the same time (sometimes it works, mostly doesn’t).
A late note on this. We have been using this method for verifying auto-swaps in our deployment pipeline for some time now, but in the last few months have found that the SlotSwapJobProcessor log entries have been taking longer and longer to appear, with it now commonly taking over 15 minutes for the logs to be updated with activity that has taken place on Azure.
This has caused us ongoing issues in our deployments – failures due to ‘missing’ log entries – and means we now have to retry our Get-AzureRmLog requests for a long time until we finally see the results we expect. Not great in terms of reporting actual issues back quickly.
I’m currently investigating alternative approaches to verifying auto-swap success/failure as a result, having not got much joy from Microsoft investigations into why this is now happening. Which is a shame, as this worked well for a good while.