OpenTelemetry-native observability for any Go service, from the team behind Pydantic. Keep the standard OTel SDK and contrib packages you already use, with no vendor imports in your code, and query every trace with SQL. Free for 10 million spans, logs, and metrics a month.
export OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_SERVICE_NAME=hello-gofunc main() {
ctx := context.Background()
exporter, err := otlptracehttp.New(ctx)
if err != nil {
log.Fatal(err)
}
tracerProvider := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))
defer tracerProvider.Shutdown(ctx)
otel.SetTracerProvider(tracerProvider)
otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(
propagation.TraceContext{}, propagation.Baggage{},
))
}Unlike Java, Go has no runtime agent, because a compiled binary has no bytecode to rewrite. You wire the exporter up once in code, then use the OpenTelemetry contrib packages for handlers and clients. There is no Logfire Go SDK to adopt. Full details are in the Go setup guide.
What lands in Logfire:
otelhttp server span, with route and statusdatabase/sql query, timed, via otelsqlLogfire accepts http/protobuf, which is exactly what otlptracehttp sends. Set the endpoint and the Authorization header, build a tracer provider with a batch processor, and register it. There is no vendor SDK to learn and no wrapper around the OpenTelemetry API.
otelhttp wraps net/http handlers and clients, otelgrpc covers RPC, and there are contrib packages for gin, echo, chi, database/sql, and the AWS SDK. All of them export to Logfire unchanged, because Logfire is a backend rather than a framework. If it emits OTLP, it arrives.
Spans follow context.Context the way Go code already passes it, so nested work inside a process is attributed to the right parent across goroutines. You are not adopting a second, parallel way of threading request state through your program. Crossing a service boundary is the propagator's job: register TraceContext once, as in the setup above, and otelhttp puts the traceparent header on outbound requests and reads it on inbound ones.
Building agents in Go? Firebase Genkit registers a standard OTLP exporter as its global tracer provider, and CloudWeGo Eino traces through the same path, so agent and tool telemetry lands in the same traces as your HTTP handlers and database calls. No separate agent-observability tool to run alongside.
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.
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.
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.
“You can tell that Pydantic Logfire was built by people who use it.”
No. Go uses the standard OpenTelemetry Go SDK, and Logfire is the OTLP backend it exports to. Nothing proprietary enters your codebase. First-party Logfire SDKs exist for Python, TypeScript, and Rust.
Java has a JVM agent that rewrites bytecode as classes load, so instrumentation can be attached at startup with a flag. Go compiles to a static binary, so there is nothing to attach to at runtime. Instrumentation has to be wired in explicitly: create an exporter, build a tracer provider, and register it.
Check three things. Use the HTTP exporter, otlptracehttp, unless you have deliberately configured gRPC, since Logfire expects http/protobuf. Confirm the endpoint matches your project's data region. Finally make sure the tracer provider is shut down cleanly on exit, because the batch processor flushes on shutdown and a killed process loses buffered spans.
Yes. otelhttp, otelgrpc, and the database instrumentation wrappers all work unchanged, because Logfire is a backend rather than a framework. Anything that exports OTLP reaches Logfire.
No. Configuration is standard OTEL_ environment variables against the standard SDK, so your application code has no Logfire-specific imports. Repoint the endpoint at another OpenTelemetry-compatible backend, or at your own collector, whenever you want.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.