Sharpen your coding skills with observability puzzlers

If you want to get better at sports, you have to train. The same applies to improving your observability skills. Application Observability Code Challenges as puzzlers are here to train you.
For example virtual threads can be very useful, but if there are problems with virtual threads, do you know how to spot them?

With these challenges, you can work through a prepared challenge with a prepared setup. The code contains some issues that you need to identify. Observability tools such as Grafana are already in place (or you can use your own). By making changes to the code, run the test and you can view the results in raw metrics, logs, traces, and prepared dashboards.
These exercises help you practice using observability tools such as Grafana.

Sometimes problems are not that obvious, even if you have a stacktrace. Adding more information to your traces, logs and metrics will give you more insights, I will tell you how to do that.

Alerts from production, help me!! Stay calm — I know what to do!
If you are trained, you know how to use the observability tools to identify problems, you will feel comfortable using them. It is important to be prepared for the real situation in order to handle an incident adequately.

I will explain what these code challenges look like and how to run them and I will give a sneak peak, but I will not demonstrate the full challenges — that's your job!

Learn how to spy in the JVM! Make your (legacy) application more observable

Did you know the Java Instrumentation API has existed since Java 5? It's a legal way to peek inside the JVM, and it's the foundation both Byte Buddy and the OpenTelemetry Java agent are built on.

What if you could add real instrumentation to a legacy or vendor application without touching its code? Ten years ago, most Java applications weren't built with observability in mind: barely any logs, hardly metrics (except JMX), no traces, just darkness.

I'll show you how the Instrumentation API and Byte Buddy work together, how the OpenTelemetry Java agent uses them under the hood, and how to build your own custom extension on top of it, all to get deep insights about the running application.
In a live demo I will show how to intercept method calls, create distributed traces, and emit custom metrics with a custom OpenTelemetry extension.

You'll leave with working code you can apply to that legacy system no one wants to touch.

Beyond System.out.println: Applying a Debugging Mindset at Scale

Debugging a consistently failing unit test is easy; you set a breakpoint and fix it. But how do you debug a "random" failure in a massive microservices landscape or a distributed monolith?

During an interview, I was once told, "You are more of a debugger than a coder." They were right: I thrive on the bugs that make others give up: the nasty, intermittent issues hidden under the carpet.
But you cannot solve these issues with 'System.out.println()' or a simple debugger attached to localhost.

Debugging at scale requires a shift in mindset and tooling. It requires moving from the paradigm of "5 Whys" and 'logger.info' to a structured observational approach based on observability data.
Based on production outages, I'll share how I uncovered the problems, the lessons I learned and how you can combine a debugging mindset with observability tooling like OpenTelemetry and the Grafana toolset to gain deeper insights.

Two-Way Observability: AI Debugs Your Code, You Debug Your AI

Your AI coding agent can already read your code. What if it could also read your logs, metrics and traces and directly tell you what's actually broken?

Grafana gcx gives an AI agent direct, live access to your observability data. I'll show it diagnosing a real issue: pulling observability data, correlating it with your code and proposing the actual fix. Not just "check your logs", but real fixes.

Then I'll show the reverse: with OpenTelemetry enabled on an AI coding agent itself, you can see what your agent is doing in a Grafana dashboard, tokens burned, tools called, cost per session. So you can observe your coding agent's behavior.

You'll leave with runnable examples for both flows that you can try yourself the next day: an agent that debugs your app using your existing telemetry, and a dashboard that debugs your agent.

How I solved production issues with OpenTelemetry (and how you can too)

Ensuring the reliability of your Java applications is critical in today's fast-paced world. But how do you identify and fix production issues before they get worse? With cloud-native applications, it can be even more difficult because you can't log into the system to get some of the data you need. The answer lies in observability - and in particular, OpenTelemetry.

In this session, I'll show you how I used OpenTelemetry to solve several production problems. You'll learn how I uncovered critical issues that were invisible without the right telemetry data - and how you can do the same. OpenTelemetry provides the tools you need to understand what's happening in your application in real time, from tracking down hidden bugs to uncovering system bottlenecks. These solutions have significantly improved our applications' performance and reliability.

A key concept we will use is traces. Architecture diagrams often don't tell the whole story, especially in microservices landscapes. I'll show you how traces can help you build a service graph and save you hours in a crisis. A service graph gives you an overview and helps to find problems.

Whether you're new to observability or a seasoned professional, this session will give you practical insights and tools to improve your application's observability and change the way how you handle production issues. Solving problems is much easier with the right data at your fingertips.

My goal for the attendees of this session is to get them excited about using OpenTelemetry (the industry standard) as a way to improve observability, so they can learn from their own software in production and improve what is needed.
And I will show how to use Grafana to visualise the data, as I believe that visualisation is a very powerful way to get more insights.

Unleash the power of distributed traces

Some of your customers are complaining about timeouts but your graphs show no problems, can you find the hidden timeouts? Can you see why some requests are failing? What is different about them compared to successful requests? How many times has this happened in the last week?

You have probably heard of observability and OpenTelemetry. Traces and spans are a core concept of OpenTelemetry. Spans can help you answer the questions above.
Traces are often associated with HTTP requests, but it they can be used for much more, such as database queries.
But do you know how to use span attributes and resource attributes? I will explain the differences. Do you know about span events? And how to record exceptions on a span?
In this talk I will show you how to use distributed traces in a microservices landscape using OpenTelemetry.

There are 4 parts I will talk about:
1) how to (auto)instrument your code to create spans, add attributes, record exceptions and other use cases of span events
2) how to store traces in Tempo
3) how to query for all the details to answer your questions with Grafana
4) how a service graph, created based on traces, gives an overview and helps to pinpoint the problem

After this talk, you will know how to use OpenTelemetry to enrich your spans and how to find those spans with relevant information.
Join this talk to supercharge your spans and help you answer all these questions!