Web Role Logging - Nlog - Configuration File Access
At the beginning of a web application project, I decided to use Nlog as my logging solution, and I really like the idea of just calling the log class in my code and then deciding at runtime what to log where. We then decided that this application should be hosted on Windows Azure in a web role to take advantage of all these offerings. Now I understand that Nlog will not work the way I imagined it. Here are the questions related to the change:
- It cannot connect to the text file in the standard log folder because the folders are read-only and even if they were not, they will be instance specific and not persistent due to the way instances and instance local storage are provided and will disappear when disposed of.
- Since these configuration files are read-only, I cannot take advantage of Nlog's most powerful feature, which is the ability to determine at run time how to configure the output.
I found several solutions to the log problem. Either configuring the login target for the Azure Diagnostics table or the role table store. While this may be the way we do it, it seems very limited because it seems like you can only log into one table (diagnostics or custom table for a role). Does anyone know of a better solution? Logging into an AzureSQL database would be too expensive.
Also how can I configure Nlog if I want to temporarily log the database or SMS, email, etc. if I can't edit the config file. I know you can store information in the ServiceConfiguration.cscfg file and it is available and editable at runtime, but AFAIK that is not an option for Nlog configurations. Is there a way to edit the deployed web.cfg or Nlog config file for all instances?
Because of these limitations, would it be better to move away from using Nlog and go with a different, more compatible way of logging?
source to share
Richard,
For the first problem, you can configure a local storage resource to store log files. You can configure the local resource to not clean up when the role is reloaded, which helps your logs live long enough to be useful.
I don't think storing the logging configuration in a .cscfg file is a good way to go unless you have a management solution that lets you update all configurations at the same time. Your best bet is to have a config file in your blob store and then check the process to see if the blob has changed. If there is one, download the file and use it.
Eric
source to share
I know this is a bit old question, but I'll drop my two cents.
We use logentries.com to keep our logs. The free tier stores your data for a week, which is enough for us. We keep the logger configuration in a separate log file, but we never had to change the log configuration files during deployment.
And just today I stumbled upon a project that allows you to store a nlog config file in .cscfg. I haven't tried this myself yet, but I will give it away for a new project. Here is the link: NLog.Config.Azure
source to share