Enable observability for your cloud-native Java applications

In this article, we’ll explore why observability is important for effective cloud-native applications and how we can enable this. We’ll investigate open source tools and technologies we can make use of, what observability features and behaviors they enable, and how we can try them out with the help of technologies like MicroProfile, Open Liberty, Jaeger), and Instana.

Why observability is important for cloud-native applications

Innovations within cloud infrastructure, the evolution of cloud-native architecture toward microservices-based applications, and the distributed nature of cloud-native deployments have provided significant innovations and advantages but have brought with them new challenges. One such challenge is the ability to effectively observe and monitor an application’s behavior and performance in real time. Our applications are more complex than ever, often composed of tens to hundreds of distributed microservices, making them challenging to manage and monitor.

This increased complexity is precisely the reason that effective observability of our applications is so critical. We need to be able to identify and act upon failures, bottlenecks, resource constraints, and issues that may arise within our deployed applications. With many of these applications mission-critical, it is vital that they remain responsive and resilient. This can only occur if we are aware of how our applications are performing in real time and how our own services depend on or affect other services.

So, two questions then arise: How can we enable effective observability for our cloud-native Java applications, and what tools can we use for this?

Enabling effective observability

To make a system observable, it must first be instrumented. What do we mean by this? Instrumented means the code should emit traces, metrics, and logs.

A Distributed Trace, more commonly referred to as a Trace, records the paths taken by requests (made by an application or end user) as they disseminate through multi-service architectures, like microservice, macroservice, and serverless applications. Without tracing, it can be challenging to pinpoint the cause of performance problems in a distributed system. Tracing helps to improve the visibility of an application’s health and enables debuging behavior that can be difficult to reproduce locally. So, to summarize, tracing makes debugging and understanding distributed systems less daunting by breaking down what happens within a request as it flows through a distributed system.

Metrics are aggregations of numeric data about infrastructure or an application over a period of time. Examples include system error rates, CPU utilization, and request rates for a given service.

A Log is a timestamped message emitted by services or other application components, providing coarser-grained or higher-level information about system behaviors (like errors, warnings, etc) and typically will be stored in a set of log files. Unlike Traces, they are not necessarily associated with any particular user request or transaction. They are found almost everywhere in software and have been heavily relied upon by developers and operators to help understand system behavior. Unfortunately, logs aren’t extremely useful for tracking code execution, as they typically lack contextual information, such as where they were called from. Thus, they become far more useful when they are included within a Trace.

Once the code is able to emit instrumented data (traces, metrics, and logs), this data should be sent to an observability back end. There are a number of options for these back ends, ranging from self-hosted open source tools such as Jaeger and Zipkin to commercial SaaS offerings like Instana.

In the past, the way code was instrumented would vary, as each observability back end would have its own instrumentation libraries and technologies for emitting data. What this meant was that there was no standardized data format for sending data to an observability back end. So if a company chose to switch observability back ends, it meant that they would potentially have to reinstrument their code and configure new technologies just to be able to emit telemetry data to the new tool. With a lack of standardization, the net result was a lack of data portability, and the onus was on the user to maintain instrumentation libraries. However, this problem was recognized by the community, and open source projects were initiated to tackle this lack of standardization, including OpenTracing, OpenCensus, and OpenTelemetry – tools we can make use of to enable effective observability.

OpenTelemetry

OpenTelemetry can be a great open source tool to use to tackle the observability challenges highlighted and enable effective insights into cloud-native applications. OpenTelemetry is an incubating project from the Cloud Native Computing Foundation (CNCF) and originated through a merger of the OpenTracing and OpenCensus projects:

• The OpenTracing project (now archived) provided vendor-neutral APIs for instrumenting distributed tracing within microservices and sending telemetry data over to an observability back end. However, OpenTracing relied on developers to implement their own libraries to meet the specification.
• The OpenCensus project (now deprecated) provided a set of language-specific libraries, called Census, that could be used to automatically capture traces and metrics from services. It included three APIs: stats, tracing, and tags. The core functionality of OpenCensus was the ability to collect traces and metrics from your app, display them locally, and send them to any analysis tool (i.e., a back end).

In the interest of having a single standard, OpenCensus and OpenTracing were merged to form OpenTelemetry in May 2019. OpenTelemetry offers a collection of tools, APIs, and SDKs that can be used to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to observability back ends (i.e., open source and proprietary). OpenTelemetry has three main parts and one additional part: Tracing, Metrics, Logging, and Baggage for additional information.

OpenTelemetry and MicroProfile

MicroProfile Telemetry 1.0, new to MicroProfile 6.0, adopts OpenTelemetry from the CNCF to allow cloud native Java applications to benefit from OpenTelemetry through a set of open and easy-to-use APIs. It also enables automatic tracing of Jakarta RESTful web services if configured. Currently, the MicroProfile OpenTelemetry 1.0 specification only supports the Tracing and Baggage elements of the OpenTelemetry specification. However, the aim in future is to adopt all three main parts (to include Metrics and Logs) when they are stable.

Try OpenTelemetry

You can now make use of OpenTelemetry through the MicroProfile OpenTelemetry 1.0 specification and the latest Open Liberty betas (from 22.0.0.10-beta). To try OpenTelemetry for yourself with Open Liberty, check out our interactive hands-on guide, Enabling distributed tracing in microservices with OpenTelemetry and Jaeger. This content focuses on open source technologies, including the use of open source observability backends like Jaeger.

Alternatively, if you’d like to make use of an alternative back end like Instana, you can find out more about this technology and how it enables end-to-end observability in our Observability-driven development article.