If you've stumbled (or purposefully landed) on this blog post, chances are you are new to—or diving deeper—into the observability space, o11y for short. Suffice it to say, you’re not in Kansas anymore. Honeycomb in a lot of ways can serve as a yellow brick road into o11y, and this article should serve as an introduction into how Honeycomb facilitates implementing o11y into applications and distributed services.

Tracing, or more specifically distributed tracing or distributed request tracing, is the ability to follow a request through a system, joining the dots between all the individual system calls required to service a particular request. Although tracing logs have been around for some time, the trend toward distributed architectures, microservices, and containerization has elevated it from nice-to-have status to an essential piece of the observability puzzle.

We are back with a simplified configuration for another critical open-source component, Hadoop. Monitoring Hadoop applications helps to ensure that the data sets are distributed as expected across the cluster. Although Hadoop is considered to be very resilient to network mishaps, monitoring Hadoop clusters is inevitable. Hadoop is monitored using the JMX receiver. The configuration detailed in this post uses observIQ’s distribution of the OpenTelemetry collector.

If you use Windows, you want to monitor Windows Events. With our latest contribution to the observIQ OpenTelemetry Collector, you can easily monitor Windows Events with OpenTelemetry. You can utilize this receiver in conjunction with any OTel collector: including the OpenTelemetry Collector and observIQ’s distribution of the collector. Below are steps to get up and running quickly with observIQ’s distribution, and shipping Windows Event logs to a popular backend: Google Cloud Ops.

Earlier this year Gartner published a report discussing OpenTelemetry and its place in enhancing Application Performance Monitoring (APM).

We are back with a simplified configuration for another critical open-source component, Zookeeper. Monitoring Zookeeper applications helps to ensure that the data sets are distributed as expected across the cluster. Although Zookeeper is considered to be very resilient to network mishaps, monitoring is inevitable. To do so, we’ll set up monitoring using the Zookeeper receiver from OpenTelemetry.

OpenTelemetry (also known as OTel) is a popular open-source framework used to generate telemetry data for traces, metrics, events and logs. In this guide, we are going to cover the best observability and application performance management tools that can be used alongside OpenTelemetry to transform telemetry data into responsive reporting dashboards.

How do you go from A to Z with observability and OpenTelemetry? This post answers a question we hear often: “How do I get started on instrumentation with OpenTelemetry, while also following best practices for the long-term?” This article is all about taking you from A to Z on instrumentation. This will help you: We will use a simple greeting service application written in Node.js to understand the journey. You can find the pre-instrumented state here.

OpenTelemetry is one of the most fascinating and ambitious open source projects of this era. It’s currently the second most active project in the CNCF (the Cloud Native Computing Foundation), with only Kubernetes being more active. I was at KubeCon Europe last month, delivering a talk on OpenTelemetry and it was amazing to see the full house and the excitement and interest around the project.

We are constantly working on contributing monitoring support for various sources, the latest in that line is support for Cassandra monitoring using the OpenTelemetry collector. If you are as excited as we are, take a look at the details of this support in OpenTelemetry’s repo. The best part is that this receiver works with any OpenTelemetry collector: including the OpenTelemetry Collector and observIQ’s distribution of the collector.