App Service Custom IIS logging in .Net Framework 4.8 sample?

Question

App Service Custom IIS logging in .Net Framework 4.8 sample?

Graham Freckleton 0

We are looking for custom IIS logging samples for our app service running .Net Framework 4.8 in Windows. Particularly, some mapping details for the standard W3C logging format used by the built in IIS logger. Some fields are bit difficult to find (for example sc-bytes, cs-bytes and time-taken). Any caveats with custom logging would be appreciated as well.

Background: We have moved our application to Managed Identity (MI) but discovered that the App Service -> App Service logs -> ``Web server logging (built-in) logging does not support MI, only storage access keys.

Sidenote: We are using NLog for the logging framework.

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-08-31T20:13:49.73+00:00

Hi @Graham Freckleton

Thank you for contacting us about the issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-08-31T22:19:21.2066667+00:00
HI @Graham Freckleton

Thank you for the detailed question.

I understand that you're looking for a custom IIS/W3C-style logging approach for a Windows-based Azure App Service running .NET Framework 4.8, particularly to reproduce fields such as sc-bytes, cs-bytes, and time-taken, while avoiding the dependency on storage account access keys due to your move to Managed Identity.

Based on the Azure App Service documentation, built-in Web Server Logs are generated in the W3C Extended Log File Format and contain raw HTTP request data such as request method, URI, client information, and response details.

For a custom implementation using NLog, the typical mappings are:

cs-bytes: Request.ContentLength (note that this may not always be available for chunked requests)

sc-bytes: Capture by wrapping the response stream and counting bytes written

time-taken: Measure elapsed time using a Stopwatch from request start to request completion

The W3C definitions for these fields are documented by Microsoft as:

cs-bytes: bytes received by the server.

sc-bytes: bytes sent by the server.

time-taken: request processing time in milliseconds

As an alternative to reproducing IIS logs in application code, you may also evaluate Diagnostic Settings and send App Service HTTP logs to Log Analytics for centralized querying and retention. Azure documents both the App Service diagnostic logging capability and the AppServiceHTTPLogs table used in Azure Monitor. Before choosing this option, I would recommend reviewing the table schema to verify that it contains all fields required by your logging and reporting requirements.

A couple of caveats to keep in mind with custom logging:

Values collected at the application layer may not exactly match native IIS-generated values because IIS captures some metrics lower in the request-processing pipeline.

Response byte counts can differ when compression, buffering, or static-file handling is involved.

Azure App Service is a managed platform, so application-level logging (NLog, Application Insights, Azure Monitor, etc.) is generally the recommended approach for custom logging scenarios.

Reference:

https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/appservicehttplogs

https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs

https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/appservicehttplogs

https://learn.microsoft.com/en-us/windows/win32/http/w3c-logging

Given that you're already using NLog, my recommendation would be to either:

Use Diagnostic Settings + Log Analytics if centralized HTTP request logging satisfies your requirements, or

Implement a lightweight custom request logger in your ASP.NET application to generate W3C-style entries and write them to a destination that aligns with your Managed Identity strategy.

I hope this helps clarify the available options.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Graham Freckleton 0 Reputation points

2026-09-01T20:58:21.5066667+00:00

@Praneeth Maddali Thanks for this. We are looking at custom request logger because I was under the impression that a 7 year retention at ~500MB/day is probably unrealistic.

I will do some more digging for sc-bytes, but I have seen a implementation for time-taken. I is kind of strange there is no implementation out there (that I can find).

2 answers

Your answer

Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator

2026-08-31T20:13:49.73+00:00

Hi @Graham Freckleton

Thank you for contacting us about the issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Graham Freckleton 0 Reputation points

2026-09-01T20:58:21.5066667+00:00

@Praneeth Maddali Thanks for this. We are looking at custom request logger because I was under the impression that a 7 year retention at ~500MB/day is probably unrealistic.

I will do some more digging for sc-bytes, but I have seen a implementation for time-taken. I is kind of strange there is no implementation out there (that I can find).

Answer 1

@Graham Freckleton I hope you are doing well,

For Windows App Service, the built-in web server logs are W3C extended logs generated by IIS. App Service stores these under /LogFiles/http/RawLogs/.

For the fields you're looking for:

cs-bytes – bytes received from the client
sc-bytes – bytes sent to the client
time-taken – request processing time in milliseconds

IIS documents TimeTaken as the time from receiving the request through the final IIS send completion.

One important caveat is that App Service doesn't expose every IIS field; for example, s-computername, s-ip, and cs-version aren't supported.

If you're moving away from Storage access keys because of Managed Identity, I would keep the IIS access-log semantics separate from NLog application logging. NLog can reproduce many of these values, but it won't necessarily have the same request-level timing and byte counts that IIS/HTTP.sys has.

For reference:

· Enable diagnostic logging in Azure App Service

· IIS W3C logging fields

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

Graham Freckleton 0 Reputation points

2026-09-01T22:00:24.6266667+00:00

@Jose Benjamin Solis Nolasco Thanks for the follow up. Yes we are looking at having a different NLog target than our application logs and writing to a separate storage container.

As for the request-level, we were looking at hooking the Application_BeginRequest/Application_EndRequest events in the Global.asax.cs but was hoping to find a sample of such, and some information on what is and is not possible.

Answer 2

Hello Graham Freckleton

There are two ways to get real IIS logs without storage keys

Before writing a custom logger, note that the three fields you call out (sc-bytes, cs-bytes, time-taken) are measured in HTTP.sys, below the managed pipeline an in-process logger can only approximate them. Two platform options give you the true values with no access keys:

Diagnostic settings → Log Analytics (recommended). App Service Diagnostic settings (Azure Monitor, not "App Service logs") has an HTTP logs category that lands in the AppServiceHTTPLogs table. It contains the genuine IIS values: ScBytes, CsBytes, TimeTaken, ScStatus, ScSubStatus, ScWin32Status, CsUriStem, CsUriQuery, CsUsername, UserAgent, Referer, Cookie, CIp, SPort, ComputerName. Sending to Log Analytics or Event Hubs involves no storage keys at all. (Caveat: the storage account destination of diagnostic settings still writes with account keys internally, so it breaks on shared-key-disabled accounts just like the built-in blob logging see this Q&A.)
Keep "Web server logging = File System" (needs no storage account; quota-limited, rotating) and ship D:\home\LogFiles\http\RawLogs\*.log to blob yourself with a scheduled WebJob using Azure.Storage.Blobs + DefaultAzureCredential. True IIS logs, MI-authenticated shipping, no custom request instrumentation.

There is no official Microsoft sample that reproduces the complete W3C line (with sc-bytes/cs-bytes/time-taken) from inside a Framework app because those three values are produced by HTTP.sys below the managed pipeline.

W3CLogger in ASP.NET Core a modern ASP.NET Core has this exact feature built in (W3C-format request logging middleware), plus metaljase/HttpLoggingW3CLoggingSerilogExamples with runnable examples.

Graham Freckleton 0 Reputation points

2026-09-01T22:10:42.15+00:00

Thanks @Andriy Bilous . We looked at Log Analytics and the file system but unfortunately it doesn't fit with our log retention requirements or storage space (7 years x ~500MB/day).

The Event Hub is interesting, but is a new resource and build for us. And I would also make sure that using it ALSO supports MI - there are some quiet restrictions in these settings (access keys, key rotation, file system size) that are surprise factors...

As for the ASP.NET Core, yes I saw that but that is a much bigger lift to convert to Core. Nice to know it will be there when we do though ;)