Grafana is a web UI for visualizing data. It can read from many data sources, including time-series databases, such as Prometheus, and relational databases, such as SQL Server. You can build dashboards in Grafana that display the health of your whole application estate, including business KPIs, application and runtime metrics, and infrastructure health.

You typically add Grafana in a containerized application to present the data from Prometheus. You run Grafana in a container too, and you can package your Docker image so that the dashboards, user accounts, and database connections are built-in. I've done that for the final part of this chapter, in the dockeronwindows/ch11-grafana:2e image. The Grafana team don't publish a Windows image on Docker Hub, so my Dockerfile starts from a sample image and adds in all the configuration for my setup:

# escape=`
FROM dockersamples/aspnet-monitoring-grafana:5.2.1-windowsservercore-ltsc2019
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]

COPY datasource-prometheus.yaml grafanaconfprovisioningdatasources
COPY dashboard-provider.yaml grafanaconfprovisioningdashboards
COPY dashboard.json varlibgrafanadashboards

COPY init.ps1 .
RUN .init.ps1 

Grafana has two approaches to automating deployment. The first just uses files in known locations, which I use to set up the Prometheus data source, the dashboard, and the dashboard provider, which just points Grafana to a directory for dashboards. The second uses a REST API for authentication and authorization, and my init.ps1 script uses that to create a read-only user with access to the dashboard.

It's simple to create your own dashboards with Grafana. You create a panel for a particular type of visualization—numbers, graphs, heatmaps, traffic lights, and tables are all supported. Then, you connect the panel to a data source and specify the query. Typically, you'd use the Prometheus UI to fine-tune the query and then add it to Grafana. To save time, my image comes with a ready-made dashboard.

I'll start the monitoring solution with the Docker Compose file in the ch11 folder, then browse to the API and the website to generate some traffic. Now, I can browse to Grafana and log in with the username viewer and password readonly, and I'll see the dashboard:

This is just a sample dashboard, but it gives you an idea about how much information you can present. I have a row for the REST API, showing a breakdown of HTTP requests and responses, and an overall view of the CPU usage. I also have a row for NerdDinner, showing performance metrics from IIS and headline statistics for cache usage.

You can add instrumentation to all your applications with very little effort and build a detailed dashboard to give you insight into what's happening in your solution. What's more, you can have the exact same monitoring facility in every environment, so in development and test you can see the same metrics that you use in production. This is very useful in tracking down performance issues. Developers can add a new metric and visualization for a performance problem, fix the problem, and when the change goes live, it will include the new metric that can be tracked in production.

The last thing I'll cover in this chapter is how to approach fixing bugs in Docker, and how containerization makes it so much easier.