Recently, I went to investigate an issue in an Azure Function, and noticed that some entries I would have expected to be present were missing. This is related to differences between the default settings of Azure Functions and other App Services, and also differences between the structure of host.json (used by Azure Functions) and appsettings.json used by other .net core applications.
There was an obvious difference between the entries that were appearing and others that were not. Any traces written within the scope of the main Run() function appeared with no problem, but any traces from other namespaces called by the Run() function didn’t appear.
Unlike some other types of .net core project, Azure Functions filter out logs from other sources by default. If you want to include logs from other namespaces, you have to add some configuration in host.json.
If you don’t add this section for the namespaces you need, their log entries will be filtered out by default. For other types of service like .net core App Services, which use appsettings.json, the default settings seem to allow logging from most namespaces.
I fell for a bit of a gotcha here because host.json is structured very similarly to appsettings.json (used by other .net core projects). Note that in Azure Functions host.json, the “logLevel” node must appear as a direct child of the “logging” node as shown above.
In similar appsettings.json files, it would have been a valid alternative to specify logLevel inside the section for a specific provider (i.e. inside the “applicationInsights” section in the screenshot above). But this does not work for host.json.