[QUERY] Handling 404 Warning Logs for Initial Blob Receipt Operations

[brandoa]

Library name and version

Azure.Storage.Blobs (12.10.0), Azure.Storage.Queues (12.8.0)

Query/Question

In one of our WebJobs we use a trigger function to create a queue message when a particular storage account is found to have a new blob within it. Occasionally we will check the Log Stream to verify the status of the job - we'll look for our own custom logs as well as invocation and success logs for the same trigger function.

The log stream has lots of background request and response information relating to Azure.Core processes so we added a filter to the logger in our Program.cs:

hostBuilder.ConfigureLogging((context, b) =>
            {
                b.AddConsole();
                b.AddFilter("Azure.Core", Microsoft.Extensions.Logging.LogLevel.Warning);

This clears out all of the additional logging so we can better view the status of our own code. However, we consistently get 404 warning logs with the following structure:

2022-06-07T15:25:15  PID[5012] Information warn: Azure.Core[8]
2022-06-07T15:25:15  PID[5012] Information       Error response [b64938d3-bd01-4dba-bdc3-5182ccf3d2a5] 404 The specified blob does not exist. (00.0s)
2022-06-07T15:25:15  PID[5012] Information       Transfer-Encoding:chunked
2022-06-07T15:25:15  PID[5012] Information       Server:Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
2022-06-07T15:25:15  PID[5012] Information       x-ms-request-id:b2f8dcfb-a01e-0089-6e82-7a8ef2000000
2022-06-07T15:25:15  PID[5012] Information       x-ms-client-request-id:b64938d3-bd01-4dba-bdc3-5182ccf3d2a5
2022-06-07T15:25:15  PID[5012] Information       x-ms-version:2021-06-08
2022-06-07T15:25:15  PID[5012] Information       x-ms-error-code:BlobNotFound
2022-06-07T15:25:15  PID[5012] Information       Date:Tue, 07 Jun 2022 15:25:15 GMT

After removing the filter and investigating, we were able to find the requesting operation and it's always a HEAD request to /azure-webjobs-hosts/blobreceipts/ that looks for a receipt relating to the new blob picked up by the trigger function. Since it's a new blob, it makes sense that there would be no receipt found for it. We also noticed a PUT request directly after the 404 that creates the new receipt. This all seems like expected behavior. However, with the information displayed in the warning there's no way of knowing this was relating to the expected process for creating/managing blob receipts.

Is there a way to add additional information to the warning logs so we have a better understanding of their context or a way to filter out this particular warning altogether?

Environment

Hosting Platform: Azure App Service WebJob (.NET6)
IDE: Visual Studio 17.0.2

[ghost]

Thank you for your feedback. This has been routed to the support team for assistance.

[amnguye]

I do agree seeing those expected exceptions being thrown can be annoying.

@JoshLove-msft
I was wondering if there's already a feature in logging that can help filter these expected exceptions for us? Or if there's a log level I'm missing that the customer can utilize?

[JoshLove-msft]

There is an upcoming feature that will help with this. See #27645

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

Issue Details

---

Library name and version

Azure.Storage.Blobs (12.10.0), Azure.Storage.Queues (12.8.0)

Query/Question

In one of our WebJobs we use a trigger function to create a queue message when a particular storage account is found to have a new blob within it. Occasionally we will check the Log Stream to verify the status of the job - we'll look for our own custom logs as well as invocation and success logs for the same trigger function.

The log stream has lots of background request and response information relating to Azure.Core processes so we added a filter to the logger in our Program.cs:

hostBuilder.ConfigureLogging((context, b) =>
            {
                b.AddConsole();
                b.AddFilter("Azure.Core", Microsoft.Extensions.Logging.LogLevel.Warning);

This clears out all of the additional logging so we can better view the status of our own code. However, we consistently get 404 warning logs with the following structure:

2022-06-07T15:25:15  PID[5012] Information warn: Azure.Core[8]
2022-06-07T15:25:15  PID[5012] Information       Error response [b64938d3-bd01-4dba-bdc3-5182ccf3d2a5] 404 The specified blob does not exist. (00.0s)
2022-06-07T15:25:15  PID[5012] Information       Transfer-Encoding:chunked
2022-06-07T15:25:15  PID[5012] Information       Server:Windows-Azure-Blob/1.0,Microsoft-HTTPAPI/2.0
2022-06-07T15:25:15  PID[5012] Information       x-ms-request-id:b2f8dcfb-a01e-0089-6e82-7a8ef2000000
2022-06-07T15:25:15  PID[5012] Information       x-ms-client-request-id:b64938d3-bd01-4dba-bdc3-5182ccf3d2a5
2022-06-07T15:25:15  PID[5012] Information       x-ms-version:2021-06-08
2022-06-07T15:25:15  PID[5012] Information       x-ms-error-code:BlobNotFound
2022-06-07T15:25:15  PID[5012] Information       Date:Tue, 07 Jun 2022 15:25:15 GMT

After removing the filter and investigating, we were able to find the requesting operation and it's always a HEAD request to /azure-webjobs-hosts/blobreceipts/ that looks for a receipt relating to the new blob picked up by the trigger function. Since it's a new blob, it makes sense that there would be no receipt found for it. We also noticed a PUT request directly after the 404 that creates the new receipt. This all seems like expected behavior. However, with the information displayed in the warning there's no way of knowing this was relating to the expected process for creating/managing blob receipts.

Is there a way to add additional information to the warning logs so we have a better understanding of their context or a way to filter out this particular warning altogether?

Environment

Hosting Platform: Azure App Service WebJob (.NET6)
IDE: Visual Studio 17.0.2

Author:	brandoa
Assignees:	-
Labels:	Storage, Service Attention, Client, customer-reported, feature-request, needs-team-attention
Milestone:	-

[github-actions]

Hi @brandoa, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.