Structured Logging in Azure Applications

Why structure matters in Log Analytics

Azure Log Analytics stores your logs in tables. Each row is a log entry. Each column is a field. When your log entry arrives as a structured object, its fields map cleanly to columns. When it arrives as a plain string, everything goes into a single text field that requires expensive full-text search and regex parsing to extract meaning.

Compare these two approaches for an e-commerce order failure:

Unstructured:

ERROR 2026-03-19 14:23:01 Payment processing failed for order 9182 user 4421 amount 149.99 method visa error gateway_timeout

Structured:

{
  "timestamp": "2026-03-19T14:23:01Z",
  "level": "Error",
  "message": "Payment processing failed",
  "orderId": "9182",
  "userId": "4421",
  "amount": 149.99,
  "paymentMethod": "visa",
  "errorCode": "gateway_timeout",
  "durationMs": 30004,
  "correlationId": "a3f2e1d4-8b9c-4a2f-b1d3-e5f6a7b8c9d0"
}

With the structured version, a KQL query can find all gateway timeouts above $100 for Visa payments in the last hour with two lines of code. With the unstructured version, you would need fragile regex parsing that breaks when the message format changes.

Designing a consistent log schema

A good log schema includes a small set of standard fields present on every entry, plus context-specific fields added per operation. Standard fields let you write reusable queries that work across all services. Context fields let you drill into specific operations.

Structured logging with Serilog and Application Insights

Serilog is the most widely used structured logging library for .NET applications. It supports message templates with named properties, and its Application Insights sink routes log entries directly to your workspace’s AppTraces table.

# Install Serilog packages for an ASP.NET Core application
dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.ApplicationInsights
dotnet add package Microsoft.ApplicationInsights.AspNetCore

Configure Serilog in your application startup:

// appsettings.json
{
  "Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning",
        "Microsoft.Hosting.Lifetime": "Information"
      }
    },
    "Enrich": ["FromLogContext", "WithMachineName", "WithEnvironmentName"],
    "Properties": {
      "Application": "OrderService",
      "Environment": "Production"
    }
  },
  "ApplicationInsights": {
    "ConnectionString": "InstrumentationKey=your-key;IngestionEndpoint=..."
  }
}

Log context enrichment

The most valuable aspect of structured logging is enriching every log entry with the request context automatically. Using Serilog’s LogContext.PushProperty, you can push the correlation ID, user ID, and operation name once at the start of a request, and have them appear on every subsequent log entry within that request’s scope — without passing them as parameters to every method.

In an ASP.NET Core middleware:

# This is C# pseudocode showing the logging pattern concept
# Middleware adds correlationId and userId to every log entry in the request
using Serilog.Context;

# At the start of each request:
# using (LogContext.PushProperty("CorrelationId", correlationId))
# using (LogContext.PushProperty("UserId", userId))
# {
#     await _next(context);
# }

# Individual log calls then just log what happened:
# _logger.LogInformation("Order {OrderId} placed for {Amount:C}", orderId, amount);
# _logger.LogError(ex, "Payment failed for order {OrderId} with error {ErrorCode}", orderId, errorCode);

These properties flow into Application Insights as customDimensions on each AppTraces entry, making them queryable in KQL.

Querying structured logs in KQL

Custom properties from structured logging appear in the customDimensions column in Log Analytics. This is a JSON object. You access individual fields using the customDimensions[“fieldName”] or tostring(customDimensions.fieldName) syntax.

// Find all payment failures in the last hour by error code
AppTraces
| where TimeGenerated > ago(1h)
| where SeverityLevel >= 3  // 3 = Warning, 4 = Error
| where Message contains "Payment"
| extend
    OrderId = tostring(customDimensions["orderId"]),
    ErrorCode = tostring(customDimensions["errorCode"]),
    PaymentMethod = tostring(customDimensions["paymentMethod"]),
    DurationMs = todouble(customDimensions["durationMs"])
| summarize
    FailureCount = count(),
    AvgDuration = avg(DurationMs)
    by ErrorCode, PaymentMethod
| order by FailureCount desc

// Trace a specific user's journey through the system
AppTraces
| where TimeGenerated > ago(24h)
| where customDimensions["userId"] == "4421"
| project TimeGenerated, Message, SeverityLevel,
    CorrelationId = tostring(customDimensions["correlationId"]),
    Service = tostring(customDimensions["service"])
| order by TimeGenerated asc

Log level strategy for production

Logging too much is almost as problematic as logging too little. Every log entry costs money to ingest and store, and too many log entries create noise that slows down incident investigation. A practical production strategy:

• Debug / Verbose — Disabled in production. Enable temporarily via a feature flag or app setting for specific troubleshooting.
• Information — Key business events: order placed, user logged in, job completed. Keep this selective — not every function call, just meaningful milestones.
• Warning — Recoverable issues: retry attempted, fallback activated, deprecated API called, rate limit approaching.
• Error — Failed operations that affect a user or a specific request. Payment failed, database connection lost, file not found.
• Critical — Service is at risk: database unavailable, certificate expired, out of memory. These should always alert immediately.