The OTel Vendor Compatibility Matrix

Not all vendors are OTel-native. The compatibility matrix, the gotchas, and what to test before committing.

Native vendors

OpenTelemetry vendor compatibility is not uniform. Some vendors accept OTel natively; others translate it into their proprietary formats. The translation layer can lose metadata or reinterpret semantics. Understanding which vendor falls into which category guides the team's vendor choice.

What native vendors provide:

• Honeycomb, Lightstep, Grafana Cloud accept OTel directly.: These vendors built around OTel from the start (or migrated to it as the standard). The OTel format is the native format; no translation is needed.
• No translation layer.: The vendor receives the OTel format and stores it natively. The semantic conventions are preserved; the metadata flows through unchanged.
• No quirks.: The vendor's UI shows what was sent. Attribute names match; the relationships match; the visualization is faithful to the data.
• Best for OTel-first stacks.: Teams that have committed to OTel benefit from native vendors. The investment in OTel pays off; the vendor relationship is straightforward.
• Future-proofed.: As OTel evolves, native vendors evolve with it. The team's instrumentation continues working; the vendor adopts new OTel features as they stabilize.

Native vendors are the cleanest path. The team's OTel work translates directly to vendor capabilities.

Translation vendors

Translation vendors accept OTel but translate it into their proprietary formats. The translation can lose metadata or reinterpret semantics; the team must understand the translation to predict behavior.

• Datadog, New Relic, Splunk accept OTel via a translation layer.: These vendors built around proprietary formats first; OTel support came later. The translation layer maps OTel to the proprietary format; some impedance is unavoidable.
• Some metadata is lost.: The translation might drop attributes the proprietary format does not support. The team's instrumentation might emit data that does not appear in the vendor's UI.
• Some semantic conventions are reinterpreted.: The vendor might rename attributes or restructure relationships. http.status_code might become statusCode in the vendor's UI; the team's queries use vendor-specific names.
• Test the translation.: The team should test what actually shows up in the vendor's UI. The behavior may not match the team's expectations; the test catches the discrepancy before it matters.
• The vendor's UI may not match what you sent.: What goes in via OTel and what shows up in the UI can differ. The translation is the source of the difference; understanding it produces accurate expectations.

Translation vendors work but require attention. The team must understand the translation to predict behavior.

What to test

Compatibility testing is the discipline. Before committing to a vendor, the team verifies the OTel telemetry behaves as expected. The testing catches surprises before they become operational issues.

• Send sample telemetry; verify it shows up correctly.: The team sends a known set of telemetry through OTel to the vendor. They verify each piece appears correctly in the UI; differences indicate translation issues.
• Test traces specifically.: Traces are where translation breaks most often. Span relationships, parent-child links, attribute mapping all can break. The trace tests are the most informative.
• This is where translations break most often.: Trace data structure is more complex than logs or metrics. The translation has more to translate; the chances of issues are higher. Trace testing prioritizes correctly.
• Test high-cardinality metrics.: Metrics with high cardinality stress the vendor's ingestion. The cost model often charges per-series; high cardinality can produce surprise bills.
• Cost models differ.: Different vendors charge differently for the same telemetry. The team's volume and cardinality determine the cost; testing reveals the actual cost before commitment.
• Surprises hide in the per-series billing.: The headline pricing is one thing; the per-series billing is another. High-cardinality metrics expose hidden costs; testing surfaces them.

OTel vendor compatibility matrix is one of those evaluations that pays off proportionally to the investment in OTel. Nova AI Ops integrates with telemetry across vendors, surfaces translation issues and cost patterns, and helps teams choose vendors that work with their OTel investment.