In the first part of this series, we talked about the relation between Sitecore.Diagnostics.Log, Log4Net and Microsoft’s Logging Abstractions with ILogger.
Let’s take things a step further and have a look at the logging mechanisms in Azure PaaS.
In our PaaS solutions we can use Application Insights to diagnose our applications. In application insights we have the ability to store different events. Two of those events are touching the logging: “Exception” and “Trace”. “Exception” events are also used for failure diagnostics. “Trace” are just traces and have no influence in performance, availability and failure metrics.
Information from different services can be collected into one application insights account.
Application Service Logs
On the other hand, we have the application service logs on our different services. Each service has its own application service logs. These logs are divided into the application logs (containing logging from your application) and the web server logs (containing request info). In this article we will focus on the application logs.
The application logs can be written to the filesytem or Azure blob storage. You can also temporary enable logging to the log-stream in order to see the live logging from your application. The output channel of the logs, as well as the logging level can be switched on the fly without recycling your application.
In order to get our logging into the Azure Application Logs, we need to use the System.Diagnostics.Trace logs.
System.Diagnostics.Trace is the most lowlevel type of logging embeded into .NET. It’s a tracelistener that receives output and sends it somewhere else. There are different tracelisteners that can be used.
- The DefaultTraceListener will log into your visual studio editor. On Azure PaaS the DefaultTraceListener will log into the application logs.
- Other option is the TextWriterTraceListener to log to files.
- The EventLogTraceListener will log to the eventlog.
It is also possible to write and attach your own custom tracelistener.
Sitecore and Logging in Azure
In our applications, we never use System.Diagnostics directly to take care of our logging. So, how does Sitecore make sure that our logs end up in either Application Insights, Application Service logs or both?
In the previous post, we already determined that all logging in Sitecore (Sitecore.Diagnostics, Microsoft ILogger, Log4Net) channels into Log4Net. The key here is that the Log4Net appender used in Sitecore on Azure PaaS is replaced by the “LevelTraceAppender” from the Sitecore.Cloud.ApplicationInsights package. This appender inherits from the Log4Net TraceAppender that will not write to files but it will write to System.Diagnostics.Trace. Thus, the logs on Azure will be channelled into the Azure Application Logs (in the log stream, files, or azure blob).
Now that our (Sitecore) logs are ending up in the Application Logs of Azure, we are still missing the final link of getting these logs into a trace event in Application Insights. This is done with an additional listener of the System.Diagnostics. The ” Microsoft.ApplicationInsights.TraceListener.ApplicationInsightsTraceListener” is added as a listener through web.config configuration. This listener uses the ApplicationInsights TelemetryClient to write the logs also to ApplicationInsights.
Since Sitecore 9.2, the new applicationsetting “UseApplicationInsights” was added. This is by default set to true. The effect of enabling this setting is that a new log4net appender “Sitecore.Cloud.ApplicationInsights.Logging.Log4NetAppender” is used instead of “LevelTraceAppender”. This appender no longer writes to System.Diagnostics.Trace but directly to ApplicationInsights using the TelemetryClient.
So, this makes it kind of confusing because setting “UseApplicationInsights” to false will keep using the LevelTraceAppender and thus write to Application Logs and ApplicationInsights.
So, should you disable the UseApplicationInsights flag? I would definitely say YES! Application Insights is a great tool to detect trends and structural errors in your application as it has search and aggregation capabilities, however if you want to tackle a specific reproducible scenario, a chronological log file of direct console logging is way more effective to solve your problems. And with UseApplicationInsights flag set to false, you still have your logs in Application Insights.
In my opinion, I would even prefer to create yet another Log4NetAppender that writes to System.Diagnostics as well as to AppInsights directly. I would even make sure that logging of exception would not go into the trace category, but end up in the Exception category in order to have better diagnostics in AppInsights.