Reactive Systems in Java

Chapter 13. Observing Reactive and Event-Driven Architectures

So far, we’ve focused on how to develop reactive systems. What we haven’t discussed is how to ensure that all the components of our reactive system are functioning as we expect them to. This is the focus of the chapter: how we monitor and observe our reactive and event-driven architecture.

Why Is Observability Important?

When an application is a single deployment, or monolith, we have a relatively easy time observing how the application is performing. Everything we need to observe is in one place. Whether it’s checking logs for errors, monitoring the utilization of CPU and memory, or any other aspect, it’s all accessible.

With a reactive and event-driven architecture, instead of one deployment, it’s often several, dozens, or even hundreds. We’re no longer dealing with a single place to view the information we need to monitor and observe, but many places! Observability tooling provides a means for us to gather this information and provide a single place to view it again.

However, we need to gather the necessary information, or telemetry, from the components in the event-driven architecture to enable a singular view. Telemetry consists of any information we gather from processes for the purpose of observing a system. The most common types of telemetry are as follows:

Logs

Textual messages often written to console output, logfiles, or exported to specific log-processing systems. We can also provide more structured logging ...