Best Open Source APM Tools for Application Performance Monitoring

"The site is slow" is the least useful bug report in software, and an application performance monitoring tool exists to turn it into something actionable: this request took 1.8 seconds, 1.6 of which were one N+1 query in the orders service. The awkward part is choosing the tool, because the market splits into two groups that rarely get compared honestly. Commercial platforms are polished and expensive. Open source platforms are free to license and cost you engineering time instead.

This guide is biased to the open-source and self-hosted side, then tells you straight out where you're better off paying for a commercial product. The licenses, release status, and OTLP support below have been validated against each project's own documentation and release history, and not lifted from vendor comparison pages.

Quick comparison of the best open source APM tools

Two things decide most of these choices, and neither is a feature checklist. The first is how telemetry gets out of your applications, because that determines whether you can change your mind later. The second is what you have to operate underneath the platform, since a free license and a free deployment are not the same thing. Each tool name below jumps to its full profile.

The Signals column is worth defining first, because these words get used loosely. Traces follow individual requests across services. Metrics show aggregated rates, latency, errors, and resource behavior over time. Logs preserve detailed application events. Profiles show where CPU time or memory is spent inside running code. RUM, meaning real user monitoring, measures performance from the end user's browser or device. A platform does not need every signal to be useful, so let the signals you actually need drive the shortlist rather than the longest row.

Jaeger and the Grafana stack are components rather than platforms. Jaeger stores traces and nothing else, and the Grafana projects are assembled into a stack rather than shipped as one backend. Both are excellent, but neither is a like-for-like swap for SigNoz or Datadog without extra parts.

What to look for when selecting an APM tool

Most comparison tables reward whatever product ticks the most boxes, which is the wrong instinct. These are the criteria that actually turn the dial:

• Transaction visibility: the capability of a tool to track an individual request through all the services it passes through and to report on where time was spent, rather than just aggregated numbers per service. Transaction visibility is one of the main capabilities that separates modern APM from basic infrastructure and service monitoring. A dashboard that says the checkout service is slow leaves you wondering. A trace that shows 700 out of 900 milliseconds spent in one downstream call settles the debate.
• Signal to signal correlation: tracing back a latency spike to the traces behind it, and from a trace to the log lines that particular request generated. This sounds like a nice-to-have until you are debugging at two in the morning, at which point it is the difference between minutes and an hour. Tools that store signals in one location tend to do this easily, but tools that federate across several stores need configuration to make it work.
• Language and runtime coverage: examine your actual stack, not the marketing list, because coverage is uneven in ways the summary tables disguise. Java and .NET are well provided almost everywhere. Rust, Elixir and PHP vary a lot. Some of the agents that claim to support a language are actually community-maintained, not first-party. A single unsupported runtime can create a major visibility gap, so verify coverage for every important language in your stack.
• Instrumentation model: OpenTelemetry makes you portable, so you can switch backends later without altering application code. A proprietary agent can go deeper because it is connected to one platform, while eBPF gives you broad coverage without code changes but less application-specific context. This choice outlives the tool choice, since changing a backend is usually much easier than replacing instrumentation across numerous services.
• Operational footprint: ClickHouse, Elasticsearch, and HBase are all real operations, not implementation details. Somebody has to size them, supervise them, upgrade them, and back them up. Be honest about whether you have that person on your team, because the most common way a self-hosted APM project fails is not the tool being bad but no one owning the database.
• Cost of storage and retention: telemetry tends to rise quicker than teams expect. Logs are frequently the bulk of the volume, but traces can also be costly at high request rates without sampling, so work out each signal independently against your predicted ingestion rate and retention length. Object storage and columnar formats impact the economics dramatically, which is why a platform that keeps Parquet on object storage has a different cost curve than one that requires hot disk on a cluster.
• Licensing reality: some of the projects listed are open core, so check that the functionality you need is in the free edition and not behind an enterprise tier. The common dividing line is single sign-on and role-based access control, and finding out that they are premium features after you have deployed the product to three teams is an awkward conversation.

The best open source APM tools

Here are the platforms and components to shortlist. All entries below are the same shape so you can read one tool or compare the same line for all 10.

SigNoz

If your team wants traces, metrics and logs in a single self-hosted OpenTelemetry-first platform instead of a bunch of components strung together, then SigNoz is one of the most compelling options. Application instrumentation is mostly portable since OpenTelemetry is the major instrumentation model, and OTLP is the native path in. Be clear about what that portability covers: dashboards, saved searches, alert definitions, and retention rules are backend-specific and stay behind if you leave.

• Best fit: polyglot stacks looking for the Datadog experience without the Datadog invoice, and that have a person willing to own a database. The sweet spot is a team already committed to OpenTelemetry, because that is the approach around which the product is developed.
• Signals: traces, metrics, logs and exceptions in one store, which is what makes correlation actually meaningful rather than three tools behind one login. You can move from a p99 spike on an endpoint, to the traces behind it, to the log lines those requests emitted without changing tools. The most significant gap is continuous profiling.
• Instrumentation: OpenTelemetry, with no proprietary SigNoz agents to install. Since the ingest tier is an OpenTelemetry Collector, it can also receive other suitable formats such as Jaeger and Zipkin. The trade-off of this approach is that applications without an OpenTelemetry path yet need to build one before SigNoz will show a single trace.
• Self-hosting: SigNoz plus ClickHouse, with a collector in front. A single-node deployment is enough to begin, and clustering or replication is only necessary when scale or high availability demands it.
• License: MIT core, enterprise features in separate directories, no data caps on the community edition, so the open core divide is about features and not volume.
• Watch out for: the ClickHouse operating load, which is normally what determines whether this decision works out. Somebody has to size it, observe disk growth, handle updates and set retention per signal. That last one is the one people skip, and the platform fails quietly weeks later when the disk is full.

Apache SkyWalking

SkyWalking is an Apache Software Foundation project under Apache-2.0, which gives it a straightforward foundation-governed licensing model. People stick around for its automatic service topology mapping.

• Best fit: Java-heavy estates that require service maps and code-level diagnostics without a procurement cycle, and are large enough that automatic topology pays for the added operational work.
• Signals: traces, metrics, logs, events, in-process and eBPF profiling, browser monitoring, topology, and alarms, which is unusually broad built-in coverage. The topology map stands out because it constructs a correct service graph without anyone needing to keep a diagram up to date.
• Instrumentation: first-party agents for Java, Python, Go, Node.js, PHP, and Ruby, plus OTLP and Zipkin receivers. SkyWalking supports OpenTelemetry, though its native agents are most closely aligned with its own analysis model and topology features. Choose which side of that trade you want: use OTLP if portability is more important, and consider the native agents if you want the richest SkyWalking-specific diagnostics. The .NET and C++ agents are third-party.
• Self-hosting: BanyanDB by default, purpose-built for SkyWalking's access patterns, with Elasticsearch, OpenSearch, MySQL or PostgreSQL as alternatives. There is no built-in zero-dependency option any longer, therefore even a trial requires a store.
• License: Apache-2.0 everywhere, no enterprise tier, no features held back, so no open core border to audit before you deploy.
• Watch out for: more moving parts and a steeper learning curve than the simpler all-in-one platforms, so the first week costs more than it would with SigNoz or Uptrace.

OpenObserve

OpenObserve is about storage economics, not features. It is written in Rust, and stores data as Parquet on local disk or object storage rather than in a database cluster. So when log volume is what makes observability expensive, the arithmetic changes considerably.

• Best fit: teams for whom the problem is telemetry volume, not the feature list, which frequently means the logging bill is the reason observability is under review. At high telemetry volumes, storage architecture can matter more than small differences in dashboards or UI features.
• Signals: logs, metrics and traces, with logging and search clearly the strongest aspect of the product. If you are shortlisting on APM grounds, then this is the profile to study carefully. OpenObserve is observability-first, not APM-first. If your primary use case is deep transaction analysis, service dependency workflows and application-specific diagnostics, compare it with APM-first systems like SigNoz or SkyWalking. Its real differentiator is telemetry storage and search economics, not an opinionated APM workflow.
• Instrumentation: OpenTelemetry over OTLP on both HTTP and gRPC, using upstream SDKs and nothing proprietary of its own. Language coverage is therefore whatever OpenTelemetry supports.
• Self-hosting: Parquet on local disk or object storage, with no ClickHouse or Elasticsearch underneath. The key structural difference from SigNoz and Uptrace is that absence. High availability is a bigger step than the single-node simplicity suggests, since it adds PostgreSQL and NATS.
• License: AGPL-3.0 core. The self-hosted enterprise edition with SSO and RBAC is free for ingesting up to 50 GB per day, which is liberal compared to rivals that lock authentication down instantly.
• Watch out for: maturity, not capability. You are working with a younger UI and smaller ecosystem, so there are fewer answers in the community and fewer worked examples when something acts oddly. Weigh that against what the storage savings are worth to you.

Uptrace

Uptrace is the lightweight option in the ClickHouse-backed family. It gives you the service graph, RED metrics, and latency percentiles that the larger systems deliver, but the deployment is small enough to run safely on a single modest server.

• Best fit: a solo developer or small team that wants tracing, metrics and logs in one location without having to stand up a cluster. The obvious question is why you would choose this over SigNoz, and the honest answer is footprint and not telemetry model. Uptrace makes sense if you want an OpenTelemetry-first backend but do not need SigNoz's wider ecosystem or broader operational approach. Expect a less complicated deployment, not a fundamentally different method.
• Signals: traces, metrics and logs. Errors are surfaced from spans and log records, not as a separate signal with its own workflow. There is no profiling and no real user monitoring, so treat those as absent rather than roadmap.
• Instrumentation: OpenTelemetry via OTLP, with ingestion from Prometheus, Vector, FluentBit and CloudWatch. That last set is more important than it looks, because Uptrace can take in telemetry you already collect through other pipelines instead of making you re-instrument everything first.
• Self-hosting: ClickHouse for telemetry with PostgreSQL for metadata, single-node or replicated. Despite the ClickHouse dependency it is designed to sit on one modest server, so the operational profile is significantly lighter than a clustered SigNoz implementation.
• License: AGPL-3.0 plus commercial cloud and on-premises tiers, so check the LICENSE file for whichever build you plan to deploy rather than assuming the terms carry over.
• Watch out for: its smaller project and community footprint, which means fewer third-party examples, integrations, and community replies than the larger platforms, and a shorter bench if a maintainer moves on.

Coroot

One tool that deserves more attention than it gets is Coroot. What it does is use eBPF to watch traffic at the kernel level and automatically derive a service map, latency, and error rates without asking you to instrument anything. On Kubernetes you get topology and SLO dashboards within minutes of installing it.

• Best fit: Kubernetes clusters and legacy or third-party services nobody wants to touch. It is also the realistic option when instrumenting applications is politically hard rather than technically challenging, since you do not need approval from another team before you can observe their traffic.
• Signals: Coroot can collect metrics, container logs, eBPF traces, and CPU profiles without application code changes. OpenTelemetry and runtime-specific profilers add deeper traces and richer profiling where needed. SLO tracking, deployment tracking, cost monitoring, and a large range of predefined automatic checks sit on top of that base. Those inspections are what differentiate it in everyday use, because the product tells you what looks wrong rather than waiting for you to build the dashboard that would have revealed it.
• Instrumentation: eBPF node and cluster agents for the zero-code path, with OpenTelemetry accepted for traces when you want greater depth. The two coexist deliberately, so you can start with eBPF everywhere for coverage and add OpenTelemetry only where you need in-code detail. On top of that language-agnostic layer sit language-specific inspections for the JVM, .NET and Python.
• Self-hosting: ClickHouse for logs, traces and profiles, plus a Prometheus-compatible store for metrics. It runs on plain Linux hosts as well as Kubernetes.
• License: Apache-2.0 community edition with a commercial enterprise edition alongside it, backed by a company rather than a foundation.
• Watch out for: the limits of inferring from external observation. Coroot excels at discovering service relationships, latency, failures and runtime behavior without touching application code. What it cannot always derive from outside the process is semantic context: business attributes, framework-specific spans, and custom application data that only the code knows about. Add in-process OpenTelemetry to the services where you need that.

Running Coroot for breadth and OpenTelemetry for depth on key services makes sense. If you’re interested in the eBPF layer without a whole platform, then OpenTelemetry eBPF Instrumentation is the upstream project to follow, and Grafana Beyla is now a downstream distribution of it.

Elastic APM

If you already use Elasticsearch, then Elastic APM is worth considering largely because adding APM data alongside existing logs is a tiny step, rather than a new platform. Trace and log correlation is good exactly because they live in the same store.

• Best fit: teams that have an Elasticsearch cluster in production and the people who know how to run it. It is all about that starting position, because what is a no-brainer for a team already running Elastic is hard to justify for a team with no Elasticsearch experience.
• Signals: traces, metrics, logs, errors, real user monitoring, and continuous profiling, which is more than most single products here cover. Some Elastic capabilities still depend on Elastic-specific components, so check feature parity before replacing an existing APM-agent deployment with EDOT.
• Instrumentation: Elastic is gradually embracing OpenTelemetry through its EDOT distributions as the preferred road forward for new deployments, while its classic APM agents remain maintained and relevant for existing deployments and some Elastic-specific features. Both are supported. The practical question is whether you are starting fresh, in which case EDOT is the way to go, or expanding something that already runs the classic agents.
• Self-hosting: self-hosting Elastic APM means operating Elasticsearch; managed Elastic offerings remove that operational burden.
• License: a mixed model spanning Elasticsearch, Kibana, APM Server and commercial features, and one that is commonly misreported. Do not think of "Elastic" as one license; check the license for the precise components you wish to deploy.
• Watch out for: resource appetite, which is the practical objection. Elasticsearch is a memory and disk hog compared to the ClickHouse-backed alternatives, so if you are starting from scratch that alone is a reason to look elsewhere. With an existing Elasticsearch cluster the marginal cost is low and the decision flips.

Grafana stack

In this comparison, the Grafana ecosystem is the build-your-own alternative. The appeal is to preserve whatever already works. Teams who have a mature Prometheus setup and dashboards that people trust do not need to throw any of it away, and Grafana on Ubuntu is typically already operating somewhere.

• Best fit: shops already invested in Prometheus and Grafana, with operational capacity to manage several services. The argument is continuity, not capability, because you add tracing and profiling beside dashboards your team already trusts instead of discarding working alert rules.
• Signals: metrics through Mimir or plain Prometheus, logs through Loki, traces through Tempo, profiling through Pyroscope. The one query surface is Grafana. Each piece scales independently, and you can take them one at a time, but the correlation between signals is something you configure, not something you acquire.
• Instrumentation: Alloy, Grafana's own distribution of the OpenTelemetry Collector, collects OpenTelemetry data for metrics, logs, traces, and profiles all in one agent. Grafana Beyla adds an eBPF option for zero-code coverage.
• Self-hosting: a distinct backend per signal, each writing to object storage. There is no need to run all of them, since Prometheus can replace Mimir and profiling is optional. The key strength is object storage as the shared backend, because it makes lengthy retention affordable without a database cluster.
• License: the Grafana backends (Tempo, Loki, Mimir and Pyroscope) are AGPL-3.0, while Prometheus and Alloy are Apache-2.0.
• Watch out for: the difference between an ecosystem and a product, which matters more than component quantity. Maximum flexibility means keeping metrics, logs, traces and profiles separate, and the price is that you put together the APM experience yourself. Correlation, retention, alerting and service workflows all depend on how you link the pieces. Your team needs PromQL, LogQL and TraceQL rather than one query language. SigNoz, SkyWalking and Elastic are opinionated products by comparison, and that opinion is doing work you would otherwise have to do.

Or you can buy that packaged experience as a managed service from Grafana Cloud Application Observability if you do not want to operate the pieces yourself.

Jaeger

Jaeger is CNCF graduated, it is reliable and it performs one thing only. It is included in the comparison since distributed tracing is the basic diagnostic layer of APM and many teams assess it alongside entire platforms, but it should not be confused with a full metrics, logs and APM suite. Version 2 is a custom distribution of the OpenTelemetry Collector, hence it is OTLP-native and does not require any client libraries on its own.

• Best fit: learning distributed tracing, demonstrating its worth to a skeptical team, or serving as the tracing piece of a stack you build yourself. Version 2 is also a practical starting point when you have not chosen a long-term backend, as it is a Collector under the hood: instrument with OpenTelemetry, aim it at Jaeger today, and repoint the exporter later without altering application code.
• Signals: just traces, and that is an intentional choice rather than a gap to be filled. Service Performance Monitoring can pull request rate, error rate and duration from spans, but it requires a separate Prometheus-compatible store to do so. No logs.
• Instrumentation: OpenTelemetry SDKs. The old Jaeger client libraries are retired and any instruction asking you to add a Jaeger tracer library is out of date. The backend still supports several wire formats, and if you need additional components you can build a custom distribution using the OpenTelemetry Collector Builder.
• Self-hosting: a single container with in-memory storage is enough for a trial. Production means Cassandra, Elasticsearch or OpenSearch, with ClickHouse still experimental. You can split primary and archive tiers so current traces stay fast and older ones move somewhere cheaper.
• License: Apache-2.0, and CNCF graduated, the foundation's highest maturity level and a good proxy for longevity if that is a selection criterion.
• Watch out for: the scope, above everything else. Jaeger provides tracing rather than a complete APM stack, so metrics, logs, and broader application workflows require additional components. Budget for those pieces rather than treating Jaeger as a destination. Version 2 additionally requires an explicit configuration file, which is a breaking change when updating a version 1 deployment.

Glowroot

Glowroot requires less setup for a single Java application than anything else here: only one agent JAR on the JVM command line, and no external database, since it keeps data in an embedded H2 file and offers its own UI. It is actively maintained, contrary to a lot of stale advice.

• Best fit: a single JVM or small fleet where you want answers in minutes, not a platform to operate. That suits a circumstance many teams are familiar with, which is wanting to debug a slow Java application now, on a server you can restart once, without having a debate about infrastructure.
• Signals: transaction breakdowns with response time percentiles, slow traces with full call trees, JDBC queries with bind parameters, errors with stack traces, JVM metrics, and thread profiling. The bind parameter capture, in particular, turns an unclear slow query into an obvious one.
• Instrumentation: its own Java agent, added as -javaagent on the JVM command line, with no documented OTLP path. Nothing you set up here carries over to another tool. This is an acceptable exchange at this scale, and a serious expense if the deployment grows.
• Self-hosting: just a JAR file on a single JVM, because it has its own storage and web interface. Covering several JVMs means a central collector backed by Cassandra, which is where operating cost finally appears.
• License: Apache-2.0, maintained by a small community without any vendor or foundation behind it, so the bus factor is a real concern rather than a theoretical one.
• Watch out for: Java exclusively, and instrumentation that does not come with you if you outgrow it. Use the GitHub releases page for the latest version instead of glowroot.org, since the download page on the project site lags well behind and is the primary reason people incorrectly think the project is abandoned.

Pinpoint

Pinpoint from Naver targets the opposite end of the Java market from Glowroot. It generates very detailed call trees inspired by the Google Dapper paper, real-time active thread charts and a ServerMap topology.

• Best fit: large Java estates that really need code-level depth and have the infrastructure budget to match. The qualifier is important because at small scale the operating cost of the storage layer overwhelms the value, and at large scale the detail of the call tree is difficult to achieve by any other means.
• Signals: distributed traces with code-level call stacks, ServerMap topology, real-time active thread charts, request and response scatter charts, JVM internals via the Inspector view, URI metrics and alarms. The scatter chart is a surprisingly good way to detect a bimodal latency distribution that percentiles alone would obscure.
• Instrumentation: its own Java agent over gRPC rather than OTLP. The agent has very wide coverage for framework, application server, messaging and JDBC instrumentation, so the stack you actually run is probably covered out of the box, and the plugin list is the place to confirm. PHP and Python come from a separate agent repository.
• Self-hosting: by far the most demanding requirement here, because it needs HBase to store traces and Apache Pinot for the metrics pipeline. Agent and collector versions must also match, so upgrades across a big fleet are something you plan rather than improvise.
• License: Apache-2.0, initially created by NAVER Corp and now primarily community managed.
• Watch out for: language coverage and portability combined. There is no .NET, Node.js or Go support, so anything outside Java and the two secondary agents is invisible. Add instrumentation that cannot transfer elsewhere and the storage footprint, and the cost is only justified when the Java estate is truly large.

Which APM tool should you choose?

Whichever row matches, treat the instrumentation decision separately from the backend decision. Changing the backend is quite cheap. Changing how your applications send telemetry is not. If any of the commercial rows apply to your case, open source vs commercial APM farther down explains what you get and what you lose.

APM tools with OpenTelemetry

OpenTelemetry is a CNCF graduated project that defines the SDKs, the automatic instrumentation agents and the wire protocol (OTLP) to emit telemetry. It is not a backend on purpose. It aggregates and moves data, and something else has to store, index and visualize it, therefore it is an addition to, not a replacement of, anything in the above comparison.

Its value is that instrumentation is not a vendor choice anymore. Most modern platforms in the comparison support OTLP directly or via an OpenTelemetry Collector, but some tools still rely primarily on their own instrumentation: Glowroot and Pinpoint use their own Java agents, and SkyWalking accepts OTLP, but its native agents integrate more tightly with its own analysis model. When OTLP is supported, the transition to a different backend is a modification to one export target and not a re-instrumentation project:

exporters:
  otlp:
    endpoint: apm-backend:4317

That is the practical side of it, the Collector. It accepts telemetry and passes it through processors that batch, filter, sample or strip attributes before exporting it to one or more destinations simultaneously. The Collector can export the same telemetry to multiple destinations, which makes backend evaluation and migration easier without changing application instrumentation. The same approach applies inside Kubernetes, where OpenTelemetry tracing for controller-runtime operators shows the instrumentation side in a Go codebase.

But none of this makes OpenTelemetry a slam dunk. Support varies by signal and language: tracing is mature across the major runtimes but logging and profiling vary quite a bit, so check the official status page for the runtimes you care about. There still remains a justification for proprietary agents, some offering deeper automatic profiling, richer transaction breakdowns or platform-specific diagnostics that generic telemetry does not capture. If portability is a must, especially for new distributed applications, go with OpenTelemetry, and keep vendor agents in mind where the extra depth really improves your workload.

Monitoring vs observability vs APM

These three phrases are used interchangeably in tool listings, and that is why articles show JConsole right next to Dynatrace as if they are solving the same problem. They speak of expanding circles, not competing products:

• Monitoring alerts you that something is wrong against thresholds you set up beforehand. Good here are Zabbix and Nagios: host up or down, disk filling, service not responding.
• Observability is the wider habit of collecting enough telemetry that you can explore questions you never thought to configure a check for.
• APM is the application-oriented slice that explains why a particular transaction was sluggish, using transaction tracing, error tracking, service dependencies, and code-level diagnostics.

That distinction places numerous familiar tools in their appropriate position. Prometheus is a metrics monitoring and alerting toolkit, and it is the metrics component of an observability stack rather than an APM platform by itself. Grafana is a visualization layer that displays data stored by other systems, which is why Grafana with Prometheus is a combination and not a product. Jaeger and Zipkin solely cover tracing. JConsole, VisualVM and Java Flight Recorder are JVM-level diagnostic tools attached to one process at a time, great for a deep dive and worthless for following a request over ten services.

None of these are bad tools. They answer a narrower question than "why was this checkout request slow", and any comparison that claims otherwise will lead you astray. Host-level checks with top, CPU utilization, and per-process memory sit at the same level: necessary, and not a replacement for tracing.

Open Source APM for Java

Java has the richest open source APM tooling of any runtime because the JVM exposes instrumentation hooks that no other runtime equals. It is all about scale:

• One JVM or a monolith, results today: Glowroot.
• A large distributed Java system that also runs other languages: Apache SkyWalking.
• Ultra-detailed Java call tracing, with infrastructure to match: Pinpoint.
• A traditional servlet program that needs simple numbers: JavaMelody, still maintained, though it is in-JVM monitoring rather than distributed tracing.
• A one-off deep diagnosis of a leak or lock contention: Java Flight Recorder and VisualVM, which are diagnostic tools rather than continuous APM.

The trap is to consider the last group as an APM option. JFR and VisualVM will detect a memory leak faster than anything on this list, yet neither will tell you which of ten services caused a sluggish checkout request.

Open Source vs. Commercial APM

Self-hosting costs money. It costs servers plus someone's attention, and the minute your observability platform pages you at 3 AM for its own purposes, you are paying a different kind of charge. The honest division is as follows:

Some of the popular commercial options include Datadog, Dynatrace, New Relic, Splunk AppDynamics, Splunk Observability Cloud, IBM Instana, and ManageEngine Applications Manager, and cloud-native options like AWS CloudWatch Application Signals and Azure Monitor Application Insights. Datadog and New Relic are SaaS only. Other providers, such as IBM Instana and Splunk AppDynamics, also offer self-hosted or on-premises deployment, although deployment options and their licensing change frequently enough that you should check the current terms with the vendor before shortlisting on that basis.

Two practical points. Older comparisons are full of defunct brands: SignalFx is now Splunk Observability Cloud, AppDynamics is now Splunk AppDynamics, and Lightstep was bought by ServiceNow. Pricing models also deserve more attention than pricing pages, because per-host charging penalizes lots of small containers, per-gigabyte billing penalizes verbose logging, and the cheaper vendor flips based on your shape.

References

• OpenTelemetry documentation and the component status page
• OpenTelemetry Collector configuration
• Apache SkyWalking downloads and release history
• Jaeger documentation
• SigNoz documentation
• OpenObserve documentation
• Coroot documentation
• Glowroot documentation
• Grafana Tempo documentation
• Prometheus documentation
• Elastic licensing FAQ

Summary

The open source options are genuinely production-grade now, which was not true when this page was first written. For a general-purpose OpenTelemetry-first self-hosted platform, SigNoz is a strong starting point. SkyWalking stands out for Java-heavy service estates, OpenObserve for storage-efficient high-volume telemetry, Coroot for zero-code Kubernetes visibility, and Glowroot for lightweight JVM diagnostics on a single application.

Two decisions are worth separating. Picking a backend is reversible, especially when telemetry travels as OTLP, so it is a smaller commitment than it feels like during evaluation. Picking how your applications are instrumented is the expensive one, which is why OpenTelemetry is the safer default for new distributed systems even though a proprietary agent sometimes sees more.

The last thing to weigh is honest cost. A self-hosted platform is free to license and not free to run, and ClickHouse or Elasticsearch tuning is the bill that arrives later. If nobody on the team wants that job, a commercial platform is genuinely cheaper once you count the hours. If you are unsure, shortlist two platforms that match your stack and compare their instrumentation model, operational footprint, and retention cost before committing.