Part 1 - OpenTelemetry: No Strings (agents) Attached

Let’s talk about OpenTelemetry for a second. If you’ve been anywhere near the observability world lately, you’ve likely heard it tossed around in every other conversation like it’s the latest tech buzzword. But OpenTelemetry isn’t just hype – it’s the open-source standard that has taken over how organizations collect and export telemetry data. It’s currently the #2 project at CNCF – as expected, Kubernetes still owns the top spot!??

For context, here’s a quick refresher on why engineering & reliability teams are embracing OpenTelemetry:

1. Vendor neutrality and flexibility - send data to various backends (observability vendors) without lock-in
2. Standardization and consistency - naming conventions, APIs, etc.
3. Community and extensibility - broad open source contributors and customization
4. Simplified Instrumentation - Instrument once, export anywhere. Avoid multiple libraries
5. Interoperability - works with existing telemetry tools (i.e. FluentBit, vendor agent)
6. Future Proofing - Avoid need for repeated future instrumentation / vendor switching costs

As great as OpenTelemetry is, there’s one little snag: the level of functionality varies dramatically depending on which observability vendor or backend you’re dealing with. Some vendors will smile at you and say, “Sure, we support OpenTelemetry!” while quietly pushing their proprietary agent in your direction with the other hand. Oftentimes, ‘we support OTel’ actually translates to “you'll need our agent alongside OTel to get the functionality that's on our website."

In my opinion, the biggest deal breaker for observability vendors supporting OTel is whether or not their proprietary agent needs to be deployed in tandem in order for customers to experience a full suite of capabilities.?

But doesn’t that somewhat defeat the main purpose of OTel? What about avoiding vendor lock-in??

This forces a critical decision for customers: they must choose between vendor lock-in (proprietary agent + OTel) or vendor neutrality (no proprietary agent, but sacrifice a TON of functionality, simplicity, and automation).??

That said, pairing a vendor's agent alongside OTel is a fantastic way to start embracing this open-source standard, and chances are you'll experience a ton of great observability functionality with that approach.

So what should you expect when you remove the proprietary agent and run OTel on its own?

For almost every Observability vendor, here's what might happen when proprietary agents are not used alongside OpenTelemetry, as several functionality gaps can emerge. Below are the most common and important:?

1. Platform-Specific, Out-of-the-Box Features: Many advanced features of observability platforms, such as AI-driven insights or specialized visualizations, may require data processed through the vendor's agent. Out-of-the-box dashboards and prebuilt service-specific capabilities become far less achievable for these vendors when only OTel is in place, sometimes even presenting siloed metrics/dashboards for OTel-only data.
2. Instrumentation:? While OpenTelemetry provides broad instrumentation capabilities, vendor-specific agents often offer deeper, more tailored instrumentation for their platforms. Removing the agent means more upfront effort to configure OTel instrumentation so that it emits more meaningful or customized metrics, often required to deliver practical Observability.?
3. Correlation: Proprietary agents typically enhance the ability to correlate across different telemetry types (metrics, traces, logs, events), providing a more cohesive observability experience. Without the agent, correlation can become manual or inaccurate leading to longer MTTR as the backend architecture for observability vendors isn’t natively designed to automatically correlate with OTel alone.
4. Naming Conventions: Vendors may have specific naming conventions that are better supported by their agents, ensuring smoother integration with their platforms. When the proprietary agent is removed but the backend is 'expecting' proprietary information (i.e. naming conventions), customers may lose a great deal of standardization and portability.
5. Pre-built Receivers: While OpenTelemetry has a growing ecosystem of receivers, vendor agents often include a wider array of pre-configured receivers optimized for their platforms. This is an advantage of a proprietary agent, but customers may lose critical receivers (or be forced to manually correct) when OTel is deployed in a standalone manner.?
6. Aggregation: Vendor agents frequently offer advanced aggregation capabilities for metrics and traces, which may not be fully replicated in a pure OpenTelemetry setup. This gets quite complicated when the proprietary agent is removed and the time-to-value with OTel is elongated.
7. Tagging: Proprietary agents often provide enhanced tagging capabilities, allowing for more granular filtering and analysis within the vendor's platform. OTel also has wonderful capabilities around tagging! But when the proprietary agent is removed, additional tweaking and configuring of tags may be necessary.

My advice? Don’t let this discourage you from embracing OpenTelemetry! Start to explore and incorporate OTel with your current Observability vendor, even if it means pairing it alongside that vendor’s agent for now. You will (hopefully) experience a full breadth of observability capabilities and when the time comes to ditch your proprietary agents, you will be ready to take the leap.?

One last thing, since you might be asking yourself “wait, are there any solutions out there today that can deliver full functionality with OTel, but don’t require me to install a proprietary agent?”?

The answer is yes!?

Stay tuned for part 2 of this blog series to learn more about Splunk 's OTel-Native approach :) [hint: no strings (proprietary agents) attached].

#opentelemetry #otel #splunk #observability