Wiring Serilog to Application Insights for richer .NET telemetry

Modern .NET services rarely live as a single process on a single machine. A request can land at a load balancer in Sydney, fan out to a microservices cluster hosted in an Australian Azure region, and trigger background jobs that touch databases running in Melbourne. When something goes wrong, scattered console output and IIS log files simply do not give engineers the end-to-end view required to act quickly. Structured logging combined with a managed telemetry backend changes that equation entirely, and pairing Serilog with Application Insights is one of the most common ways Australian engineering teams make it happen.

Serilog is a diagnostic logging library for .NET that captures events as rich, structured properties rather than flat text. Application Insights, the APM component of Azure Monitor, ingests those events and correlates them with requests, dependencies, exceptions, and custom metrics. When the two are joined through the correct sink, every log line becomes a queryable record with timestamps, severity, request IDs, and trace context. For teams shipping APIs out of Brisbane or Perth, this combination often replaces bespoke logging wrappers and ad-hoc file scraping.

This walkthrough explains how the pieces fit together, which sink variant fits which scenario, and how to ship a configuration that survives the realities of production. Whether the audience is a fintech in the Sydney CBD, a healthcare integration vendor in Adelaide, or a small SaaS shop in Hobart, the same building blocks apply, with only the surrounding governance choices changing.

Understanding the building blocks and how they compare

Before writing any code, it helps to be precise about the moving parts. Serilog is the producer; it captures messages from your application and shapes them. Sinks are the destinations; they decide where formatted events go. Enrichers decorate events with extra properties such as machine name, process ID, thread ID, or the current correlation context. Formatters translate a structured log into a wire format such as JSON or a compact message template. Application Insights is the receiver, exposing the data through the Azure portal, Log Analytics, and Kusto queries.

The common approach for sending Serilog output to Application Insights is to install a sink that knows how to speak the AI ingestion protocol. There are two mature options, and teams in Australia commonly evaluate both before settling on one.

For greenfield services, the TelemetryCorrelation package is almost always the right answer because it threads Operation_Id and Operation_ParentId through every event, which is what makes a click in Sydney appear in the same trace as a backend call executed in an Azure Australia East datacenter.

Setting up the project in Visual Studio

Open Visual Studio 2019 or 2022 and create a new ASP.NET Core Web API project targeting .NET 6 or later. Add the NuGet packages the pipeline requires: Serilog.AspNetCore, Serilog.Sinks.ApplicationInsights, and Serilog.Sinks.ApplicationInsights.TelemetryCorrelation. The TelemetryCorrelation package pulls several enrichers with it, including the request-id enricher that ensures each HTTP request gets a stable identifier across threads and async continuations.

In appsettings.json, configure the Application Insights connection string rather than the legacy instrumentation key. Connection strings let you pin a specific Azure region and a specific endpoint, which matters when an Australian tenant is required to keep telemetry inside Australia for data sovereignty reasons. The InstrumentationKey=...;IngestionEndpoint=https://australiaeast-0.in.applicationinsights.azure.com/ form gives the runtime the correct Australian ingestion host.

The connection string is read at startup and passed to the Serilog logger configuration. Sensitive values can be sourced from Azure Key Vault, User Secrets during development, or environment variables in production. Local .NET user groups, from the DDD Perth meetup to the Brisbane .NET community, often share starter templates that wire User Secrets in by default.

Wiring the pipeline in code

Inside Program.cs, the Serilog logger is created before the host is constructed so that even startup failures are captured. A typical configuration begins with LoggerConfiguration(), sets the minimum level, adds enrichers, and writes to multiple sinks. The console sink stays on for local debugging, while the Application Insights sink receives the same events for cloud analysis.

Log.Logger = new LoggerConfiguration()
    .MinimumLevel.Information()
    .Enrich.FromLogContext()
    .Enrich.WithMachineName()
    .Enrich.WithProcessId()
    .Enrich.WithThreadId()
    .WriteTo.Console()
    .WriteTo.ApplicationInsights(
        telemetryConfiguration: TelemetryConfiguration.CreateDefault(),
        telemetryConverter: new TraceTelemetryConverter())
    .CreateLogger();

Once the logger exists, the host is built with UseSerilog() so that ASP.NET Core's internal logging routes through Serilog. The result is that every ILogger call inside the framework and your code produces a structured event, decorated with correlation IDs and routed to Application Insights as TraceTelemetry.

The TraceTelemetryConverter is the default and emits each log event as a TraceTelemetry with severity, message, and properties attached. A common extension is to also pipe warning-level and higher events into EventTelemetry, so that the failures show up under the custom events blade in the Azure portal without further configuration.

Production hardening, sampling, and the Australian context

A pipeline that works on a developer laptop can collapse under production load. Application Insights has an ingestion cap, and Serilog will happily throw events away without complaint if that cap is reached. A fixed sampling ratio or an adaptive sampling policy in the ApplicationInsightsServiceOptions keeps volumes predictable. For services that must preserve every event for compliance reasons, such as a payroll platform processing payments under APRA oversight, sampling should be disabled and the cap raised through an Azure support ticket.

Properties carried by Serilog events become columns in Log Analytics. Standard fields such as RequestId, CorrelationId, UserId, and SessionId should be enriched at the logger level so that Kusto queries can join logs with traces and dependencies. The Australian Cyber Security Centre's Essential Eight maturity model encourages log retention of at least 18 months for many entities, and structuring properties up front makes that retention useful rather than ornamental.

Time zones are another practical concern. Azure Monitor stores timestamps in UTC, but Australian engineers in Melbourne, Sydney, Brisbane, Perth, or Hobart need to read them in AEST, AEDT, AWST, or ACST when triaging an incident. A simple Kusto projection, extend local_time = todatetime(timestamp) + 10h, produces a column aligned to AEDT during daylight saving, with the offset adjusted for the rest of the year.

Finally, it pays to think about who sees what. Application Insights supports role-based access, and a sensible baseline is to give developers Contributor access in non-production resources and Reader access in production. The same RBAC model satisfies the access-control expectations outlined in the Notifiable Data Breaches scheme, which has shaped how Australian software vendors expose telemetry to support teams.

Where to go next and who is presenting it

The patterns above have been battle-tested across many stacks running in Australian Azure regions, but there is always more to learn. Engineers interested in seeing live coding sessions, deep dives into .NET diagnostics, and Azure observability patterns should keep an eye on the program for the C# Corner Annual Conference 2020. The three-day event covers logging, telemetry, cloud, DevOps, and AI tracks, and the event platform lets attendees build a personal agenda from the published speakers. Watching a live walkthrough of a Serilog-to-Application Insights setup often reveals small details, from enricher ordering to sink flush behaviour, that are hard to capture in a written guide.

Beyond the conference, the Serilog GitHub repository hosts an extensive list of sinks, enrichers, and formatters curated by the community. Reading the source for Serilog.Sinks.ApplicationInsights.TelemetryCorrelation is a quick way to understand how Operation_Id propagates from Activity.Current into a log event's properties. Pairing that reading with a local Kusto sandbox gives engineers the full feedback loop needed to debug complex multi-region issues without waiting for production traffic.

A final practical tip is to commit the Serilog configuration to source control and to gate changes behind the same code review process as business code. Logging pipelines tend to grow quietly until they become hard to maintain, and a pull request review is the cheapest place to catch a sink that floods a workspace or a property name that collides with an existing column in Log Analytics. With those habits in place, the journey from Log.Information("Hello, world") to a queryable, correlated trace on the other side of the planet becomes a calm engineering activity rather than a firefighting exercise.