I have an Azure Function that exhibits some unexpected logging behavior. The host.json
file is this:
{
"version": "2.0",
"logging": {
"fileLoggingMode": "never",
"logLevel": {
"default": "Information",
"Function": "Information",
"Host": "Warning",
},
"applicationInsights": {
"samplingSettings": {
"excludedTypes": "Exception"
}
}
}
}
With that configuration, I expect that no Debug log messages will show up in App Insights. But what we're seeing is that calls to logger.IsEnabled(LogLevel.Debug)
returns true (where logger is an ILogger
). A package we're using has some expensive log message construction that's wrapped in the IsEnabled
calls, but that code is being called even with the configuration above.
This only happens in Azure; when running locally, we don't see the same behavior.
How can we configure the logging in Azure so that IsEnabled(LogLevel.Debug)
returns false?
I use the same host.json as yours.
At first, I face the same situation as yours.
Then, I simplified the host.json file.
This is my function code:
and this is my host.json file:
On local, how you set it will have corresponding results. For example, if you set the loglevel to error, then the information of Information level will not be returned when the trigger is triggered. As shown in the following figure, the Information prefix is not displayed locally, but the Information prefix is displayed when running on the portal. Executing and Executed are Information level.
Locally, setting other loglevel levels can only get the return value of 'Value is false', and only returns 'Value is true' when the loglevel is set to 'debug'.
Then I try to publish this function to Azure with loglevel equals to information. Then I found the function return 'Value' is true'. It's weird, so I try to change loglevel to error, then I found out that no information was displayed in the logstream that was originally used to display information level information. This shows that the setting of the error level is valid. But the trigger still returns 'Value is True'. So you can only think that Azure forces each Function to retain the Debug level regardless of the access level set.
This may be a bug, because there seems to be no other way to set the access level, no matter how you set it, the debug access level is always retained.