Most teams pick an observability platform the wrong way: they compare integration counts and dashboard galleries, checking off which tool ships an agent for which service. That comparison feels thorough and predicts almost nothing, because moving off Datadog, Splunk, New Relic, or Dynatrace is not decided by how many integrations a stack lists. It is decided by which signals you actually need, at what cardinality and scale, and whether your team can run the pieces. The acceptance bar for any monitoring change is blunt: you get paged correctly for the incidents you care about. This guide gives you a rubric that keeps that bar in view instead of a longer feature list.
Name the signals and the scale first
Before you shortlist anything, write down what you are really replacing. Which signals you depend on: metrics, logs, and traces are three different systems, and most teams need them in different proportions rather than all equally. Your metric cardinality and volume, because high-cardinality tags and heavy log ingest are exactly what made the incumbent expensive and will size your storage on any target. Your team’s maturity with Kubernetes and OpenTelemetry, since the open stacks assume you can operate them. And your alerting and dashboarding needs: how many monitors page humans, and how much of your dashboard estate genuinely gets used. Those facts decide the answer more than any integration catalog.
What actually decides an observability target
- Breadth of signals needed. A metrics-first estate is a very different project from one that must unify metrics, logs, and traces. Decide how many of the three you truly depend on before you look at products, because it changes the whole shape of the stack.
- Metric cardinality and scale. Cardinality and retention are what drive both the incumbent’s bill and your self-hosted storage. Size the target against your real label churn and volume, and plan recording rules from the start.
- Kubernetes and OpenTelemetry maturity. The open stacks assume comfort with Kubernetes-native deployment and vendor-neutral instrumentation. A team fluent here moves quickly; one that is not will spend its savings learning under load.
- Self-host versus managed. Running the stack yourself trades SaaS polish for operational ownership and usually far lower cost at scale. This is an operating-model decision, and it narrows the field before features do.
- Alerting and dashboarding needs. The monitors that page humans are the real product; dashboards are secondary. Weight your choice by how well the target expresses your alerting model and query language, not by dashboard aesthetics.
Which stack fits which signals
Score your estate against the criteria above, then treat these as starting points rather than conclusions. Metrics-centric estates default to a Prometheus core, extended with Thanos or Mimir for long retention, when the incumbent was mostly infrastructure and application metrics with rule-based alerting. Teams that want the unified metrics-logs-traces experience a suite like Datadog or Dynatrace gave them look at the full Grafana stack, with Mimir, Loki, and Tempo under one Grafana UI, as the closest single-pane replacement, self-hosted or as managed Cloud. Estates whose real job is network and infrastructure polling, the SolarWinds-style workload, map to Zabbix, where you template once and scale with discovery and proxies instead of paying per node and per module. All three shift cost from subscription to your own operations, and where you land depends on which signals dominate and how much your team can run, not on which stack lists the most integrations.
Mistakes that leave you paged wrongly
Several errors recur. The first is porting dashboards first when the monitors that page humans are what matter: rebuild alerting before aesthetics, or you will have pretty panels and miss incidents. The second is underestimating the query-language shift, since one incumbent language usually becomes two or three open ones (PromQL for metrics, LogQL for logs, TraceQL for traces), and alert quality depends on on-call engineers becoming fluent. The third is expecting vendor auto-instrumentation and “AI” root-cause features to have free open equivalents; auto-instrumentation breadth and features like automated RCA are the hardest things to reproduce and often have no direct replacement. A quieter fourth is carrying retention and cardinality forward unchanged, which re-creates the exact cost profile you left the incumbent to escape.
Prove the paging, then switch
Turn your top candidate into a dual-run with written acceptance criteria. Stand up the stack, roll out exporters and agents, and recreate the monitors that page humans first, then rebuild the top dashboards. Fire test alerts end to end, from trigger through Alertmanager to the pager and back to acknowledgement, run a dashboard-parity review, and load-test at your real retention and cardinality. Keep the incumbent running in parallel until paging is proven, and cut over paging integrations last. Model the spend sized on monitored hosts with the calculator, and treat the numbers as illustrative until you have run the stack at your own scale. Choose the target that pages you correctly for the incidents you care about at an operational load your team can sustain, not the one with the richest feature grid.