Introduction
Logging is one of the most critical components in modern web applications. It helps developers understand what happened, when it happened, and why it happened. Good logging reduces debugging time, improves monitoring, and helps identify performance problems, security attacks, or unexpected failures.
ASP.NET Core includes a built-in logging framework called ILogger that works without requiring any external libraries. It supports logging to the console, debug window, files, Application Insights, cloud logging systems, and custom providers.
This article explains how to use ILogger effectively in real-world enterprise applications, how logging behaves inside different layers (Controllers, Middleware, Services), and how to format logs for production readiness.
Real-World Problem Statement
A large SaaS product started facing occasional failures in production. Users reported intermittent errors, but developers could not find the cause because:
Errors were not logged properly
Messages were too generic
Logs did not include correlation IDs
Exceptions were swallowed inside try-catch blocks without context
The engineering team decided to implement structured logging using the built-in ILogger framework.
Result after implementation
Root causes became traceable
API request patterns became visible
Performance bottlenecks were identified
Security anomalies were detected early
This case reflects why structured and meaningful logging matters.
How Logging Works in ASP.NET Core
ASP.NET Core logging is built around:
ILogger interface
ILogger<T> dependency injection
Logging providers (Console, Debug, EventLog, Azure, etc.)
Log levels (Trace → Critical)
Logging flows through DI, and the framework automatically manages lifecycle and configuration.
Logging Levels Explained
| Level | Purpose |
|---|
| Trace | Very detailed debugging logs (rarely used in production) |
| Debug | Used during development for troubleshooting |
| Information | General flow information such as startup, login, or successful processing |
| Warning | Something unexpected happened but system continued working |
| Error | Application failure requiring investigation |
| Critical | System-wide or infrastructure-level failure |
Best practice: Set different log levels for Development and Production.
Basic Example: Logging in a Controller
[ApiController]
[Route("api/[controller]")]
public class OrderController : ControllerBase
{
private readonly ILogger<OrderController> _logger;
public OrderController(ILogger<OrderController> logger)
{
_logger = logger;
}
[HttpGet("{id}")]
public IActionResult GetOrder(int id)
{
_logger.LogInformation("Fetching order with id {OrderId}", id);
if (id <= 0)
{
_logger.LogWarning("Invalid order id received: {OrderId}", id);
return BadRequest("Invalid Id");
}
return Ok($"Order {id}");
}
}
Notice structured logging with placeholders such as {OrderId}. This is important for queryable log analytics platforms.
Logging Exceptions the Right Way
Many developers log exceptions incorrectly, such as:
_logger.LogError("Error occurred: " + ex.Message);
Correct approach
catch (Exception ex)
{
_logger.LogError(ex, "Failed to process order {OrderId}", orderId);
}
This logs:
Exception stack trace
Message
Contextual data
Logging in Service Layer
Logging shouldn't only exist in controllers. It must also exist in business and repository layers.
public class PaymentService
{
private readonly ILogger<PaymentService> _logger;
public PaymentService(ILogger<PaymentService> logger)
{
_logger = logger;
}
public bool ProcessPayment(decimal amount)
{
_logger.LogInformation("Processing payment of {Amount}", amount);
if (amount <= 0)
{
_logger.LogWarning("Attempted to process invalid payment value: {Amount}", amount);
return false;
}
return true;
}
}
Logging from Middleware (Recommended Practice)
public class RequestLoggerMiddleware
{
private readonly RequestDelegate _next;
private readonly ILogger<RequestLoggerMiddleware> _logger;
public RequestLoggerMiddleware(RequestDelegate next, ILogger<RequestLoggerMiddleware> logger)
{
_next = next;
_logger = logger;
}
public async Task InvokeAsync(HttpContext context)
{
_logger.LogInformation("Request: {Method} {Path}", context.Request.Method, context.Request.Path);
await _next(context);
_logger.LogInformation("Response Status: {StatusCode}", context.Response.StatusCode);
}
}
Workflow Diagram
Incoming Request
|
V
Middleware (Request Logging)
|
V
Controller Logging
|
V
Service/Repository Logging
|
V
Exception Logging (if needed)
|
V
Response + Log Output
Flowchart of Logging Strategy
┌──────────────────────┐
│ Start Application │
└───────────┬──────────┘
│
▼
┌────────────────────────────┐
│ Log Request Information │
└───────────┬───────────────┘
│
▼
┌──────────────────────────────────┐
│ Execute Business Logic │
└───────────────┬─────────────────┘
│
▼
┌────────────────────────┐
│ Any Errors Occurred? │
└───────┬───────────────┘
│
Yes │ No
│
▼
┌─────────────────────────────┐
│ Log Error With Stack Trace │
└─────────────────────────────┘
│
▼
┌───────────────────────────┐
│ Return Response + Logs │
└───────────────────────────┘
Writing Logs to Files
Modify appsettings.json:
{"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}}}
To enable file logging (built-in on Windows hosting):
"Logging": {"AddFile": true}
On Linux/docker environments, logs are typically written to stdout and collected by the hosting system.
Adding Correlation IDs (Highly Recommended)
Correlation IDs allow tracking a single request across the entire application.
Example:
_logger.LogInformation("Request {CorrelationId}", context.TraceIdentifier);
This becomes critical when using distributed systems, queues, or microservices.
Best Practices
Use structured logging, never string concatenation.
Log warnings only when action is required.
Avoid logging sensitive data (passwords, tokens).
Add correlation IDs for tracking.
Use LogInformation for standard flow, not LogError.
Configure different logging levels for staging vs production.
Common Mistakes
| Mistake | Why It Is Wrong |
|---|
| Logging everything as error | Creates noise and hides real problems |
| Logging user passwords or tokens | Security vulnerability |
| Logging large objects fully | Creates unnecessary storage cost |
| Missing context | Makes logs useless in investigation |
Final Recommendations
Start logging early in development.
Design consistent log messages.
Use structured logs with placeholders.
Integrate logs with monitoring tools when scaling.
Conclusion
The built-in ILogger in ASP.NET Core is powerful enough for most enterprise applications without requiring external dependencies. When implemented with best practices, it provides complete visibility into system behavior, reduces support burden, enables faster incident resolution, and improves long-term maintainability.
Logging is not just a debugging tool — it is an operational asset.