A log line isn't a sentence for a human — it's a record for a search engine.

Something breaks in production at 3am. You open the logs, and you're staring at ten thousand lines that look like "Order 4471 failed for customer sam@example.com". Now try to answer: "how many orders failed for this specific customer in the last hour, across every log line, regardless of the exact wording?" With plain interpolated strings, you can't — the customer's email and order ID are baked irretrievably into free-form text. Your only tool is a fuzzy text search.

Structured logging exists to fix exactly this. Instead of burning your data into a sentence, you log a message template with named placeholders, and pass the actual values as separate parameters. The logging system keeps the values as real, queryable data alongside the human-readable message — so you can search, filter, and aggregate by OrderId or CustomerEmail as if they were columns in a database, because in a real logging backend, they effectively are.

In this lesson, you'll learn how ILogger<T> works, what structured logging with message templates actually means (and why it's not string interpolation), log levels, and why this distinction matters enormously once your app is running in production.

What Is It?

The Simple Explanation

ILogger<T> is the standard .NET interface for writing log messages, automatically supplied through DI to any class that asks for it. The <T> tells the logging system which class is doing the logging, so every message is automatically tagged with its source (called a "category").

The Technical Definition

.NET's logging system, part of Microsoft.Extensions.Logging, is built into the generic host and automatically available via DI. It's built around three ideas: categories (which component logged this — usually the class's full name via ILogger<T>), log levels (how important/severe is this message), and structured message templates (named placeholders that keep logged values as real, extractable data, not just embedded text).

Why Does It Exist?

The Problem — Free-Text Logs Don't Scale

A single developer running an app locally can eyeball a handful of Console.WriteLine calls just fine. A production service handling thousands of requests per minute across dozens of machines generates millions of log lines per day. At that scale, "reading the logs" isn't reading at all — it's querying, filtering, and aggregating, in a log aggregation platform (Seq, Application Insights, Elasticsearch, Datadog, and similar tools). Those platforms work by indexing structured values — if your values are welded into a sentence via string interpolation, there's nothing for them to index.

The Solution — Templates With Named Placeholders

logger.LogInformation("Order {OrderId} placed by {CustomerEmail}", orderId, email) keeps OrderId and CustomerEmail as distinctly named, separately captured values. The logging system renders a human-readable line for the console, and hands structured log backends a payload like { "OrderId": 4471, "CustomerEmail": "sam@example.com" } that they can index and query directly — "show me every log entry where OrderId = 4471," instantly, across the entire fleet.

Big Picture

logger.LogInformation("Order {OrderId} placed by {CustomerEmail}", 4471, "sam@example.com");

info: OrderService[0]
      Order 4471 placed by sam@example.com

{ "Message": "Order 4471 placed by sam@example.com",
  "OrderId": 4471, "CustomerEmail": "sam@example.com",
  "Category": "OrderService", "Level": "Information" }

One call to LogInformation produces both — a readable line and a queryable record — because the template and the arguments are kept separate all the way through the pipeline, not merged into a string before logging happens.

How It Works

public class OrderService(ILogger<OrderService> logger)

logger.LogWarning("Payment {PaymentId} failed after {Attempts} attempts", paymentId, attempts);

Simple Example

public class OrderService(ILogger<OrderService> logger)
{
    public void PlaceOrder(int orderId, string customerEmail)
    {
        logger.LogInformation("Placing order {OrderId} for {CustomerEmail}", orderId, customerEmail);

        try
        {
            // ... processing ...
            logger.LogInformation("Order {OrderId} placed successfully", orderId);
        }
        catch (Exception ex)
        {
            // Pass the exception as the first argument — it's captured with a full stack trace,
            // separately from the message template.
            logger.LogError(ex, "Order {OrderId} failed to process", orderId);
        }
    }
}

var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddTransient<OrderService>();
using var host = builder.Build();

host.Services.GetRequiredService<OrderService>().PlaceOrder(4471, "sam@example.com");

Console output looks like:

info: OrderService[0]
      Placing order 4471 for sam@example.com
info: OrderService[0]
      Order 4471 placed successfully

Note the order matters: placeholder names in the template must line up positionally with the arguments passed after it — {OrderId} matches the first argument, {CustomerEmail} the second.

Real-World Example

A payment worker logs at different levels depending on outcome, and uses BeginScope to attach a correlation ID to every log line produced while processing one specific payment — so when something goes wrong, every related log entry can be found together, even across multiple log calls:

public class PaymentWorker(IPaymentGateway gateway, ILogger<PaymentWorker> logger)
{
    public async Task ProcessAsync(Payment payment)
    {
        using (logger.BeginScope("PaymentId:{PaymentId}", payment.Id))
        {
            logger.LogDebug("Starting payment processing");

            var result = await gateway.ChargeAsync(payment);

            if (result.Succeeded)
            {
                logger.LogInformation("Payment succeeded for {Amount:C}", payment.Amount);
            }
            else if (result.IsRetryable)
            {
                logger.LogWarning("Payment failed but is retryable: {Reason}", result.Reason);
            }
            else
            {
                logger.LogError("Payment permanently failed: {Reason}", result.Reason);
            }
        }
    }
}

Every log line inside the using (logger.BeginScope(...)) block automatically carries PaymentId, even the ones that don't explicitly mention it in their own template — so a log query for a single payment ID returns the complete story: start, gateway call outcome, and result, all correlated.

Analogy

Under the Hood

Common Confusion

"It looks like string.Format — so it must work the same way" — it doesn't

This is the single most common mistake in this lesson: writing logger.LogInformation($"Order {orderId} placed") instead of logger.LogInformation("Order {OrderId} placed", orderId). They can render identical console output, which is exactly why the mistake is so easy to miss — but the first one has already collapsed orderId into an opaque string before logging even sees it, so no structured backend can ever recover it as a distinct, queryable value. The second keeps OrderId as a real, named, separately captured piece of data all the way through the pipeline.

Log levels are a filter, not a suggestion

Setting the minimum log level to Warning in production doesn't just make LogDebug calls invisible — the framework typically skips the expensive work of even formatting those messages, because the "is this level enabled" check happens first.

Common Mistakes

Mistake 1 — Using string interpolation in the message template

logger.LogInformation($"User {userId} logged in") — destroys structure, as explained above.

logger.LogInformation("User {UserId} logged in", userId) — keeps UserId queryable.

Mistake 2 — Logging sensitive data in plain templates

logger.LogInformation("User logged in with password {Password}", password) — passwords, credit card numbers, and other secrets end up permanently stored in log systems, often with weaker access controls than your primary database.

Never log secrets or full sensitive payloads. Log identifiers (user ID, masked card number) instead.

Mistake 3 — Wrong log level for the situation

Logging routine, expected events (like every successful request) at LogError, or logging genuinely critical failures at LogInformation where they'll be filtered out or ignored in production.

Match severity to reality: Trace/Debug for detailed diagnostic noise, Information for normal operational events, Warning for recoverable/unexpected-but-not-broken situations, Error for failures that need attention, Critical for failures threatening the whole application.

When Should I Use It?

• Use ILogger<T> instead of Console.WriteLine in any application beyond a throwaway script — it's filterable by level, routable to multiple destinations, and structured.
• Always use message templates with named placeholders, never string interpolation, for any value you might ever want to search or filter by.
• Console.WriteLine can still be fine for a quick, disposable debugging print you'll delete in five minutes — but production code should always go through ILogger<T>.

Mental Model

Key Takeaway

Check Your Understanding

You've seen why structured logging beats string interpolation. Let's confirm you can spot the difference in practice.

You now understand structured logging with ILogger<T> — and why message templates, not string interpolation, are the professional standard.

dotnetmadeeasy.com — Learn C# and .NET, the right way.