Why I Recommend Native Prometheus Instrumentation Over OpenTelemetry - And Why That Title Sparked a Fight

There are few debates in modern observability as emotionally loaded as this one: Prometheus instrumentation… or OpenTelemetry? A recent blog post titled *“Why I recommend native Prometheus instrumentation over OpenTelemetry”* lit up the Prometheus crowd for exactly that reason . Not because it attacked OpenTelemetry outright. But because it made a specific, opinionated recommendation in a world increasingly obsessed with “one standard to rule them all.” And almost immediately, someone pointed out the nuance that was missing: > This should probably say “for metrics.” That small clarification reveals the entire tension underneath the debate. --- ## The Title Was the Spark The first major pushback wasn’t about technical correctness. It was about scope. One commenter suggested the post should be titled: > Why I recommend native Prometheus instrumentation over OpenTelemetry **for metrics** Because modern instrumentation isn’t just about metrics anymore. We have: - Metrics - Traces - Logs - Profiles - Events And OpenTelemetry exists specifically to unify those. The author responded simply: yes, but the title was already long, and in a Prometheus context, it should be obvious this discussion is about metrics . That exchange matters. Because it frames the argument correctly. This isn’t Prometheus vs OpenTelemetry in totality. It’s about metrics instrumentation specifically. --- ## Prometheus Was Built for Metrics — Period Prometheus does one thing. Metrics. That constraint is a feature. Native Prometheus client libraries are designed around: - Counters - Gauges - Histograms - Summaries - Pull-based exposition They match the storage model. They match the query language. They match the scraping philosophy. When you instrument natively, there’s no translation layer. No semantic conversion. No “bridge.” No exporter in between. It’s direct. And direct usually means simpler. --- ## The OpenTelemetry Promise OpenTelemetry, on the other hand, promises something broader: A unified instrumentation framework for metrics, traces, and logs. One SDK. Multiple signal types. Vendor-neutral. For distributed systems with multi-tier architectures, that’s 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 not wrong. Metrics tell you something is wrong. Traces help you understand why. The question isn’t whether traces are valuable. The question is whether OpenTelemetry metrics are the best path if Prometheus is your backend. --- ## Where the Friction Really Lives The friction often shows up in architecture. One commenter described running many disparate public internet projects and preferring push-based statistics gathering because it avoids opening firewall rules for a central collector . That’s a very real constraint. Prometheus is pull-based. OpenTelemetry often operates in push pipelines. If your topology favors push, OpenTelemetry collectors can feel like the easier path. But now you’re introducing: - Collectors - Pipelines - Processors - Potentially Alloy or other agents Another commenter described Alloy as essentially Prometheus plus exporters plus data sinks in one — and worried about it becoming bloatware . There’s also a jab at HCL configuration being “insane” compared to structured config files . That’s not just nitpicking. It reflects a deeper concern: When you introduce universal agents, you introduce complexity. And complexity rarely stays small. --- ## Native Instrumentation Is Boring — And That’s the Point Native Prometheus instrumentation is: - Language-specific. - Stable. - Direct. - Focused only on metrics. It doesn’t try to solve tracing. It doesn’t try to export logs. It doesn’t build cross-signal pipelines. It exposes `/metrics`. Prometheus scrapes it. Done. When you’re running a metrics-first stack and Prometheus is the source of truth, that simplicity is powerful. You avoid: - Semantic mismatches. - Feature gaps. - Translation edge cases. - Surprises in aggregation behavior. And most importantly, you reduce moving parts. --- ## The Hidden Risk of “Universal” Instrumentation Universal instrumentation frameworks age differently than single-purpose ones. They grow. They add layers. They add configuration knobs. They add compatibility modes. And eventually, they start solving problems you don’t actually have. That’s where the “bloatware” comment hits . It’s not that OpenTelemetry is inherently bloated. It’s that universal agents tend to accumulate responsibilities. When you only need metrics, native Prometheus libraries feel leaner. --- ## But Metrics Aren’t the Whole Story The counterargument is obvious. Metrics alone aren’t enough in complex systems. Traces reduce RCA time. Logs provide context. Correlation across signals is powerful. If you’re already deploying OpenTelemetry for tracing, it can feel redundant to use separate instrumentation for metrics. That’s the architectural fork: - Optimize each signal for its native ecosystem. - Or unify signals under one instrumentation framework. There’s no universal right answer. --- ## The Audience Matters The author clarified that the blog post was written for a Prometheus audience . That context matters. If your backend is Prometheus. If your queries are PromQL. If your alerting is based on Prometheus-native semantics. Then native instrumentation is aligned by default. You’re not fighting translation layers. You’re not depending on bridge components to behave perfectly. You’re using the system as designed. --- ## Architecture Is Constraint-Driven Look at the push vs pull comment again . If firewall rules make pull-based scraping impractical, your architecture will push you toward collectors. If you’re widely distributed across public networks, you might accept additional overhead for centralized ingestion. Constraints drive design. And instrumentation strategy should reflect constraints, not ideology. --- ## The Real Takeaway This debate isn’t about which project is “better.” It’s about alignment. Native Prometheus instrumentation aligns perfectly with Prometheus. OpenTelemetry aligns perfectly with multi-signal observability strategies. When those goals overlap, friction appears. The blog post triggered discussion because it was opinionated . And in observability, opinionated guidance is rare. Most content hedges. Most tools promise everything. Sometimes it’s refreshing to hear: “If you’re using Prometheus for metrics, just instrument for Prometheus.” That doesn’t negate traces. It doesn’t dismiss logs. It doesn’t attack OpenTelemetry. It just argues for reducing unnecessary abstraction layers when your stack is already decided. And in infrastructure, fewer layers usually means fewer surprises. Which, at 3AM, is often what matters most.