For most new services in 2026, I'd start with OpenTelemetry (OTel) as the instrumentation standard and then choose a backend based on your team's needs. That keeps you from getting locked into a vendor while still giving you flexibility.
Here's how I'd think about it:
| Goal | Recommendation |
|---|
| Lowest lock-in | OpenTelemetry + Grafana ecosystem |
| Fastest time to value | Opinionated SaaS (Honeycomb, Datadog, New Relic) with OTel |
| Kubernetes-heavy | OpenTelemetry + Grafana + Prometheus + Loki |
| Small team, few services | Grafana Cloud or an opinionated SaaS |
| Large organization | OTel Collector with centralized pipelines |
My default open-source stack
- Instrumentation: OpenTelemetry SDKs
- Collector: OpenTelemetry Collector
- Metrics: Prometheus (or OTLP metrics if your backend supports them well)
- Traces: Tempo
- Logs: Loki
- Visualization: Grafana
This gives you:
- One instrumentation API
- One collector layer for sampling, filtering, and routing
- Excellent correlation between logs, metrics, and traces
- Minimal vendor lock-in
The Collector is arguably the most important component because it lets you change backends later without touching application code.
If I wanted the least operational overhead
I'd seriously consider:
- OpenTelemetry
- OpenTelemetry Collector
- Grafana Cloud
or
These eliminate almost all of the operational burden of running Prometheus, Tempo, and Loki yourself.
If I wanted the best developer experience
I'd lean toward Honeycomb.
Their event-based model makes investigating distributed traces extremely fast, especially for high-cardinality data like:
- tenant_id
- customer_id
- feature_flag
- endpoint
- deployment version
You can ask questions that are difficult to express in traditional metrics systems.
If I wanted to self-host
A typical architecture looks like:
Application
│
OpenTelemetry SDK
│
OTLP
│
OpenTelemetry Collector
│
┌───────────────┬──────────────┬──────────────┐
│ │ │
Tempo Prometheus Loki
│ │ │
└───────────────┴──────────────┘
Grafana
The Collector can also:
- batch exports
- retry on failures
- perform tail sampling
- redact sensitive fields
- enrich telemetry with Kubernetes metadata
This keeps application code clean.
Things I'd instrument immediately
Don't try to instrument everything.
Start with:
- HTTP requests
- database queries
- cache calls
- message queues
- external APIs
- background jobs
Then add business spans like:
checkout.process_payment
invoice.generate
search.execute
Those become much more valuable than purely technical spans.
Metrics I'd keep
Golden Signals still work well:
- request rate
- latency
- errors
- saturation
Plus service-specific metrics like:
- queue depth
- cache hit rate
- active users
- job duration
Avoid creating high-cardinality metrics with dimensions like user IDs. High-cardinality attributes are generally better suited to traces.
Sampling
A mistake I still see is head sampling everything at 1%.
Instead:
- Keep all error traces.
- Keep high-latency traces.
- Sample healthy requests.
- Use tail sampling in the Collector when feasible.
That preserves the traces you most often need during incidents while controlling storage costs.
What I'd choose in 2026
For a greenfield project:
- OpenTelemetry SDKs
- OpenTelemetry Collector
- OTLP everywhere
- Grafana Cloud if I don't want to operate infrastructure
- Self-hosted Grafana + Tempo + Loki + Prometheus if infrastructure control matters
I wouldn't start with proprietary instrumentation libraries anymore unless there's a compelling feature you specifically need. OpenTelemetry has become the de facto standard, and most major observability platforms support it well, making it much easier to switch backends without rewriting your instrumentation.
