Updated: 2026-07-12

Observability has changed enough in the last three years to warrant updating recommendations. With OpenTelemetry stable and adopted practically everywhere, with the Grafana stack mature across all layers, and with several SaaS products consolidated or gone, the map is clearer. Time to update concrete recommendations for teams starting observability or revising what they set up years ago.

Key takeaways

  • OpenTelemetry is the single instrumentation standard in 2026: mature SDKs, OTLP accepted by all collectors, real portability across providers.

  • Prometheus keeps its dominant position for metrics; VictoriaMetrics or Grafana Mimir for workloads that exceed it.

  • Loki has won the log segment for workloads not needing Elasticsearch-style full-text search.

  • Grafana Tempo is the default recommendation for distributed traces if already on the Grafana stack.

  • Grafana Alloy replaces Promtail and Grafana Agent as the unified collection agent.

  • The decision between self-hosting and Grafana Cloud is made with cost arithmetic, not ideology.

The non-negotiable base: OpenTelemetry

In 2026, if you’re instrumenting a new application, use OpenTelemetry. No caveats, no alternatives. Three years of stabilization have turned the project into the single standard for emitting metrics, traces, and logs, with mature SDKs in every relevant language, the OTLP protocol accepted by every commercial and open collector, and a community large enough to guarantee maintenance for the next decade.

OpenTelemetry’s strategic advantage is portability. Instrument once with the project’s SDKs and you can send data to Datadog, New Relic, Honeycomb, Dynatrace, Grafana Cloud, or your self-hosted stack by changing only the collector configuration. This removes the vendor lock-in that was for years the biggest hidden cost of commercial platforms.

# Minimal instrumentation with OpenTelemetry in Python
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://alloy:4317"))
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("my-service")

with tracer.start_as_current_span("process-order") as span:
    span.set_attribute("order.id", order_id)
    result = process(order_id)

The learning curve is notable, especially for teams coming from direct instrumentation with Prometheus client libraries or proprietary agents. But this upfront investment pays off in under a year for any team running more than a handful of applications.

Metrics: Prometheus is still the answer

For metrics, Prometheus keeps its dominant position. Its PromQL query language remains the standard every alternative tries to emulate. Its pull-scrape model with service discovery aligns naturally with Kubernetes. The exporter ecosystem for any database, message queue, proxy, or platform is still richer than any alternative’s.

Alternatives worth knowing:

  • VictoriaMetrics for large workloads where Prometheus starts to struggle. It speaks PromQL, ingests Prometheus metrics unchanged, and its write throughput and compression are better.

  • Grafana Mimir for large-scale multi-tenant deployments. If you’re already in the Grafana ecosystem and need real multi-tenancy, Mimir is the natural choice. Covered in detail in the Grafana Mimir post.

For a small or medium team, self-hosted Prometheus is still enough up to tens of millions of active series. The move to VictoriaMetrics or Mimir should happen when real performance problems show up, not before.

Prometheus’s natural companion remains Alertmanager: in 2026 it hasn’t changed much and is still adequate for severity-routed alerts, with mature integrations for Slack, PagerDuty, Telegram, email, and any custom webhook.

Logs: Loki has won, with caveats

In 2026 the caution around Loki has faded: Loki has clearly won the log segment for small and medium workloads that don’t need Elasticsearch-style full-text search. Its model of indexing only labels and storing the text as compressed blocks in object storage makes it orders of magnitude cheaper than full inverted-index solutions.

Loki fits especially well with deployments where object storage is cheap: S3, GCS, Hetzner Object Storage, MinIO. With recent releases and the new TSDB backend, LogQL query performance has improved noticeably.

Where Loki still falls short: full-text search with relevance ranking, linguistic analysis, huge log volumes with complex free-text queries. For these cases, Elasticsearch or OpenSearch remain the right tool, with the operational cost that comes with them. But the share of teams that genuinely need full-text search is smaller than it looks.

Traces: Tempo or Jaeger, by context

For distributed traces, the two serious open options are Grafana Tempo and Jaeger. Tempo is my default recommendation if you already run the Grafana stack, because the integration with Loki and Prometheus for trace-log-metric correlation is native and frictionless. Its object-storage model makes it cheap to operate.

For small teams starting out with observability: don’t introduce distributed tracing until metrics and logs are working maturely. The marginal value of traces grows with architectural complexity. If the system is three well-monitored services on Prometheus, traces are not the priority.

Dashboards and visualization: Grafana, no debate

Grafana in 2026 is the de facto visible face of the open stack. Its unified query engine combining metrics, logs, and traces in a single panel, its plugins for connecting to any data source, and its unified alerting model make it hard to beat.

Grafana Cloud deserves a separate mention. For small teams that don’t want to operate the stack, the free tier and initial plans are competitive: Prometheus, Loki, Tempo, and Grafana with no ops overhead. For larger teams, self-hosting remains significantly cheaper and gives more control.

Collection and routing: Alloy has replaced Promtail

Grafana Alloy, the unified agent that replaces Promtail, Grafana Agent, and several components that used to exist as separate pieces, is the default choice for collection in Grafana environments. It combines Prometheus metric scraping, log shipping to Loki, OTLP reception and forwarding, all with unified configuration.

Fluent Bit remains a solid reference for non-Grafana environments or where highly sophisticated log routing to multiple destinations is needed. For teams that already have it deployed, there is no urgency to migrate to Alloy.

Availability: Uptime Kuma for the simple case

For synthetic checks and outside-in availability monitoring, Uptime Kuma remains the pragmatic choice for small and medium teams. It has 88,800 stars on GitHub[1], a simple interface, reasonable notifications, and self-hosted operation in a single container. For teams running LLM systems, availability alerts for inference endpoints integrate naturally alongside those for any other API.

The base recommendation

For a team starting or rebuilding observability: OpenTelemetry for instrumentation, Prometheus for metrics, Loki for logs, Tempo for traces if needed, Grafana for visualization, Alloy for collection, Alertmanager for alerting, Uptime Kuma for outside-in availability. This combination covers 90% of cases with open tools, reasonable operational cost, and near-total portability.

The classic mistake is over-engineering from the start: building the full stack with distributed tracing, multiple Prometheus clusters, and sophisticated alerting when the product doesn’t have users yet. Observability should grow with load. This stack integrates well with LLM cost monitoring in production and with AI agent telemetry when the system incorporates language models.

This article is also available in Spanish.

Sources

  1. 88,800 stars on GitHub
  2. OpenTelemetry official documentation
  3. Prometheus overview
  4. Grafana Loki documentation