Today, the Honeycomb OpenTelemetry Distribution for Java reaches a major milestone with a 1.0 release. This is the first Honeycomb OTel Distro to come out of beta and go into the general release category, and you can expect more to come!
Placing winning bets on OpenTelemetry
In August 2021, we shifted our support to making OTel the de facto standard for application instrumentation when we proclaimed that Honeycomb is All-in on OpenTelemetry. Since then, the overwhelming majority of new Honeycomb customers use OpenTelemetry to send us their data, from small startups to massive enterprises alike. It’s clear that open standards and vendor neutrality matter a great deal to you, just as they matter to us.
To that end, we’ve been working on providing a number of OpenTelemetry Distros for different languages. Today, we’re happy to report that the Honeycomb OpenTelemetry Distro for Java is now 1.0!!! 🥳🥳🥳
We want to thank users of the beta distros for helping us iterate the design of these SDKs. As you might know, our OTel distro for Java is made up of three main components:
- An automatic instrumentation agent that you can run alongside your app
- A set of configuration options to make it as easy as possible to send data to Honeycomb
- A deterministic head sampler
Since its first release, we’ve overhauled our design approach. The first release exposed a HoneycombSdk class that wrapped the base OTel SDK class. However, real-world usage showed that a better approach was to simply expose the vendor-neutral SDK. Now, our distro focuses on making your configuration and export to Honeycomb as simple as possible.
Getting started with Java
The quickest way to get started with our Java SDK distribution is to run the automatic instrumentation .jar with your app. From there, you can enhance the automatically generated traces with manual instrumentation code.
See our documentation on OpenTelemetry for Java to learn how to acquire, set up, and run the agent. From there, you can refer to OpenTelemetry documentation for Java on how to use the OpenTelemetry APIs in manual instrumentation.
Honeycomb now has better support for OpenTelemetry app metrics
In addition to the new 1.0 distro, we’ve made enhancements to make it easier for you to send Honeycomb your metrics data by compressing it into fewer events for you—automatically!
Generally speaking, there are two kinds of metrics that you may want to send to Honeycomb:
- Host Metrics, such as CPU or Memory utilization of a VM or cluster
- App Metrics, such as garbage collection data or performance metrics of the JVM
When we released Metrics in Fall 2021, OpenTelemetry metrics were still relatively new. As OpenTelemetry metrics continue to mature, different components and SDKs offer the ability to collect common metrics and create your own. A critical challenge at release was overcoming a need to compress metrics data before sending it to Honeycomb.
Why compress metrics data? It’s actually an interesting problem at the heart of Honeycomb’s data store and pricing model. Observability favors ultra-wide events with lots of dimensions and values of high cardinality. Honeycomb is built to handle data in this shape economically: it’s fast as hell and doesn’t cost you an arm and a leg to attach more context to something. Our pricing model is per-event, with no practical limitations on how wide or complex those events are.
However, Metrics (aka time series) data is typically narrow and numerous. Each individual event representing a metric generally contains very little information, and you usually want to send a lot of them. For Honeycomb, that means eating into your event volume with very shallow data. Whoops! This is partly why we have a nuanced view of Metrics as complementary to traces and events from your application, rather than being the backbone of observability.
Previously, to collect and send us any metrics data, you needed to do so with an OpenTelemetry Collector Configuration Generator. Critically, the config ensured that it is economical to send metrics data to Honeycomb by compressing many shallow events into a singular and wider event within the OpenTelemetry Collector prior to sending it.
Now, we offer compression for App Metrics that happens automatically when it reaches our ingesting endpoints. Send App Metrics from your SDK to the Honeycomb endpoint and we’ll automatically compress them for you. (However, you should note that you’ll still want to use the OpenTelemetry Collector Configuration Generator when sending Host Metrics.)
When compressing metrics data, it turns out, you don’t really lose visibility on things when you compress seven metric “events” down into one wider event. So that’s exactly what we’re doing now for OpenTelemetry App Metrics you send to Honeycomb. We find this approach strikes the right balance between fidelity of data and economic use of your event volume (though we may explore more sophisticated compression strategies in the future). If you have feedback on this approach, let us know in Pollinators!
OpenTelemetry continues to mature
Lastly, we want to highlight some of the awesome stuff going on in OpenTelemetry since our last blog update. OpenTelemetry is maturing and we whole-heartedly believe that it is the best option for generating observability data today—and that it will only get better with time.
Distributed tracing with OpenTelemetry is generally available for JavaScript, Java, .NET, Python, Ruby, Go, C++, and Erlang/Elixir. Additionally, most of these languages have a rock-solid suite of automatic instrumentation packages that you can use to get end-to-end visibility of your systems with very little effort. Note that if you’re using Rust, PHP, or Swift, distributed tracing is still in preview for those languages.
Stability for Metrics in OpenTelemetry is a big focus for 2022. It is stable in the spec and protocol, and language SDKs are starting to roll it out in alpha form. Since metrics are in active development for many languages, it’s best to refer to a language documentation page for the latest status for each language SDK.
Logging for OpenTelemetry is still under active development. The spec reached stability yesterday! Congrats to the special interest group working on that! The protocol is under active development and implementations in the language SDKs and the Collector is on the horizon.
To learn more about other aspects of OpenTelemetry and their statuses, see OpenTelemetry Status.
OpenTelemetry docs are more uniform and complete
Since last Fall, we’ve heard a lot of feedback from existing customers and new users: OpenTelemetry can be hard to learn due to sparse documentation. While there are lots of ways to solve this problem, the most fundamental way is to write a bunch of docs and contribute them upstream.
To that end, we’ve been spending a lot of time contributing documentation improvements upstream, collaborating with others to ensure that each language covers all the major topics in a uniform way. Together, we’ve all been able to significantly improve the following topics for .NET, Go, Java, JavaScript, and Python:
- Getting started with automatic instrumentation
- Manual instrumentation topics: tracers, spans, span events, span links, etc.
- Exporting data to an endpoint or collector, Zipkin, Prometheus, etc.
- SDK-specific concerns, such as using the annotations API with Java
This journey is far from over. Our goal, by the end of 2022, is to have every language with a stable SDK have comprehensive, vendor-neutral, accurate, and uniform documentation. We believe you should be able to search for a concept in OpenTelemetry and find how to use it in your language of choice with OpenTelemetry documentation.
We’re committed to upstream contributions in service towards this goal. Want to help pitch in? The OpenTelemetry Communications SIG is open and welcoming contributors.
What’s next for Honeycomb and OpenTelemetry
We said it when we told you we were all-in on OTel, and we’ll say it again: The future looks bright for OpenTelemetry and Honeycomb.
We’re still continuing to build more Honeycomb OTel Distros for each major language so that sending data to Honeycomb is as easy as possible. We’re still making improvements to how we ingest your OTel data. We will continue to contribute upstream and continue to ramp up those contributions to further support the future we all want to see for OTel.
As OpenTelemetry matures, our support for it will follow in lockstep so that you never have to wonder if you can send us your data. We will continue to ensure that OpenTelemetry becomes the de facto choice for application instrumentation.
Want to help further contribution efforts with OTel? Let us know in Pollinators!
