.CONF & SPLUNKLIVE!

Announcing Native OpenTelemetry Support in Splunk APM

At Splunk, we've been leading the way in observability and helping accelerate the adoption of the OpenTelemetry project. With the trace specification reaching a stable maturity level and several SignalFx Gateway and client library capabilities being upstreamed, we're ready to go all-in while we continue accelerating the growth and adoption of OpenTelemetry beyond the commitments we made last year.

Contributions from cloud providers, vendors and most importantly end-users in OpenTelemetry is what continues to make the project the key solution to supporting observability data, and a solution enterprises can rely on to unshackle their infrastructure and accelerate their cloud journey. Today, I’m excited to talk about a set of capabilities in OpenTelemetry and announce native Splunk support.

Splunk OpenTelemetry Client Libraries

First, we are excited to announce Splunk distributions of the OpenTelemetry Java and Python client libraries. These beta release distributions support automatic (no code modification) trace instrumentation making it easy to get started with distributed tracing. In addition, we are announcing the deprecation of the SignalFx Java and Python tracing libraries. These SignalFx libraries will continue to be supported, but we are 100% committed to OpenTelemetry instrumentation and actively working to upstream all SignalFx tracing library support to the project. Broader stack support is critical to supporting a wide variety of applications and making it easier for organizations to adopt observability.

Splunk OpenTelemetry Collector

We are also announcing the Splunk distribution of the OpenTelemetry Collector. This beta release distribution comes configured out-of-the-box to support Splunk APM and Splunk Infrastructure Monitoring. It supports receiving data from the most popular open-source solutions including Jaeger, Zipkin and Prometheus making it easy to get started. With one command, you can deploy the Collector in a variety of form factors including Docker, Kubernetes, Linux and Windows. Native integration helps organizations adopt observability practices faster, reducing the friction of operating and launching applications. In addition, we are announcing the deprecation of the SignalFx Gateway and Smart Gateway. Over the last year, we have made several major contributions to the Collector including support for receiving Carbon and Collectd data as well as adding metric processors including the ability to batch and add labels. As a result, the Collector is now a full replacement for the Gateway.

Native OTLP Support

OpenTelemetry Protocol (OTLP) is the standard format for storing and transmitting data in the OpenTelemetry project – a standard proposed by Tigran Najaryan at Splunk. OpenTelemetry client libraries default to sending data in OTLP format and the Collector leverages OTLP to support translating received data into exported data, thus providing a vendor-agnostic collection mechanism. As a result, we decided to add the ability to ingest and understand OTLP natively in Splunk APM. All you need to do is point your OpenTelemetry client libraries or Collector to the Splunk APM endpoint.

100% OpenTelemetry Semantic Conventions

One less-known part of OpenTelemetry is its data semantic conventions. These conventions define an open standard to specify metadata on data sources. By leveraging these semantic conventions, the telemetry data generated by OpenTelemetry becomes portable and vendor-agnostic. Starting today, Splunk APM defaults to OpenTelemetry semantic conventions and provides automatic remapping from OpenTracing semantic conventions for a seamless experience regardless of convention followed.

Looking Ahead

While Splunk has doubled down on OpenTelemetry in the last year, we are really just getting started. We recently:

Tim Tully, Splunk’s Chief Technology Officer and SVP, is a longtime champion of open source and OpenTelemetry.

“Splunk’s continued dedication to open source and OpenTelemetry shouldn’t surprise anyone. As I’ve said before, open source is the future of software and OpenTelemetry is the future of observability. You’ll hear us repeat that message throughout .conf20, and you’ll see how OpenTelemetry has helped Splunk define the future of APM.”

Regardless of your interest in using Splunk products and services, we would love to see you participate in the OpenTelemetry revolution. There are a variety of ways to get involved in this rapidly growing project:

If you want to accelerate OpenTelemetry with us, we are hiring and are remote-friendly!

Learn More at .conf20

At .conf20 this week there will be sessions on OpenTelemetry, Splunk APM and Splunk Observability. The virtual conference is free so be sure to check it out!


Follow all the conversations coming out of #splunkconf20!

Steve Flanders is a Director of Engineering at Splunk responsible for Observability “Getting Data In”, which includes contributions to the CNCF OpenTelemetry open-source project. Previously, he was the Head of Product and Experience at Omnition, which was acquired by Splunk. Steve has an extensive background in software development, user experience, product design, and operational management. He has a strong focus on product usability, data-driven decision making, and agile development processes.

TAGS

Announcing Native OpenTelemetry Support in Splunk APM

Show All Tags
Show Less Tags

Join the Discussion