Go Observability from the team behind Pydantic: keep the standard OTel SDK and contrib packages you already use, keep vendor code out of your binary 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.
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{},
))
}Full details are in the Go setup guide.
Trusted by teams building production software and AI
What lands in Logfire:
otelhttp server span, with route and statusdatabase/sql query, timed, via otelsqlStart free with 10 million spans, logs, and metrics each month. No credit card required.
Logfire 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.
Export spans, metrics, and structured logs from Go services over OTLP into one project. Resource attributes such as service.name stay attached, so the same service filter works in a trace search, dashboard, or alert.
Use PostgreSQL-compatible SQL to group Go telemetry by route, gRPC method, dependency, or any attribute your instrumentation records. Save the result as a dashboard or alert when the investigation becomes something you want to keep.
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. 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.