Native Prometheus Instrumentation vs OpenTelemetry for Metrics
Few debates in modern observability are as emotionally loaded as Prometheus instrumentation versus OpenTelemetry. A recent blog post titled "Why I recommend native Prometheus instrumentation over OpenTelemetry" lit up the Prometheus crowd for exactly that reason. The post made a specific, opinionated recommendation without attacking OpenTelemetry outright, at a time when much of the industry wants one standard to rule them all.
Almost immediately, someone pointed out the nuance that was missing:
This should probably say “for metrics.”
That small clarification explains most of the tension underneath the debate.
The title was the spark
The first major pushback was about scope, and technical correctness barely came up. One commenter suggested the post should be titled:
Why I recommend native Prometheus instrumentation over OpenTelemetry for metrics
Modern instrumentation covers metrics, traces, logs, profiles and events, and OpenTelemetry exists specifically to unify them. The author replied that yes, but the title was already long, and in a Prometheus context it should be obvious that the discussion is about metrics.
That exchange frames the argument correctly. The post compares the two projects for metrics instrumentation specifically and doesn't weigh OpenTelemetry as a whole.
Prometheus was built for metrics
Prometheus does one thing, metrics, and that constraint is a feature. Native Prometheus client libraries are designed around counters, gauges, histograms, summaries and pull-based exposition, so they match the storage model, the query language and the scraping philosophy. When you instrument natively there is no translation layer, no semantic conversion, no bridge and no exporter in between. The path is direct, and direct usually means simpler.
The OpenTelemetry promise
OpenTelemetry promises something broader: one vendor-neutral SDK that handles metrics, traces and logs. For distributed systems with multi-tier architectures, that is compelling. As one commenter pointed out, once you have multi-tiered applications you'll want traces and logs to cut down root cause analysis time.
That's fair. Metrics tell you something is wrong, and traces help you understand why. Nobody in the thread doubted that traces are valuable. The open question is whether OpenTelemetry metrics are the best path when Prometheus is your backend.
Where the friction really lives
The friction usually shows up in architecture. One commenter runs many disparate public internet projects and prefers push-based statistics gathering, because it avoids opening firewall rules for a central collector. That is a very real constraint. Prometheus is pull-based, OpenTelemetry often runs in push pipelines, and if your topology favors push, OpenTelemetry collectors can feel like the easier path.
The price is more components: collectors, pipelines, processors and possibly Alloy or other agents. Another commenter described Alloy as essentially Prometheus plus exporters plus data sinks in one package and worried about it becoming bloatware. There was also a jab at HCL configuration being "insane" compared to structured config files.
Those complaints point at a real concern. Universal agents add complexity, and complexity rarely stays small.
Native instrumentation is boring, and that's the point
Native Prometheus instrumentation is language-specific, stable, direct and focused only on metrics. It doesn't try to solve tracing, export logs or build cross-signal pipelines. It exposes /metrics, Prometheus scrapes it, and you are done.
When you run a metrics-first stack with Prometheus as the source of truth, that simplicity is powerful. You avoid semantic mismatches, feature gaps, translation edge cases and surprises in aggregation behavior, and above all you have fewer moving parts.
The hidden risk of "universal" instrumentation
Universal instrumentation frameworks age differently from single-purpose ones. They grow, adding layers, configuration knobs and compatibility modes, until they start solving problems you don't actually have. That is where the bloatware comment hits. OpenTelemetry isn't inherently bloated, yet universal agents tend to accumulate responsibilities, and when you only need metrics, the native Prometheus libraries feel leaner.
Metrics aren't the whole story
The counterargument is obvious. In complex systems metrics alone aren't enough: traces reduce RCA time, logs provide context, and correlating signals is powerful. If you already deploy OpenTelemetry for tracing, separate instrumentation for metrics can feel redundant.
That is the architectural fork. You can optimize each signal for its native ecosystem or unify all of them under one instrumentation framework, and neither choice is right for everyone.
The audience matters
The author clarified that the post was written for a Prometheus audience, and that context matters. If your backend is Prometheus, your queries are PromQL and your alerting relies on Prometheus-native semantics, native instrumentation fits by default. You aren't fighting translation layers or depending on bridge components to behave perfectly, because you are using the system as it was designed.
Architecture is constraint-driven
Look at the push versus pull comment again. If firewall rules make pull-based scraping impractical, your architecture will push you toward collectors. If you are spread widely across public networks, you might accept extra overhead for centralized ingestion. Constraints drive design, and instrumentation strategy should follow your constraints instead of an ideology.
The takeaway
The debate is about fit more than about which project is better. Native Prometheus instrumentation fits Prometheus, OpenTelemetry fits multi-signal observability strategies, and friction appears where those goals overlap.
The post started a discussion because it was opinionated, and opinionated guidance is rare in observability. Most content hedges and most tools promise everything, so it can be refreshing to hear "If you're using Prometheus for metrics, just instrument for Prometheus." That advice leaves room for traces and logs and doesn't attack OpenTelemetry. It argues for cutting unnecessary abstraction layers once your stack is decided, and in infrastructure fewer layers usually means fewer surprises, which at 3AM is often what matters most.