# Don't Wrap OpenTelemetry -- You're Probably Hurting More Than Helping

DevFeed: [Don't Wrap OpenTelemetry -- You're Probably Hurting More Than Helping](<https://devfeed.tech/articles/don-t-wrap-opentelemetry-you-re-probably-hurting-more-than-helping-32570.md>)

Original publisher: [Read original article](<https://opentelemetry.io/blog/2026/dont-wrap-opentelemetry/>)

Author: OpenTelemetry Authors; Docs CC BY

Published: 2026-06-24T08:42:08Z

Content type: opinion

Language: en

Sources: [Blog on OpenTelemetry](<https://devfeed.tech/sources/blog-on-opentelemetry.md>)

Topics: [OpenTelemetry](<https://devfeed.tech/topics/opentelemetry.md>), [Instrumentation](<https://devfeed.tech/topics/instrumentation.md>), [telemetry](<https://devfeed.tech/topics/telemetry.md>), [SDKs](<https://devfeed.tech/topics/sdks.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [cache](<https://devfeed.tech/tags/cache.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [instrumentation](<https://devfeed.tech/tags/instrumentation.md>), [opentelemetry](<https://devfeed.tech/tags/opentelemetry.md>), [traces](<https://devfeed.tech/tags/traces.md>)

## AI overview

This opinion article argues that thin abstractions wrapping the OpenTelemetry API can harm application instrumentation by hiding allocation-free SDK designs and adding repeated lookup, hashing, comparison, or locking costs. It distinguishes API wrappers from shared helpers for SDK configuration.

## Source excerpt

There's a pattern I've seen across many teams adopting OpenTelemetry, and it's well-intentioned every single time. An engineer wants to make things easier for the team. They build a thin abstraction over the OTel API -- an IMetric interface, a TelemetryHelper class, a MetricsWrapper module -- and ship it as the team's standard. "Just use this," they say. "It's simpler." The intention is genuine. The outcome is usually not good.