Grafana is relatively simple to use and intuitive. If you know how to write queries for the data source hooked to Grafana (for example, Prometheus), you already learned the most challenging part. The rest is mostly about checking boxes, choosing panel types, and arranging things on the screen. The main difficulty is to avoid being carried away by creating a bunch of flashy dashboards that do not provide much value. A common mistake is to create a graph for everything we can imagine. That only reduces the value of those that are truly important. Less is often more.

That's it. Destroy the cluster if its dedicated to this book, or keep it if it's not or if you're planning to jump to the next chapter right away. If you're keeping it, please delete the grafana Chart by executing the command that follows. If we need it in one of the next chapters, I'll make sure that it's included in the Gists.

 1  helm delete grafana --purge

Before you leave, you might want to go over the main points of this chapter.

• Looking at dashboards with graphs is a waste of time. Visiting dashboards after receiving a notification about an issue makes a bit more sense. Still, all but trivial problems require deeper digging through Prometheus metrics.
• Dashboards are not designed for us to stare at them, especially not when they are on big screens where everyone can see them.
• Semaphores are much more useful than graphs as a way to see the status of the system, even though they do not look as colorful and eye-pleasing as graphs.
• Dashboards with semaphores should be displayed on big screens around the office. They should provide an indication of a problem. Corresponding graphs (and other panels) provide a first look at the issue. Prometheus serves as the debugging tool we use to dig into metrics until we find the culprit.
• Stick with Prometheus for alerts/notifications based on metrics stored there. For other data sources, Grafana alerts might be a better or even the only option.