Open Source APM Tools
Observability has a backwards cost curve: the more traffic an application handles, the more traces, metrics, and logs it emits, so a hosted monitoring bill climbs fastest at exactly the moment an incident makes that data most valuable. Teams respond by instrumenting less, which is the opposite of what you want. The open source stacks here collect the same signals into storage you run yourself, so the cost tracks the hardware you provision rather than a per-gigabyte meter on telemetry volume. Long retention stops being a line item you ration, and the request paths, headers, and query text in your traces never leave infrastructure you control.
SigNoz
Open-source observability platform for logs, traces, metrics, alerts, and exceptions in one tool
Apache SkyWalking
Open source APM for microservices and cloud native systems with tracing, metrics, logs, profiling, and alerts
Jaeger
Distributed tracing system for monitoring and troubleshooting workflows in complex distributed systems
OpenObserve
Open source observability platform for logs, metrics, traces, RUM, and pipelines
Pinpoint
APM for large-scale distributed systems with transaction tracing, topology maps, and real-time monitoring
HyperDX
Open source observability platform for logs, metrics, traces, errors, and session replay on ClickHouse
Coroot
eBPF-powered observability and APM with AI-guided root cause analysis
Uptrace
OpenTelemetry-native APM for traces, metrics, and logs with self-hosted and cloud options
Elastic APM
Application performance monitoring for the Elastic stack, with distributed tracing on Elasticsearch
Our picks
All-in-one OpenTelemetry platform: SigNoz SigNoz brings logs, metrics, traces, alerts, and exceptions into one interface, built on OpenTelemetry instrumentation and ClickHouse storage. It correlates the three signals so you can move from an error rate to the trace behind it, and it positions itself as an alternative to Datadog and New Relic. The community edition is MIT-licensed and self-hostable.
Distributed tracing specialist: Jaeger Jaeger does one job thoroughly: tracing a request across every service it touches to locate latency and errors. It ingests OpenTelemetry data over HTTP or gRPC, writes to pluggable storage backends, and offers sampling controls to keep trace volume manageable. A CNCF project that has passed third-party security audits, it fits when you already have metrics and logs.
Zero-code instrumentation via eBPF: Coroot Coroot collects metrics, logs, traces, and profiles automatically with eBPF, so even legacy or third-party services are covered without code changes. On top of that data it builds a service map, distributed tracing, log pattern clustering, and SLO-based alerting, with automated root cause analysis. The Apache-licensed community edition runs on Docker or Kubernetes.
Log-scale, object-storage backend: OpenObserve OpenObserve is a single Rust binary that stores telemetry as Parquet on object storage, which keeps large log and trace volumes affordable. It offers full-text log search, SQL and PromQL queries, dashboards, OpenTelemetry tracing, and real user monitoring with session replay. Native multi-tenancy and a stateless design suit teams that want observability without stitching several systems together.
What actually matters when picking an APM stack
The value of an APM stack is decided upstream of the tool, by the telemetry it receives, so begin with how your services will be instrumented. Most platforms here are built around OpenTelemetry - SigNoz, Jaeger, OpenObserve, HyperDX, and Uptrace all ingest OTel traces - which keeps instrumentation vendor-neutral and portable if you later change backends. Coroot takes a different route, using eBPF to collect metrics, logs, and traces with no code changes, reaching legacy services an SDK cannot. Apache SkyWalking and Pinpoint lean on their own agents, with deep roots in Java. Match the collection model to the runtimes you actually run.
Then decide whether you want one screen or one signal. Jaeger is deliberately tracing-only and pairs with a separate metrics stack, while SigNoz, OpenObserve, HyperDX, Coroot, and Uptrace correlate logs, metrics, and traces so you can move from a slow request to its trace, related logs, and host metrics in one place. If your team debugs from logs today, test that exact click path first, because tight correlation is the difference between a fast diagnosis and four tabs of guesswork mid-incident.
Finally, the storage engine underneath determines cost and behavior under load. Several of these run on ClickHouse - SigNoz, HyperDX, Coroot, and Uptrace - which handles high-cardinality event data cheaply, while OpenObserve uses Parquet on object storage and Elastic APM stores in Elasticsearch. High-cardinality data from endpoints, tenants, and deployments is where these backends strain, so test ingestion, retention, and query latency with realistic data, not a demo trace, before you rely on it.
Related categories
Frequently asked questions
What does OpenTelemetry-native mean, and why care?+
OpenTelemetry is a vendor-neutral standard for emitting traces, metrics, and logs. When a backend ingests OTel directly, as SigNoz, Jaeger, OpenObserve, HyperDX, and Uptrace do, your instrumentation lives in your code rather than in a vendor's proprietary agent. That means switching backends later is mostly a matter of repointing a collector, not re-instrumenting every service. It is the single biggest defense against lock-in in this category.
Do I need a full observability platform or just distributed tracing?+
It depends on the gap you are filling. Jaeger does one thing well: distributed tracing, which you pair with a separate metrics and logging stack. Platforms like SigNoz, OpenObserve, HyperDX, Coroot, and Uptrace bundle logs, metrics, and traces together. If you already run Prometheus and a log store and only lack tracing, Jaeger slots in cleanly; if you are starting fresh, a combined platform is fewer moving parts.
How do these tools keep logs, metrics, and traces connected?+
The better platforms correlate signals so you can jump from a slow request to its trace, then to the related logs and host metrics without losing context. SigNoz, HyperDX, Coroot, and Uptrace are built around this. Tools that store each signal separately rely on matching timestamps and labels, which is slower during an incident. Test the click path from a log line to a trace and back before you commit.
Why does the storage engine matter in an APM tool?+
It sets your cost and how the system behaves under load. High-cardinality data from endpoints, users, tenants, and deployments is what strains observability backends. Several tools here use ClickHouse - SigNoz, HyperDX, Coroot, and Uptrace - for cheap high-cardinality queries, OpenObserve uses Parquet on object storage, and Elastic APM uses Elasticsearch. Test ingestion and query latency with realistic cardinality, since a demo with a few labels tells you nothing about production.
What is eBPF instrumentation and when should I use it?+
eBPF lets a tool observe application behavior from the Linux kernel without changing your code. Coroot uses it to collect metrics, logs, and traces automatically, which is valuable for legacy or third-party services you cannot easily instrument by hand. The tradeoff is that kernel-level collection sees system calls and network activity rather than rich in-application context, so many teams combine eBPF coverage with OpenTelemetry where they can add SDKs.
How does sampling affect what I can debug?+
Sampling controls how many traces you keep, and it is central to both cost and usefulness. Head-based sampling decides up front and is simple but can drop the one failed request you needed. Tail-based sampling keeps slow or error traces while discarding routine traffic, at the cost of more collector capacity. Jaeger exposes sampling controls directly. Set policies per service and error rate rather than one global rate.
How hard is it to move off a commercial APM like Datadog?+
It depends on your instrumentation, not the backend. If your services already emit OpenTelemetry, the switch is mostly rerouting the collector and rebuilding dashboards and alerts, which is why SigNoz, HyperDX, Coroot, and OpenObserve position themselves as Datadog alternatives. If you rely on proprietary agents and custom annotations, expect code changes. Historical data rarely migrates cleanly, so many teams run both during a cutover window.