When hosting an Umbraco website, Microsoft Azure Web Apps offers an easy platform for hosting. It's easy to provision a new website and you don't need to keep track of server updates or maintenance, as that is all taken care of by the Azure team.
The ease to scale a website from a simple (and cheaper) shared server plan to a highly-powered dedicated server environment makes it great way to keep your website performing well when it grows over time.
One of the packages that I tend to install as one of the first things for any new Umbraco website is Dan Booth's excellent Diplo Trace Log Viewer. It gives you the option to view the Umbraco trace logs from within the developer section of the back office. This is especially useful when hosting on Azure Web Apps, as that does not give you the option to RDP onto the server and view the log files on the server itself.
A little while ago when I had a website up and running on the Azure Web Apps Shared plan, I noticed something in the list of available trace logs:
As you can see there are about 11 entries for 2016-05-09.
At first this kind of baffled me.
Was it maybe a bug in the trace log viewer package?
Or could it be that Umbraco is generating duplicate log files for some reason?
But if that was the case, how would that be possible since the log file names would have to be unique?
I decided to FTP onto the server (which you can do with Azure Web Apps) and have a look at the log file directory.
When looking at the log files I noticed two things:
- That the log file names are formatted as UmbracoTracelog.[machine name].txt.[date].
- That there are log files with different machine names, but for the same date.
I always had thought that the log files were saved in the UmbracoTracelog.txt.[date] format.
But after looking through the log4net config file I noticed the machine name of the host was now also being added.
After a bit of digging through the Git history of the log4net config file in the Umbraco repository I noticed the format had changed around the release of Umbraco v7.3. Both the related ticket on the issue tracker and the commit message didn't give me many clues on why this was changed.
But I can have a guess at the reason: when you're running an Umbraco site on a load-balanced environment with multiple servers and you encounter an error which relates to the server configuration (file write permissions, for example) it's incredibly useful to know on which server the error occurred.
Now that's all well and good when you control the server environment, and your servers won't change very often. But what if you don't control those things?
So when I saw the list of log files with different machine names, I noticed a few things:
- The server seemed to change every few days (sometimes even multiple times on the same day).
- There seemed to be a cycle where the same few servers were being reused over a period of time.
As I mentioned before, this website was using the Shared plan on Azure. This means that the website is running on a shared virtual machine (VM) together with other websites. You don't get to choose the server, but Azure assigns this for you.
I've not been able to find anything in the Azure documentation on what happens exactly, but some sources seem to suggest that your website might move from one server to another when the Azure VM gets updated or when the VM's performance degrades too much (which could be caused by one of the other websites that share the same VM as yours). This move happens automatically and you shouldn't notice any downtime.
So that would explain why I saw the server moves every few days. And I suspect when the websites get moved to another VM, the old one gets re-provisioned and put back into the pool (hence why it reappears again in the log list after a while).
Since this happens beyond my control and it creates separate Umbraco trace log files which look a bit confusing in the back office, I decided to make one simple change to the log4net config file:
<file type="log4net.Util.PatternString" value="App_Data\Logs\UmbracoTraceLog.txt" />
This basically reverts the change of adding the machine name into the trace log file name. That means all trace logs for a day will now end up in a single log file and it keeps everything together for easier viewing and diagnosis in the trace log viewer.
And so it gives us a way of keeping track of the Umbraco trace logs when hosting on Azure Web Apps on a shared VM.
Turn off Application Insights for your dev environment
Application Insights is a great way to track a website's performance, but I was after a setup that allowed me to disable this on my dev environment and make sure it's enabled on live.Read more
Updating Azure CDN files through continuous integration
My experience of setting up Azure CDN on this site and fine-tuning it to automate the deployment of static files during the build process on Visual Studio Team Services.Read more