How to deal with excessive logging from storage blob/queue triggers in Azure Functions?

[paulirwin]

I have added an Azure Functions C# project to my Aspire AppHost, and it contains several functions using various timer, storage queue, blob, and Cosmos DB triggers. We have Azurite spun up by Aspire as the Functions host storage and where the queues live. The storage queue trigger in particular is very noisy in the logs when running in Aspire. There are two main areas this affects: the console logs view, and the traces view.

For the console logs view, it's not as much of a problem, since you can filter to specific resources. But if you have it set to "(All)" resources or the storage account, it is showing every single polling request for the queue messages, with several entries per second. It quickly builds up to many thousands of lines of logs.

The traces view is much worse: it adds several traces per second, drowning out legitimate traces of real requests to the app. These are all for BlobContainerClient.GetBlobs (for the blob triggers) and QueueClient.Exists (for the queue triggers). It honestly is so noisy that it ruins the value of using Aspire for distributed tracing, when these traces are providing no value and the app is sitting there doing nothing. I only want to see traces if there is actually a blob or queue message that triggers a function.

Here is what my traces view looks like:

Has anyone found a good solution to this, without i.e. switching to a timer trigger? Even if the solution is just slowing down the polling to once a minute or something that would be better than this. Thanks in advance!

[davidfowl]

cc @fabiocav @mattchenderson @JamesNK

[JamesNK]

I think the solution is configuration in the client to not send all telemetry to the dashboard. Either disable sending certain kinds of telemetry, or sample it.

[paulirwin]

Awesome, thanks. Are there any docs or guidance on how to do that? ChatGPT and such have not been helpful ☹️

[JamesNK]

Sorry I don't know about Azure Functions OTEL configuration.

[AwkEng]

I ran into a similar issue. The Azure Functions template has the host.json which contains logging settings, but that does not control the process worker log levels.

https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide?tabs=ihostapplicationbuilder%2Cwindows#managing-log-levels

The Functions host and the isolated process worker have separate configuration for log levels, etc. Any Application Insights configuration in host.json will not affect the logging from the worker, and similarly, configuration made in your worker code will not impact logging from the host. You need to apply changes in both places if your scenario requires customization at both layers.

I added an appsettings.*.json file with the desired log levels to my Functions project and that calmed my logging down. I'm not sure if this is the long term solution, but it works for me for now.

[paulirwin]

This did it, thanks! I wasn't expecting to need an appsettings.Development.json file in a functions project, since that usually uses host.json or local.settings.json.

Adding the following appsettings.Development.json file fixed the issue:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}

[tjwald]

I ran into a similar issue with registry:3 local registry image. We want the tracing for when we actually pull/push images, but it has background spans that are spamming.