Skip to main content
Logfire for .NET

.NET observability with OpenTelemetry

OpenTelemetry-native observability for any .NET app, from the team behind Pydantic. Instrument with ActivitySource from the base class library, so nothing vendor-specific enters your code, and query it all with SQL. Free for 10 million spans, logs, and metrics a month.

Start free with .NET As Markdown
Getting started

Configure the exporter

dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol
export OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
var activitySource = new ActivitySource("hello-dotnet");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource("hello-dotnet")
    .ConfigureResource(r => r.AddService("hello-dotnet"))
    .AddOtlpExporter()
    .Build();

using var activity = activitySource.StartActivity("hello");

The name passed to AddSource must match the ActivitySource you create, or spans are dropped silently. There is no Logfire .NET SDK to adopt: these are base class library types exported over standard OTLP. Full details are in the .NET setup guide.

What you get

One request, one trace

A Logfire trace of an ASP.NET Core request: the endpoint, Npgsql queries and the outbound call, with an errored request below

What lands in Logfire:

  • the Microsoft.AspNetCore request span, with route and status
  • every Npgsql query against Postgres, timed
  • your own ActivitySource spans, nested underneath
  • the outbound System.Net.Http call
  • a 404 marked red, at the span that produced it
  • GC heap size, lock contention and thread-pool queue length, as metrics beside the spans
How it works

Standard OpenTelemetry, hosted backend

Use ActivitySource, not a vendor type

System.Diagnostics.ActivitySource is .NET's built-in tracing API and is what OpenTelemetry consumes directly. Instrumentation you write against it is portable by construction: nothing in your code references Logfire, so nothing has to be undone if you change backends.

ASP.NET Core instrumentation is a package, not a rewrite

Add the OpenTelemetry ASP.NET Core instrumentation and incoming requests become spans automatically, with route, status, and timing attached. Contrib packages also cover HttpClient, Entity Framework Core, SQL Client, and gRPC. Your own ActivitySource spans nest inside the request span, so a slow endpoint and the work that made it slow appear in one trace.

Standard OTLP, so genuinely no lock-in

Everything is configured through OTEL_ environment variables and the standard exporter. Repoint at another OpenTelemetry backend, or at your own collector, without touching a line of application code.

Microsoft Agent Framework and Semantic Kernel

Building agents on .NET? Microsoft Agent Framework (Microsoft.Agents.AI) and Semantic Kernel both send their agent and model telemetry to Logfire, so agent runs sit in the same traces as the requests and queries around them. Both go through the standard OpenTelemetry .NET SDK and an OTLP exporter, so there is still no vendor SDK in your project.

Traces, metrics, and logs in one place

Logfire is not just tracing. Send metrics and structured logs alongside your traces, build dashboards, and set alerts, all in the same OpenTelemetry-native project, and query all of it with the same SQL.

SQL instead of a query language you have to learn

Query your traces, metrics, and logs with PostgreSQL-compatible SQL. Any question you can express in SQL becomes a dashboard, an alert, or an ad-hoc investigation, and AI assistants are already fluent in it.

Query

Query your telemetry with SQL

select
  attributes->>'http.route' as route,
  count(*) as requests,
  avg(duration) as avg_seconds
from records
where duration > 1
group by route
order by avg_seconds desc;

Your traces, metrics, and logs are queryable with real SQL, no proprietary query language to learn. Any question you can express becomes a dashboard, an alert, or a one-off investigation.

Proof

In production

“You can tell that Pydantic Logfire was built by people who use it.”
Dennis Griffin, VP of Engineering, Sophos Read the case study
Decision guide

Is Logfire right for you?

Choose Logfire if

  • You already use ActivitySource and want a hosted backend for it
  • You want no vendor-specific types in your .NET codebase
  • You want to query traces, metrics, and logs with PostgreSQL-compatible SQL
  • You do not want to run Jaeger, Prometheus, and storage yourself
  • You want the option to repoint at another backend without a rewrite

Choose a vendor APM if

  • You want a vendor-maintained .NET SDK with vendor-specific APIs
  • You are already deeply integrated with a specific APM vendor's ecosystem
  • You need a vendor-only integration or compliance capability Logfire does not offer
FAQ

Common questions

Is there a Logfire SDK for .NET?

No, and .NET needs one less than most languages. Tracing primitives live in the base class library as System.Diagnostics.ActivitySource, which is the OpenTelemetry API in practice. You add the standard OpenTelemetry OTLP exporter and point it at Logfire. First-party Logfire SDKs exist for Python, TypeScript, and Rust.

Why is nothing arriving in Logfire?

Two usual causes. First, protocol: set OTEL_EXPORTER_OTLP_PROTOCOL to http/protobuf, because the OpenTelemetry .NET default can be gRPC, which Logfire does not expect. Second, source names: the string passed to AddSource must match the name given to the ActivitySource you create, or every span is silently dropped with no error.

Does this work with ASP.NET Core?

Yes. Add the OpenTelemetry ASP.NET Core instrumentation package and incoming HTTP requests become spans automatically, without changing your controllers. Your own ActivitySource spans then nest inside those request spans.

Do I need to change how I write code?

No. You use ActivitySource and Activity from System.Diagnostics, which are standard .NET types rather than anything vendor-specific. The instrumentation you write is portable to any OpenTelemetry-compatible backend.

Am I locked in to Logfire?

No. Configuration is standard OTEL_ environment variables and the standard exporter, and your code references only base class library types. Repoint the endpoint at another OpenTelemetry-compatible backend, or at your own collector, at any time.

Start seeing your .NET app

Get started with 10 million free spans, logs, and metrics per month. No credit card required.

Start free View pricing plans