2026-09-01

Better Together: Eliatra on Why OpenTelemetry and OpenSearch Are a Natural Fit

An introduction to why OpenTelemetry and OpenSearch are a natural technical pairing for observability, and how Eliatra helps organisations turn that compatibility into a production-ready, vendor-neutral stack.

Reading time: 4 minutes

By Alannah Melly

Most observability stacks are built the same way, almost by accident: an agent chosen because it was the default for one cloud provider, a metrics backend chosen because someone evaluated it in 2019, a logging tool bolted on later because the first two didn’t cover traces. It’s a pattern Eliatra sees constantly in OpenSearch deployments: a few years in, the organisation is paying for three separate proprietary tools that don’t share a schema, don’t share a query language, and lock the data — and the pricing — into whichever vendor built them.

OpenTelemetry and OpenSearch are, individually, the industry’s answer to that problem. Put together, they solve it twice over — which is exactly why Eliatra, the OpenSearch specialist behind this series, treats the pairing as one of the most common and most valuable combinations a team can standardise on. This is the first of three articles: this one makes the case for why OTel and OpenSearch belong together technically; Part 2 covers how Eliatra actually implements that pairing in production; and Part 3 covers the business case and what it takes to keep the whole thing supported for the long haul.

What OpenTelemetry Actually Standardizes

OpenTelemetry (OTel) is a CNCF project that defines a single, vendor-neutral way to generate, collect, and export telemetry data — traces, metrics, and logs — from applications and infrastructure. Its entire reason for existing is to stop teams from having to instrument their code differently for every backend they might send data to. Instrument once, with OTel’s SDKs and the OpenTelemetry Collector, and the data can flow to whichever backend the organisation chooses, without re-instrumenting anything if that choice changes later.

That last part matters more than it sounds. The single biggest hidden cost of most commercial observability platforms isn’t the licence fee — it’s the switching cost, because the instrumentation is often tied to the vendor’s proprietary agent. OTel removes that lock-in at the source.

Why OpenSearch Is a Natural Backend for OTel Data

OpenSearch didn’t add OpenTelemetry support as an afterthought — its observability capabilities were built with OTel’s data model in mind, which is why the fit is closer than most backend integrations. A few highlights:

Data Prepper ingests OTel data directly. OpenSearch’s server-side data collection component has purpose-built processors for OpenTelemetry traces and metrics, so data arriving from an OpenTelemetry Collector can be transformed and written into OpenSearch without a custom integration layer.
Trace Analytics is OTel-native. The Observability plugin’s Trace Analytics feature consumes OTel-formatted trace data directly, enriching spans and building service maps so teams can see request flows and latency across a distributed system in one place.
The Simple Schema for Observability (SS4O) closes the format gap. Modelled on OpenTelemetry’s semantic conventions, SS4O gives OpenSearch a unified schema so logs, metrics, and traces can be correlated in the same tool without custom mapping work.
Both are genuinely open. OpenSearch and OpenTelemetry are open-source projects with permissive governance, not open-core products with a proprietary ceiling — adopting both means opting out of the vendor lock-in that defines most of the commercial observability market.

Each of those points — Data Prepper pipeline design, Trace Analytics configuration, SS4O alignment — sounds straightforward in a bullet list. Getting them right in a production cluster, at real data volumes, is a different exercise, and it’s the subject of Part 2.

The Short Version of the Business Case

Consolidating traces, metrics, and logs onto one open backend means one system to operate instead of three, no licence cost that scales against the thing observability is supposed to encourage (instrumenting everything), and no re-instrumentation tax if priorities change later, because OTel decouples instrumentation from the backend. Part 3 goes into this in full, including what it takes to keep that backend supported over years rather than just at launch.

Where Eliatra Fits

The technical fit between OpenTelemetry and OpenSearch is real. Turning that fit into something a production team can depend on — correctly designed Data Prepper pipelines, a schema that actually enables correlation, and a security posture applied consistently to observability data — is where Eliatra comes in. Eliatra’s focus is exclusively OpenSearch: Data Prepper pipeline design, the Observability plugin, and OpenSearch’s security layer, backed by a team with direct upstream involvement in the OpenSearch project and grounded in IT security specifically.

Part 2 gets into exactly how that implementation work happens. Part 3 covers why it needs to be supported for the long term, and how Eliatra does that as a founding accredited provider under the OpenSearch Software Foundation’s LTS program.

Next: Part 2 — From Compatible to Production-Ready: How Eliatra Implements OpenTelemetry on OpenSearch.