Once you have instrumented your application, you will need to store your data somewhere. As I mentioned in the Instrumenting an application section of this chapter, there are many possible tools you can use. I will be talking about some of the tools, but be aware that there are many others. Talk to your friends, do research online, and try different tools to figure out what is best for you, your team, and your organization.

I tend to organize monitoring tools into two buckets. This is often a simplification of these systems, but it helps me to think about how they work. These two buckets are polling applications and push applications.

Now that you are collecting your data and writing it into storage, you can start to display it to users. Many of the previously mentioned monitoring tools provide their own visualization systems. Others recommend that you bring your own. One popular open-source tool for this is Grafana.

Whatever you use to visualize and access your metrics, there are four categories of tools that people often use to get and share their data:

Let us talk about why each is useful and things to keep in mind for each of these features.

OK, now you have the basics of a monitoring system all set up. You have data flowing from your service to a datastore. You can visualize how things change over time. As you accumulate data over time, you are going to have to maintain that service. There are a few tricks for dealing with that.

The first way is a classic, tried, and true method—pay someone else to do it. There are tons of companies that sell hosted monitoring software. Datadog, Honeycomb, GrafanaCloud, InfluxCloud, Librato, Instrumental, New Relic, and many others, sell products with all sorts of features and tools where you do not have to host your monitoring tools.

Sometimes though, you do not have that kind of money, you have special security requirements, you cannot deal with the restrictions that hosted services impose, or you have some other reason not to relegate your monitoring infrastructure to someone else. In that case, first and foremost, you should monitor your monitoring...

We have talked a bit about communicating about monitoring to others throughout the chapter, but let's focus in on it for a minute. Firstly, if you have spent all this effort spinning up a monitoring system, make sure other people can access it. If you are going to go about spreading the gospel of your new monitoring system, make sure to test it. Otherwise, when you get them interested with all of your well-crafted emails, and poking and prodding, they will give up immediately if they cannot access it.

Related to the code in this chapter, the following are links to documentation for frameworks, programming languages, and other code.

Now that the metrics and logs are flowing, and people love this new system you set up, it is time to start using it for what it was meant for—waking people up at three in the morning because of an emergency.

In this chapter, we learned about a variety of tools that you can use for monitoring, plus why monitoring is useful and important.

In the next chapter, we will be talking about alerting team members about outages and how to run incident response in such a way that people will not be afraid of responding to an incident. Let's make sure that everyone will be laughing and hugging, instead of running for the doors!