.NET Observability from the team behind Pydantic: export ActivitySource spans, keep instrumentation vendor-neutral, and query everything in plain SQL. Standard OpenTelemetry, no lock-in.
Fetch and follow the instructions at https://pydantic.dev/agent-setup.md to set up Logfire for this project.
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocolexport OTEL_EXPORTER_OTLP_ENDPOINT='https://logfire-us.pydantic.dev'
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobufvar 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");Full details are in the .NET setup guide.
Trusted by teams building production software and AI
What lands in Logfire:
Microsoft.AspNetCore request span, with route and statusNpgsql query against Postgres, timedActivitySource spans, nested underneathSystem.Net.Http callStart free with 10 million spans, logs, and metrics each month. No credit card required.
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.
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.
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.
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.
Keep ActivitySource spans, Meter metrics, and ILogger records in one Logfire project. Shared resource attributes keep service identity consistent across them, so the service you filter in a trace search is the same one you chart or alert on.
Use PostgreSQL-compatible SQL to investigate ASP.NET routes, dependencies, tenants, or any attribute your application records. Save the result as a dashboard or alert when it becomes an operational question you ask repeatedly.
If you can ask it, SQL can find out
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;You can tell that Pydantic Logfire was built by people who use it.
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.
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.
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.
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.
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.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.