OpenTelemetry Moves Past the Three Pillars

This is an article from DZone's 2021 Application Performance Management Trend Report.

For more:


Read the Report

Last summer, the OpenTelemetry project reached the incubation stage within the Cloud Native Computing Foundation. At the same time, OpenTelemetry passed another mile marker: over 1,000 contributing developers representing over 200 different organizations. This includes significant investments from three major cloud providers (Google, Microsoft, and AWS), numerous observability providers (Lightstep, Splunk, Honeycomb, Dynatrace, New Relic, Red Hat, Data Dog, etc.), and large end-user companies (Shopify, Postmates, Zillow, Uber, Mailchimp, etc.). It is the second-largest project within the CNCF, after Kubernetes. 

Getting Started With OpenTelemetry

With the growing number of mass migrations to the cloud, OpenTelemetry solves new challenges by simplifying and reducing time spent on data collection through automation. OpenTelemetry is an open-source collection of tools, APIs, SDKs, and specifications with the purpose of standardizing how to model and collect telemetry data. OpenTelemetry has been proven to enable effective observability and it aims to become a standard of observability implementation.

In this Refcard, we introduce core OpenTelemetry architecture components, key concepts and features, and how to set up for tracing and exporting telemetry data.

How to Trace JVM Filesystem Accesses Using Java

For tracing filesystem accesses of Java applications, native tracing facilities are always the first choice. On Windows, use Process Monitor to trace I/O. On Linux, use strace. Other platforms provide similar facilities.

By tracing directly in Java, you can work around environment limitations. For example, strace is unavailable in a container that lacks the CAP_SYS_PTRACE capability and the container host is not always accessible. Also, a potentially lighter-weight tracing mechanism comes handy for tracing in production environments.

Observability 101: Terminology and Concepts

When I first started following Charity on Twitter back in early 2019, I was quickly overwhelmed by the new words and concepts she was discussing. I liked the results she described: faster debugging, less alert fatigue, happier users. Those are all things I wanted for my team! But I was hung up on these big polysyllabic words, which stopped me from taking those first steps toward improving our own observability.

This post is my attempt to help orient folks who want to learn more about observability but maybe feel overwhelmed or intimidated by the vocabulary list, like I did. My goal is to get everyone on the same page about what these words mean so that we can focus on leveraging the tools and ideas to build better software and deliver more value! 

Rethinking Programming: Automated Observability

Introduction

Observability is the ability to understand the internal state of your system by looking at what is happening externally. In a software system, in order to acquire observability, we mainly implement the following aspects: logging, metrics, and tracing. Especially when we are moving away from monolithic software systems to microservices-based architectures, observability becomes a key aspect of the system design. Compared to monoliths, it’s much harder to troubleshoot issues and do performance tuning in microservices deployments. This is mainly due to the added complexity of working with a distributed system. Thus, your software system should understand these challenges, and be ready to handle any issues that may arise. Observability tools allow us to do this. 

In this article, we will focus on three observability tools: