Create Grafana dashboard for platform health — lab audio overview

Host: Welcome back to the AI Developer Platform Engineering course. You're in the chapter on Internal Developer Platform Vision — which is a fancy way of saying, how do you design the system that your own developers use to ship software? This discipline matters because the platform your team builds is the foundation every other team depends on. And today's skill — watching the health of that platform in real time — is the difference between knowing something is wrong and finding out from an angry user. Expert: Picture this. You're on a platform engineering team at a mid-sized company — maybe fifty engineers, a few hundred microservices, all running on top of infrastructure your team provides. It's Tuesday afternoon. Deploys are flowing, services are being created, everything seems fine. Then your phone starts buzzing. Three different product teams are saying their new services won't come up. Requests are timing out. Nobody knows why. You open a terminal, start grepping through logs, and twenty minutes later you finally spot it — one of your provisioning services has been quietly failing for the last half hour. Twenty minutes of blind panic, when the information was sitting there the whole time. That's the scenario this exercise fixes. Every serious platform team solves this the same way — they build a live visual dashboard, a single screen on the wall that shows the heartbeat of the platform. Request volume, error rates, how slow things are, how many services are alive. When something goes wrong, you see it immediately, in color, on a chart. That's what you're about to build. Host: In the previous exercise, you built the part of the system that measures how long provisioning operations take — tracking not just averages but the slow outliers, the worst one-percent experiences. Now you're taking all those numbers and turning them into something a human can actually look at. So what exactly are we building? Expert: You're going to build a live dashboard — a web page full of charts and numbers — that shows the health of your platform at a glance. The tool we'll use is called Grafana. Grafana is an open-source dashboarding tool — think of it as a drawing program for graphs, except the graphs are fed by live data from your running systems. It reads numbers from a metrics database called Prometheus, which is the tool that's been collecting all those counters and timings you built in the first two exercises. So Grafana is the face, Prometheus is the memory. Here's the key idea, and this is the thing that surprises people. You are NOT going to build this dashboard by clicking around in a web interface. You're going to build it as code — a text file that describes every chart, every number, every color. That text file gets checked into version control, reviewed by your teammates, and deployed just like any other piece of software. The industry term for this is dashboards-as-code. Why does this matter? Because a dashboard that lives only inside someone's browser tab is a dashboard that disappears when that person leaves the company. A dashboard defined in a file is a permanent part of your platform. You'll define four things on this dashboard — how many requests per second are flowing in, what percentage of them are failing, how slow the slow ones are, and how many services are currently running. Host: Okay, so before they start — what's the part that trips people up? Expert: The queries. Grafana doesn't magically know what to draw. For each chart, you have to write a small query — a little snippet of a query language called PromQL, which stands for Prometheus Query Language. And PromQL thinks differently from regular databases. Instead of asking "what is the value right now," you're almost always asking "what is the rate of change over the last few minutes." So for request rate, you don't ask for the counter's current value — you ask how fast the counter is going up. For error rate, you ask for the ratio of two rates. The tip here is — start simple. Get one panel showing one number correctly before you try to build all four. If your chart is empty or flat, the problem is almost always the query, not the dashboard. Host: And last thing — what will they walk away being able to do, and where does this land in the bigger picture? Expert: After this exercise, you'll be able to take any platform you're running and give it a live health display — something your team can glance at during an incident and know within five seconds whether things are healthy. You'll know how to define those displays as code, so they live in your repository and get reviewed like anything else. For your team, this is a foundational capability. The dashboard you build here is the kind of artifact that becomes the centerpiece of your operations review, your on-call handoff, your status page. And since this is the final exercise in this objective, here's where you've landed. Across three exercises, you instrumented your platform with counters, you added detailed timing histograms, and now you're visualizing all of it. You now have the complete observability story for an internal developer platform — something you can bring straight into your team's architecture discussions. Thanks for listening, and good luck with the build.