Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

AnsweredbyAwkEng
paulirwin asked this question inQ&A
Discussion options

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:
screenshot-2025-10-29-at-16-29-07

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!

You must be logged in to vote

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. AnyApplication 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.

Replies: 4 comments 3 replies

Comment options

cc@fabiocav@mattchenderson@JamesNK

You must be logged in to vote
0 replies
Comment options

JamesNK
Oct 30, 2025
Collaborator

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.

You must be logged in to vote
2 replies
@paulirwin
Comment options

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

@JamesNK
Comment options

JamesNKOct 31, 2025
Collaborator

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

Comment options

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. AnyApplication 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.

You must be logged in to vote
1 reply
@paulirwin
Comment options

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"    }  }}
Answer selected bypaulirwin
Comment options

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

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
5 participants
@paulirwin@davidfowl@JamesNK@AwkEng@tjwald

[8]ページ先頭

©2009-2025 Movatter.jp