Skip to main content
Logfire for Java

Trace, monitor and debug your Java app

Java Observability from the team behind Pydantic: attach the Java agent, trace an existing service with one JVM flag, and query everything in plain SQL. Standard OpenTelemetry, no lock-in.

Install and configure
curl -LO https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

export OTEL_SERVICE_NAME=hello-java
# For EU-region projects, use https://logfire-eu.pydantic.dev instead.
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

java -javaagent:opentelemetry-javaagent.jar -jar your-app.jar

Full details are in the Java setup guide.

Trusted by teams building production software and AI

What you get

One request, one trace

A Logfire trace of a Java gRPC request, showing the OpenTelemetry gRPC and annotation instrumentation and the service's own spans

What lands in Logfire:

  • the request span from your servlet container or gRPC service, with no code changes
  • calls into JDBC, Kafka and HTTP clients, instrumented as the agent loads them
  • your own manual spans, if and when you add them
  • JVM metrics beside the traces: heap used, GC pause time, thread and loaded-class counts

One request, top to bottom — produced by the OpenTelemetry Java agent, with no application code changes.

Try it on your stack

See your own Java trace

Start free with 10 million spans, logs, and metrics each month. No credit card required.

How it works

Why the agent approach is a good deal

No code changes, no rebuild

The OpenTelemetry Java agent instruments supported libraries at class-load time. Your servlet container, JDBC driver, HTTP client, and messaging library start producing spans because of a JVM flag, not because you edited them. For an existing Java service that nobody wants to refactor, this is the cheapest observability you can buy.

Broad framework coverage you do not maintain

The OpenTelemetry Java agent instruments Spring Boot, Tomcat, Jetty, Netty, JDBC, Hibernate, Kafka, gRPC, Apache HttpClient, Cassandra, and much of the rest of its instrumentation catalogue. That coverage is maintained by the OpenTelemetry project rather than by a single vendor, so it keeps pace with the ecosystem rather than with one company's roadmap.

Standard OTLP, so genuinely no lock-in

Logfire is configured entirely through OTEL_ environment variables: an endpoint, a header, a protocol. Your application never references Logfire. Repoint those variables at another OpenTelemetry backend, or at your own collector, and nothing in the app changes.

Java signals in one project

Send Java agent traces and any OTLP metrics or logs to the same Logfire project. The service and resource attributes stay queryable across signals, so a production investigation does not stop at the edge of a trace.

SQL instead of a query language you have to learn

Use PostgreSQL-compatible SQL to compare Java services by route, dependency, status, or any attribute the instrumentation records. A useful investigation can be saved as a dashboard or alert without translating it into another query language.

Query

Query your Java telemetry with SQL

If you can ask it, SQL can find out

  • Query your traces, metrics and logs with real SQL
  • No proprietary query language to learn
  • AI models are great at writing SQL
  • From a one-off investigation to an alert, dashboard, or SLO
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;
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 want traces from an existing Java service without changing its code
  • You want the standard OpenTelemetry agent rather than a proprietary vendor agent
  • You want to query traces, metrics, and logs with PostgreSQL-compatible SQL
  • You want a hosted backend without running Jaeger, Prometheus, and storage yourself
  • You want the option to repoint at another backend without touching the application

Choose a vendor APM if

  • You want a vendor-maintained Java 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 Java?

No, and you do not need one. Java uses the standard OpenTelemetry auto-instrumentation agent, and Logfire is the OTLP backend it reports to. That means there is nothing proprietary to adopt and nothing to remove later. First-party Logfire SDKs exist for Python, TypeScript, and Rust.

Do I have to change my application code?

No. The OpenTelemetry Java agent attaches at JVM start with the -javaagent flag and instruments supported libraries as they are loaded, so your servlet container, JDBC driver, HTTP client, and messaging library produce spans without any source changes. You can add manual spans later for your own business operations.

Why is nothing arriving in Logfire?

The most common cause is protocol. Logfire expects OTEL_EXPORTER_OTLP_PROTOCOL set to http/protobuf, while some OpenTelemetry setups default to gRPC. After that, check the endpoint matches your project's data region and that the Authorization header carries a valid write token.

Does this work with Spring Boot?

Yes. Spring Boot is covered by the OpenTelemetry Java agent's instrumentation catalogue, so the same -javaagent flag applies with no extra configuration. The agent also covers JDBC, Kafka, and gRPC among many others.

Am I locked in to Logfire?

No. Configuration is entirely standard OTEL_ environment variables, so your application has no knowledge of Logfire at all. Repoint the endpoint at a different OpenTelemetry-compatible backend at any time, or self-host, without touching your application or its instrumentation.

Start seeing your Java service

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