New
Datadog vs Grafana stack vs OpenTelemetry + open source
If you have run more than one, compare them on cost at your scale, time to value and on-call experience.
Evaluation guide
How to evaluate observability platforms
This guide is for SRE, platform and operations leaders replacing a monitoring stack, consolidating several tools or bringing telemetry costs under control. It assumes you already collect logs, metrics and traces somewhere and need to choose what to keep, where to send it and what to pay for.
In short
Use this guide to compare observability platforms on what decides the outcome: open collection and data portability, cost as telemetry grows, query speed during an incident, correlation across logs, metrics and traces, AI help on your own incidents and control of sensitive data. Then shortlist three to five companies on Techarda and replay a recent incident on each.
What’s changing in Observability
Before you compare anyone, it helps to know what has shifted in the market, because it changes which questions matter.
OpenTelemetry is the default way to collect
Most vendors now accept OpenTelemetry data, and many teams instrument with it to avoid proprietary agents. That makes changing backends more practical, though dashboards, alert rules and vendor extensions still tie you in.
Telemetry cost is now a budget conversation
Every new service adds logs, metrics and traces, and budgets do not grow with them. Teams now filter, sample and route data before it reaches a paid backend, and telemetry pipeline tools have become a category of their own.
AI is entering incident response
Vendors offer assistants that summarise incidents, suggest causes and write queries. Results depend on the quality of your data and service maps, so test them on incidents you have already solved.
Operations and security data overlap
The same logs feed operations and security teams. Some platforms now serve both, which can cut duplicate storage and complicates access control and retention.
What to judge vendors on
Those shifts shape the criteria below. Each one says why it matters and what to ask, so you can take it straight into a vendor call.
| Criterion | Why it matters | What to ask vendors |
|---|---|---|
| 1Open collection and data portability | Instrumentation is expensive to redo. Collecting through an open standard keeps the option of changing backends later. | “Do you accept OpenTelemetry data with no loss of features, which features need your own agent, and can we export raw data, dashboards and alert rules?” |
| 2Cost as data grows | Pricing by host, by gigabyte ingested, by event or by user behaves differently as you scale. Surprises usually come from logs and high-cardinality metrics. | “At our current volumes, what would we pay this year and at twice the volume, and which controls let us cut ingest without losing what we need?” |
| 3Query speed during an incident | When something is down, a query that takes minutes costs money and patience. Speed over long time ranges matters most exactly when it is hardest to deliver. | “How fast do typical queries return at our data volumes over the last day and the last month, and is older data slower or charged again to query?” |
| 4Correlation across signals | Jumping between separate tools for logs, metrics and traces slows every investigation down. | “How do you link a slow trace to the related logs, metrics and deployment, and does that work for services instrumented with OpenTelemetry?” |
| 5Alert quality | Noisy alerts train people to ignore them. The platform should help you alert on the symptoms users feel. | “How do you support service level objectives and alerting on them, and what helps us find and remove noisy alerts?” |
| 6Investigation help from AI | An assistant that restates the dashboard adds nothing. One that narrows down the cause on your own data saves real time. | “Can we replay two of our past incidents through your assistant during the trial, and what data does it send to which models?” |
| 7Sensitive data and access control | Logs often contain personal data, tokens and customer identifiers, and everyone with query access can see them. | “How do you detect and mask sensitive data at ingest, control access by team or data type, and set retention for each data set?” |
| 8Retention and archiving | Audit, security and regulatory needs can require keeping data far longer than operations needs it, which changes the cost. | “What retention options do you offer, can we archive to our own storage and bring data back later, and what does bringing it back cost?” |
Trade-offs to settle early
No vendor does well on every criterion, and some pull against each other. Decide where you stand on these before the demos start, or the demos will decide for you.
One platform or a tool per signal
One platform gives correlation and one bill. Separate tools for logs, metrics and traces can be cheaper or deeper, and make investigations slower unless you join them well.
Keep everything or filter at the source
Sending all telemetry keeps every option open and costs the most. Filtering and sampling cut cost, and now and then the data you dropped is the data you needed.
Managed service or self-hosted open source
Open-source backends avoid licence costs and keep data with you. Running them at scale takes skilled people and careful storage planning.
Vendor agents or OpenTelemetry
Vendor agents can be easier to deploy and offer extra features. OpenTelemetry keeps you portable and may trail a vendor agent for some languages or features.
Shared with security or kept separate
One store for operations and security data cuts duplication. It also widens who can see what, and the two teams often want different retention.
Red flags
As the answers come back, watch for these. One on its own isn’t a deal breaker, but it deserves a follow-up question in writing.
- Cost estimates based on today’s volumes with no model for growth.
- OpenTelemetry support that loses features or costs more than the vendor’s own agent.
- No reference customer at your telemetry volume who has been through a renewal.
- AI assistant demos run only on the vendor’s sample application.
- Older data moved to a tier that is slow, or charged again, to query.
- Sensitive data masking available only after ingest, or only on a higher tier.
Build your shortlist
Start with what you need to see and what you can afford to keep, then use Techarda to narrow the field to three to five companies.
- Record your current telemetry volumes, retention needs and the tools each team uses today.
- Decide whether OpenTelemetry collection is a requirement. It decides how easily you can change backends later.
- Compare like with like: full platforms against each other, telemetry pipelines against each other, incident tools against each other.
- Read recent stories on Techarda for pricing changes and acquisitions, which can change terms at renewal.
- Replay a recent incident on each finalist, then check the practitioner questions below and compare side by side.
Companies to consider in Observability
Listed by recent activity on Techarda (what people are reading, following and discussing). The order says nothing about quality, market share or fit for your needs.
Latest Observability stories
Once you have names, recent news is where pricing changes, acquisitions and outages show up first. These are the five newest stories in this category.
What practitioners are asking
News tells you what vendors announced. These open questions show what teams are still trying to work out, with the least-answered first.
New
How are you controlling observability costs without losing visibility?
Sampling, tiered retention, OpenTelemetry pipelines, switching vendors? What cut the bill the most?
New
How are you approaching AI governance and model risk management?
Inventories, risk tiers, approval workflows, monitoring. What framework did you adopt and what does day-to-day governance look like?
New
What is your approach to managing thousands of edge devices?
Fleet management, updates, security patching and observability at the edge: what tools and practices have held up?
Where evidence is thin
A shortlist is only as good as the evidence behind it, and ours is still growing category by category. Here is what’s missing in Observability right now.
20 of 20 companies have no published reviews
If you’ve run one of these in production, a short review helps the next team decide. Reviews are moderated before they appear.
4 questions with no answers yet
An answer from someone who has made the same decision is often more useful than any guide. Share what worked, what didn’t and what you’d check next time.
Answer a Observability questionFrequently asked questions
What should I ask Observability vendors about open collection and data portability?
Instrumentation is expensive to redo. Collecting through an open standard keeps the option of changing backends later. Ask: Do you accept OpenTelemetry data with no loss of features, which features need your own agent, and can we export raw data, dashboards and alert rules?
What should I ask Observability vendors about cost as data grows?
Pricing by host, by gigabyte ingested, by event or by user behaves differently as you scale. Surprises usually come from logs and high-cardinality metrics. Ask: At our current volumes, what would we pay this year and at twice the volume, and which controls let us cut ingest without losing what we need?
What should I ask Observability vendors about query speed during an incident?
When something is down, a query that takes minutes costs money and patience. Speed over long time ranges matters most exactly when it is hardest to deliver. Ask: How fast do typical queries return at our data volumes over the last day and the last month, and is older data slower or charged again to query?
What should I ask Observability vendors about investigation help from AI?
An assistant that restates the dashboard adds nothing. One that narrows down the cause on your own data saves real time. Ask: Can we replay two of our past incidents through your assistant during the trial, and what data does it send to which models?
New to some of the terms in this guide? The glossary explains AIOps, Distributed tracing, Observability, OpenTelemetry and Service level objective (SLO).
This guide is written by Techarda editors to our editorial standards. No vendor paid to appear in it or saw it before publication. See our methodology, the trust dashboard or go back to the Observability hub.