Azure Functions CLI - such a pretty logo for such an awesome functionality

How to enable verbose logging for Azure Functions?

Reading Time: 3 minutes.

This post describes how you can easily enable debug/verbose information for your Azure Functions for a lightweight and built-in way to extract just a bit more information out of your Azure Function executions.

There’s different methods available for Azure and your local development environment.

Problem

Azure Functions are awesome. But by default, your tools on gathering information without some additional configuration are not that great. The “monitor” view of the function doesn’t give you more than an excerpt of the console.

This applies not only to the “production” Azure cloud environment, where the function invocation log is very concise, and even Kudu exposes very simple logging information. Additionally, this applies pretty much completely to your local development environment as well!

However, you can extract a bit more information by enabling verbose logging. Sometimes that might be just enough to get that additional tidbit of information, that’ll help you figure out the issue!

Solution

Okay – so it’s a minor improvement, but worth documenting. Changing your host.json file for your Azure Functions app (local or in Azure Functions app) allows you to enable verbose logging for your functions.

Solution for Azure: Modify the host.json file in the cloud

You’ll need to add this to the host.json file:

{
  ...
  "tracing": 
  {
   "consoleLevel": "verbose"
  }
}

To do that, you’ll need to access the file system of your (Functions) app service. You can get there by following this path:

Azure Portal > Function Apps > [Your Function App] > Platform Features > Advanced Tools (Kudu) > Tools > PowerShell

And then open the following directory:

site > wwwroot > host.json

Kind of a shorthand way would be to jump directly to this address:

https://[contosofunctionappsite].scm.azurewebsites.net/DebugConsole/?shell=powershell

Alternatively, you could also just use ftp to do that and navigate to the same folder- like shown below:

host.json file location in Azure Functions app using ftp.
host.json file location in Azure Functions app using ftp.

Once you have the file open, no matter which way, make sure to update the file so that it contains the tracing level set to verbose.

{
  "queues": {
    "maxPollingInterval": 1000
  },
  "tracing": 
 {
  "consoleLevel": "verbose",
  "fileLoggingMode": "debugOnly"
 }
}

It should look something like below:

TracingLevel set to verbose in host.json
TracingLevel set to verbose in host.json

Remember to restart your function app to apply the changes! Just saving the file is not enough, they won’t take action until the IIS instance behind the (function) app service is recycled.

Remember to restart your (Function) app service after changing the host.json file - otherwise your changes won't get applied until it restarts automatically!
Remember to restart your (Function) app service after changing the host.json file – otherwise your changes won’t get applied until it restarts automatically!

Solution for local environment: modify host.json in your solution

Okay – so this is very similar to what you need to do in Azure. Just instead of fishing out the host.json file from Azure, open it from Visual Studio:

How to find host.json in your Visual Studio solution
How to find host.json in your Visual Studio solution

And just like on Azure, you add this in the file:

{
 ...
  "tracing": 
  {
   "consoleLevel": "verbose"
  }
}

And the next time you should have more logging!

References and additional information

Different logging levels:

Value Does
OffNothing at all!
Errorerror-handling messages
WarningWarnings & errors
InfoInfo, warnings, errors
VerboseAll logging – when tracking an error, you probably wnat this.

Sources:

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
mm

Leave a Reply

avatar
5000
  Subscribe  
Notify of