Feedback is at the core of agile development. We strive to improve and shorten the feedback loops wherever we can. We do code reviews, ask for customer feedback, and run automatic test suites to locate regressions in functionality and performance. However, there is an often overlooked feedback loop where we can gain important insights. One that will allow us to be proactive instead of reactive.
Have you ever felt worried when releasing a new version of your product? How many issues will our customers find this time? Would it not be better to locate some of these issues sooner before deploying the product into production?
We can get that feedback loop by combining OpenTelemetry and Micrometer alongside various open-source tools. We can also gain insights into how our code is performing by using a new tool. It analyses the collected data and produces insights into our code that we should look at. We can get these insights before submitting our changes to the code base. More about this tool in a bit. First, let’s look at OpenTelemetry. What is it, and how can we use the information it collects?
OpenTelemetry
OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. It has been standardized and works with many languages and frameworks.
It allows us to get a view into how our application is performing much in the same way a racing team uses telemetry to analyze and optimize the performance of a race car during practice and a race. By using this information, we can be proactive instead of reactive to possible issues with our applications.
How to activate this depends on your framework or language. If you are using Quarkus, you use an extension. If you are using Java without a framework, you use an agent. There is already a lots of documentation on enabling OpenTelemetry for different languages and frameworks, and I won’t repeat it here.
Collecting data won’t help us much. Luckily, several open-source tools will help us visualize the collected telemetry data.
Visualize telemetry
Jaeger allows us to monitor and troubleshoot workflows in complex distributed systems.
Prometheus helps us go from metrics to insights. It collects and stores its metrics as time series data. Metrics information is stored with the timestamp at which it was recorded, alongside optional key-value pairs called labels.
Grafana enables us to query, visualize, alert on, and explore your metrics, logs, and traces wherever they are stored.
OTel Collector is a vendor-agnostic way to receive, process, and export telemetry data. It is a central hub that connects the different parts of your observability environment.
Using telemetry
Now, we can collect and visualize information about the runtime performance of our application. We can plot graphs showing the number of requests per second and timing. We can follow requests between and internally in our services.
Enabling OpenTelementry and visualizing it in Jaeger and Grafana have given us more insight into how our application is performing. We are getting earlier feedback of potential problems and can be proactive instead of reactive. The problem is that we get so much data that it’s hard to locate problem areas.
Is there something we can do about that?
As it turns out, there is. Stay tuned for the next part, where we will build on OpenTelementry to get continuous feedback from our applications.
The Empathetic Developer 