Web Server Logging, IIS logs, deployment slots and swaps

아티클
04/18/2018

I wrote a number of articles related to this topic, have a look to get a better context in regards to this one.

The following is a scenario I worked on, which was a little confusing, but understandable, nonetheless.

The misunderstanding was that when a production slot is swapped with a staging slot, the worker is not restarted and therefore, the production slot, after a slot swap is running in a different W3WP process. When the swap happens, the process does not change only the routing of requests changes. Because of that, you might see different information in your IIS / Web Server logs after a swap. Let me try to explain why now.

Production – Pre swap

This is how the configuration looked liked before I swapped my slots. As you can see in Figure 1, the Azure Blob Storage account is iislogs and the container is blackforest-iislogs. I also made this slot setting sticky. This means, when I swap, this setting will not be moved.

Figure 1, swapping slots and IIS Web Server logs Azure App Service

I look in KUDU/SCM and see the process user_name is BLACKFOREST, see Figure 2.

Figure 2, swapping slots and IIS Web Server logs Azure App Service, KUDU/SCM

I make some requests to the PRODUCTION slot and see that a folder named BLACKFOREST is created, Figure 3, which contains my IIS / Web Server logs.

Figure 3, swapping slots and IIS Web Server logs Azure App Service

Then, looking into the logs I see that the s-sitename is also BLACKFOREST. *NOTE – the s-sitename with the tilde “~” is a request to the KUDU/SCM site.

 
#Fields: date time s-sitename
2018-04-18 10:45:29 BLACKFOREST GET
2018-04-18 10:42:36 ~1BLACKFOREST

No let’s look at the staging slot.

Staging – pre swap…

This is how the configuration looked liked before I swapped my slots. As you can see in Figure 4, the Azure Blob Storage account is iislogs and the container is blackforest-iislogs-staging. I also made this slot setting sticky. This means, when I swap, this setting will not be moved.

Figure 4, swapping slots and IIS Web Server logs Azure App Service

I look in KUDU/SCM for the staging slot and see the process user_name is BLACKFOREST_2DC8, see Figure 5.

Figure 5, swapping slots and IIS Web Server logs Azure App Service, KUDU/SCM

I make some requests to the STAGING slot and see that a folder named BLACKFOREST_2DC8 is created, Figure 6, which contains my IIS / Web Server logs.

Figure 6, swapping slots and IIS Web Server logs Azure App Service

Then, looking into the logs I see that the s-sitename is also BLACKFOREST_2DC8.

 
#Fields: date time s-sitename
2018-04-18 10:49:53 BLACKFOREST__2DC8
2018-04-18 10:50:15 ~1BLACKFOREST__2DC8

No let’s do a swap.

After the slot swap

The Application Setting is sticky to the slot and therefore when I swap I would expect the Application Setting “WEBSITE_HTTPLOGGING_CONTAINER_URL” not to change. Let’s confirm.

It did not change, it remained the same as is seen in Figure 1 and Figure 4.

However, now my production slot is running with a user_name value of the previous staging slot, I saw this by logging into the PRODUCTION KUDU/SCM site and I see the following, Figure 7, in Process Explorer.

Production after swap with staging

Figure 7, swapping slots and IIS Web Server logs Azure App Service, KUDU/SCM

Additionally, when I look at the storage container, I see a new folder which matched the user-name, Figure 8.

Figure 8, swapping slots and IIS Web Server logs Azure App Service

This means that Web Server / IIS logs are being written into that folder and the s-sitename in the log file contains the same name too, I.e. BLACKFOREST_2DC8.

Staging slot after the swap with production

You see the same when accessing the staging slot, it is now staging, but has a user_name of BLACKFOREST, Figure 9.

Figure 9, swapping slots and IIS Web Server logs Azure App Service, KUDU/SCM

And, as expected, a directory named BLACKFOREST is existing in the storage container, Figure 10.

Figure 10, swapping slots and IIS Web Server logs Azure App Service

If you are doing analysis of your IIS / Web Application logs, then you need to keep this in mind if you use s-sitename as a filter. You might instead consider using cs-host.

다음을 통해 공유