In a few minutes, we’ll get you set up to run this app yourself, so you can see your own data in Honeycomb to follow along.
Before that, I want to pause and clear up some terminology that Mary, Liz and I threw out in that conversation.
Starting with observability. Observability means: the ability to observe what’s happening inside our software.
From out here in the physical world of people, we can’t naturally see into the digital space of running software.
I want to shine a flashlight, and have the light bounce back to my eyes and show me something. But flashlights are not effective on the moving bits of information that is our running software.
We need a new superpower. We need observability. How do we get it?
It starts with telemetry. Telemetry is data that the software emits to tell its team what’s going on inside.
This is happening. Here’s my current state. Here’s how long it took.
Our software emits telemetry in the form of events.
Events about requests and responses received, events about decisions made.
How does this telemetry get there? We add it! Our flashlight into our code is called instrumentation.
Instrumentation is code that emits telemetry.
Mostly that means library code, autoinstrumentation, that injects telemetry into our frameworks to emit telemetry about what everyone finds important: http requests and responses, database access.
The best autoinstrumentation comes from OpenTelemetry.
OpenTelemetry is a community project for telemetry standards.
What should the data look like? What does it mean? How do we send it, from all the different programming languages and frameworks?
When you use OpenTelemetry libraries, you do some configuration, sometimes initialization code, and that’s it. Your software emits telemetry.
Now the hard part: what will you do with it?
You could throw all these events into a log somewhere, and they would still be telemetry. But this would not be observability.
Digging through logs is a slog. Slow, tedious, ain't gonna do it every day. We don’t want a slog. We want superpowers!
We need technology to receive that telemetry and convert this signal to stories we can see. That’s where the real power is.
When your instrumentation uses OpenTelemetry standards, you have choices.
Our choice is Honeycomb.
Honeycomb gets us observability by weaving these telemetry events into traces and visualizations of our choosing.
Graphing aggregates lets us notice problems. Custom queries and Bubble Up let us find the problem. Then traces let us look into the problem, at the detail level of a single customer experience.
Observability with Honeycomb includes high-level performance monitoring, individual customer views, and many paths in between.
In this course, we’ll start from simple graphs of counts.
Go to Bubble Up, to custom queries, and down into a slow trace to understand what’s happening in this Sequence of Numbers application.
At the end, we’ll know what we want to change, and we won’t be afraid to change it, because we have observability.
Responses