Written by: Nimesh Chakravarthi, Co-founder & CTO, Struct
Key Takeaways for Choosing an Open Source APM
-
OpenTelemetry has become the universal collection standard, so the real differences between APM stacks now sit in storage design, query cost, and day‑to‑day operations.
-
SigNoz and Grafana LGTM deliver 80–90% of commercial APM functionality for Series A–C teams at a fraction of the licensing cost.
-
Storage and query costs vary sharply: ClickHouse-based SigNoz keeps infra lean, while Elastic and multi-component Grafana stacks demand more engineering time at scale.
-
Teams should choose based on existing infrastructure (ELK, Prometheus, Java), how many components they can realistically run, and whether they need unified traces + metrics + logs or traces alone.
-
Once your APM backend is chosen, Struct automates your on-call runbook by turning every alert into an instant root-cause investigation.
Choosing an Open Source APM Stack for Production Kubernetes
For most Series A–C software engineering teams, SigNoz or the Grafana LGTM stack provides the feature coverage mentioned above at a fraction of commercial APM licensing cost. The right choice depends on three variables: how many components your platform team can operate, whether you already have an Elastic or Java-heavy environment, and whether you need traces alone or unified traces + metrics + logs.
The five stacks evaluated here are SigNoz, Grafana LGTM, Elastic APM, Apache SkyWalking, and Jaeger + Prometheus. Each stack is assessed on storage cost, query cost, component count, and operational overhead for a 20–50 node Kubernetes cluster with 30-day retention.
2026 Storage and Query Cost Snapshot
|
Stack |
Storage model |
Est. monthly infra cost (20–50 nodes, 30-day retention) |
Operational overhead (FTE) |
|---|---|---|---|
|
SigNoz |
Low compute + storage |
0.2–0.4 FTE |
|
|
Grafana LGTM (self-hosted) |
~$800/month for 1TB log retention at 200-microservices scale, lower at 20–50 nodes |
Moderate at larger scales, lower at 20–50 nodes |
|
|
Elastic APM |
High, because shard and node sizing add overhead |
0.3–0.6 FTE |
|
|
Apache SkyWalking |
Elasticsearch or BanyanDB |
Comparable to Elastic APM if ES-backed |
0.2–0.4 FTE |
|
Jaeger + Prometheus |
Costs driven by HA Prometheus replicas plus Jaeger backend |
0.15–0.3 FTE (traces only) |
Grafana LGTM Tempo traces produce variable data volumes based on sampling and retention. Prometheus instances at 500,000 active series typically require 4–9 GB RAM according to modern sizing rules of thumb.
SigNoz for Unified Traces, Metrics, and Logs
SigNoz is an OpenTelemetry-native, full-stack APM built on ClickHouse that unifies distributed tracing, metrics, and log management in a single interface. It feels closest to Datadog’s APM surface area without the per-host pricing model.
-
Storage: ClickHouse columnar backend with efficient compression.
-
Query cost: SQL and PromQL over ClickHouse, which stays fast on large datasets.
-
Component count: SigNoz binary, ClickHouse, and OTel Collector, for a total of three components.
-
Operational overhead: Teams must manage the ClickHouse columnar backend, but a Helm chart exists, so overhead sits around 0.2–0.4 FTE.
-
Limitation: No built-in RUM or synthetic monitoring, and ClickHouse tuning becomes complex at very high ingest rates.
Grafana LGTM for Modular, Prometheus-First Teams
The Grafana LGTM stack, which combines Loki for logs, Grafana for dashboards, Tempo for traces, and Mimir for metrics, is the most modular option and the most widely deployed self-hosted observability architecture in 2026. It covers 80–90% of commercial APM functionality but spreads that coverage across four independently operated components.
-
Storage: Loki and Tempo use S3-compatible object storage, while Prometheus or Mimir use EBS-backed PVCs.
-
Query cost: PromQL for metrics, LogQL for logs, and TraceQL for traces, which means three query languages to support.
-
Component count: Four primary components plus the OTel Collector.
-
Operational overhead: Moderate for initial setup and ongoing work at 20–50 nodes, with complexity rising as scale grows.
-
Limitation: About 39% of practitioners cite complexity and operational overhead as their biggest obstacle, and Loki degrades on high-cardinality label sets beyond 15 label names per series.
-
Best for: Teams already invested in the Prometheus ecosystem who want to add logs with Loki and traces with Tempo step by step.
Elastic APM When ELK Is Already in Place
Elastic APM extends existing Elasticsearch and Kibana deployments. It adds distributed tracing and service maps on top of a current log pipeline without introducing a new storage backend.
-
Storage: Elasticsearch shards on EBS or Persistent Disk, which are resource-intensive in Kubernetes.
-
Query cost: KQL and ES|QL perform well on structured data, but shard management increases operational work.
-
Component count: Elasticsearch, Kibana, APM Server, and OTel Collector, for four components in an OTel-native setup.
-
Operational overhead: Managing clusters, shard counts, and node sizing adds meaningful operational overhead, estimated at 0.3–0.6 FTE.
-
Limitation: Storage costs climb quickly with log volume, and OpenObserve benchmarks claim 140x better storage efficiency than Elasticsearch.
-
Best for: Log-heavy teams with an existing ELK investment who want APM without adding a second storage backend.
Apache SkyWalking for Java-Heavy Environments
Apache SkyWalking is a mature APM platform built for Java and JVM-based microservices, with automatic bytecode instrumentation that requires no SDK changes. It supports OpenTelemetry ingest and can use Elasticsearch or its native BanyanDB storage.
-
Storage: Elasticsearch or BanyanDB for production, with H2 for local development.
-
Query cost: SkyWalking UI and GraphQL API, plus PromQL support through an OTel bridge.
-
Component count: OAP server, UI, and storage backend, for a minimum of three components.
-
Operational overhead: Moderate, because BanyanDB reduces Elasticsearch dependency but remains less battle-tested at scale, with overhead around 0.2–0.4 FTE.
-
Limitation: Best fit for Java-heavy and cost-constrained environments, while polyglot support trails SigNoz and Grafana LGTM.
-
Best for: Java-first engineering teams on tight budgets who want automatic bytecode instrumentation without SDK adoption.
Jaeger + Prometheus for Incremental Tracing
Jaeger + Prometheus does not function as a full-stack APM. Tracing-only tools such as Jaeger do not qualify as APMs on their own, because they require pairing with Prometheus for metrics and a separate log backend for full signal coverage. This combination fits teams that already run Prometheus and want distributed tracing without committing to a new unified backend yet.
-
Query cost: PromQL for metrics and the Jaeger UI for traces, with no unified query layer.
-
Component count: Prometheus, Grafana, Jaeger, and a storage backend, which means four or more components and no native log pillar.
-
Operational overhead: Teams report 15–20 engineer hours per month on Prometheus maintenance alone (~$1,875/month at a $150K salary), which translates to roughly 0.15–0.3 FTE for a traces-only scope.
-
Limitation: Jaeger lacks native metrics and logs support, so you do not get unified correlation across all three pillars without extra tooling.
-
Best for: Teams already running Prometheus who want distributed tracing added incrementally before committing to a unified backend.
Connect Struct to your chosen backend in 10 minutes and let it handle the next investigation automatically.
Reducing Operational Hassle with OpenTelemetry
The most reliable way to cut operational hassle, language-specific agents, and Kubernetes support questions is OpenTelemetry auto-instrumentation deployed via the OTel Collector as a Kubernetes DaemonSet. This approach eliminates language-specific agent management because OpenTelemetry provides auto-instrumentation agents for 12+ languages that capture traces, metrics, and logs without modifying source code. The Collector supports 200+ components to process, filter, and route telemetry at scale, which centralizes configuration that would otherwise live inside individual services.
For Kubernetes-specific overhead, several practical guardrails from production deployments help keep systems stable:
-
Increase the Prometheus scrape interval to reduce TSDB write load.
-
Cap Loki label cardinality at 15 label names per series to prevent query performance degradation.
-
Use Thanos or Mimir for Prometheus retention beyond 30 days, while accounting for Thanos sidecar deployments that can add S3 API costs beyond storage fees.
-
For high-cardinality OOM events, identify problematic series through the TSDB status page and drop labels using relabel_configs.
OTel-native instrumentation reduces lock-in by making backend migration a configuration change rather than a code rewrite, which becomes a concrete advantage as your stack evolves between funding rounds.
Struct as the Investigation Layer on Open Source APM
Every stack above stores and surfaces telemetry, but none of them investigate it for you at 3 AM. That gap, the manual context-switching triage loop across Grafana dashboards, Loki queries, and GitHub blame, is where Struct operates.
Struct is an automated on-call investigation platform that sits on top of your existing APM backend as an investigation layer. It does not replace SigNoz, Grafana, or Elastic APM. When an alert fires in Slack or PagerDuty, Struct immediately queries your connected backends, including Datadog metrics, logs, and traces, plus cross-stack signals from Sentry, GitHub, and cloud logging. It then correlates them into a unified timeline and delivers a root-cause hypothesis with suggested fixes before an engineer opens a laptop.
The numbers from production use show the impact clearly. Arcana reduced median investigation time from 30 minutes to 2 minutes and senior engineer hours on investigation from about 60 to about 4 per month after adding Struct on top of their existing stack. That change represents an 80%+ reduction in triage time, and setup takes under 10 minutes.
Struct also ships Deploy Guard, which provides PR and post-deploy health checks that improve alerting quality before incidents happen, and composable runbook encoding so the AI investigates exactly the way your senior engineers would.
Connect Struct to your APM backend in 10 minutes and let it handle the next investigation automatically.
Frequently Asked Questions
Does Struct replace my open-source APM backend?
Struct does not replace your APM backend. Struct acts as an investigation layer that sits on top of your existing observability stack, whether that is SigNoz, Grafana LGTM, Elastic APM, or a commercial tool like Datadog. It queries your backends when an alert fires, correlates signals across them, and delivers a root-cause report. Your APM backend continues to store and serve telemetry exactly as before, while Struct adds automated first-pass investigation and incident resolution verification that no APM backend provides natively.
How long does Struct take to set up alongside an existing APM stack?
Setup takes under 10 minutes. You authenticate your alert source, such as Slack or PagerDuty, your code repository, such as GitHub, and your observability context, such as Datadog, Grafana, Prometheus, Loki, AWS CloudWatch, GCP Logs, or Azure. Once these systems connect, auto-investigations start immediately. You avoid a lengthy enterprise deployment, an indexing phase, or a professional services engagement.
Which open-source APM stack works best with Struct?
Struct integrates with Grafana, Prometheus, and Loki natively, so it works with the Grafana LGTM stack out of the box. It also connects to Datadog, Sentry, AWS CloudWatch, GCP Logs, Azure Logs and Traces, and Sumo Logic. Struct performs best when your stack already has basic logging, trace IDs, and alerting triggers configured, because the quality of Struct’s investigation output scales with the quality of your telemetry. Teams running SigNoz or Grafana LGTM with OpenTelemetry auto-instrumentation are well-positioned to get accurate root-cause output immediately.
Is Struct appropriate for a team that is still evaluating APM backends?
Struct fits teams that are still evaluating APM backends. Struct’s composable architecture allows you to add it at any point in your observability journey. If you currently run Jaeger + Prometheus and plan to migrate to SigNoz or Grafana LGTM, Struct connects to your current backends today and reconnects to new ones as you migrate, without requiring a re-investigation of your runbooks. The 10-minute setup and 30-day risk-free pilot keep evaluation risk low while you select an APM backend. Struct is SOC 2 Type II and HIPAA compliant, which satisfies the compliance requirements of most Series A–C fintech and B2B SaaS companies.
Conclusion: Pick a Backend, Then Add an Investigation Layer
In 2026, the open-source APM tools comparison reduces to a clear decision tree: SigNoz for unified traces, metrics, and logs on a single ClickHouse backend, Grafana LGTM for maximum modularity and S3-backed scale, Elastic APM when ELK already exists, SkyWalking for Java-heavy environments, and Jaeger + Prometheus when you need traces added incrementally to an existing metrics stack.
Each of these stacks solves the storage and query problem. None of them solve the 3 AM triage problem, the manual context-switching investigation loop that costs senior engineers 30–45 minutes per incident and makes on-call rotation hard to delegate to newer engineers without deep tribal knowledge.
Struct acts as the investigation layer that closes that loop. It performs automated first-pass investigation and incident resolution verification on top of whichever backend you choose, reducing triage time by about 80% without replacing your existing observability infrastructure. The Arcana results mentioned earlier, with 2,100+ automated investigations per month and 56 engineer-hours reclaimed, show the practical impact of adding this investigation layer.
For further reading, see the related guides on automated root-cause analysis with Struct vs Datadog and incident tracking and resolution verification with Struct vs Sentry Seer.
See Struct investigate a real alert against your APM backend and automate your on-call runbook in under 10 minutes.
