Written by Liz Fong-Jones and Phillip Carter. OpenTelemetry, also known as OTel, is a CNCF open standard that enables distributed tracing and metrics collection from your applications. At Honeycomb, we believe that OpenTelemetry is the best way to ingest the high-cardinality and high-dimensional data that every system, no matter how complex or distributed, needs for observability.
Microservices architecture is the new norm for building products these days. An application made up of hundreds of independent services enables teams to work independently and accelerate development. However, such highly distributed applications are also harder to monitor. When hundreds of services are traversed to satisfy a single request, it becomes difficult to investigate system issues.
Getting existing telemetry into Honeycomb just got easier! With the release of the Datadog APM Receiver, you can send your Datadog traces to the OpenTelemetry Collector, and from there, to any OpenTelemetry-compatible endpoint. Often, evaluating a new tracing solution requires re-instrumenting your applications from the ground up in a new vendor’s tooling. It’s a pretty high bar to clear just to see if a solution is worth adopting.
OpenTelemetry (OTel), an open source project under the Cloud Native Computing Foundation (CNCF), is a collection of tools, APIs and SDKs for generating and collecting observability data (mainly trace, metrics and logs) from cloud-native applications. An industry-standard for distributed tracing and observability, OTel enables analyzing application health and performance to ensure production-readiness and support production monitoring.
When you want to direct your observability data in a uniform fashion, you want to run an OpenTelemetry collector. If you have a Kubernetes cluster handy, that’s a useful place to run it. Helm is a quick way to get it running in Kubernetes; it encapsulates all the YAML object definitions that you need. OpenTelemetry publishes a Helm chart for the collector. When you install the OpenTelemetry collector with Helm, you’ll give it some configuration.
Customer-facing applications request and process many types of sensitive data, such as API keys, credit card numbers, and email addresses. As your application scales in size and complexity, it becomes harder to keep track of this sensitive data moving across more services, increasing the risk of data leaks.
Today, I’d like to share with you a new community-contributed integration that helps you optimize and debug your Gradle builds. This new Gradle plugin is available today, is free to use, and you can use it immediately with a free Honeycomb account.
Just a few short months ago, we talked about a bunch of updates to Honeycomb’s support for OpenTelemetry. To the surprise of no one, we’ve got more updates to share!
OpenTelemetry is an open source, vendor-neutral observability framework that provides tools, APIs, and SDKs to collect and standardize telemetry data from cloud-native applications and services. One of OpenTelemetry’s key components is the OpenTelemetry Collector, which receives and processes data before using exporters to route it to the destinations of your choice.
OpenTelemetry is an open source set of tools and standards that provide visibility into cloud-native applications. OpenTelemetry allows you to collect metrics, traces, and logs from applications written in many languages and export them to a backend of your choice.
One analogy of a microservice architecture that I personally like is the idea of a large office setting with disparate departments communicating through an internal mail system. I imagine manilla envelopes being passed around, carried on carts through hallways, up elevators—passing the information one department needs to the next department.
Modern application architectures are complex, typically consisting of hundreds of distributed microservices implemented in different languages and by different teams. As a developer, site-reliability engineer, or DevOps professional, you are responsible for the reliability and performance of these complex systems. With observability, you can ask questions about your system and get answers based on the telemetry data it produces.
This article will give you a quick overview of some of the key attributes you should know in order to get started with leveraging the OpenTelemetry collector for your next telemetry project. As an integral component of any project that involves distributed tracking, the OpenTelemetry Collector plays an important role. Simply put, it is helpful to know that the collector itself is a data pipeline service that collects telemetry data.
Many developers don’t know what instrumentation really is, and those who do don’t really understand the black magic that takes an application and makes it emit telemetry, especially when automatic instrumentation is involved. On top of that, each programming language has its own tricks. I wanted to unwrap this loaded topic on my podcast, OpenObservability Talks. For this topic I invited Eden Federman, CTO of Keyval, a company focused on making observability simpler.
When we set out to trace applications running outside of AWS Lambda, there was little doubt in our minds that building on top OpenTelemetry was by far the best course of action. There are many reasons for this, but chiefly, it is a question of coverage. At its most fundamental level, achieving coverage requires as-wide-as-possible support for technologies, and interoperability among instrumentations.
Microservices are loosely coupled services that are organized around business capabilities. In an ideal microservices architecture, each service can be developed and deployed independently. To form a functional application, these separate services communicate with each other in the production environment (and even beforehand).
