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.
They can be your boss, your product team, your engineering team, your friend who runs her website on the Raspberry Pi cluster sitting in the closet of your sister's house with a fiber connection, or anyone else you think should care about your service. The first thing to do is tell them about the new monitoring system. A well-written email with example graphs, links to documentation, and your favorite dashboards goes a long way. Yet far too frequently, this is ignored. The next step is sending messages in a positive tone showing a useful graph or dashboard. An excited statement like, "Did you see how many requests the site got last month?" with a link to the graph in a text message can do wonders. This is different than the first step. The first step is education by showing that monitoring exists. The second step is integrating it with your life and showing its usefulness constantly to another employee.
Another useful tool is carrying out lightweight user studies. Take a coworker out to coffee and ask them what they think of the monitoring. Do they find it useful? Is there data they wish they had but don't know how to get? This can inform the documentation you can write for your team or get you to pair program with another engineer to help them implement a new metric in a service. Avoid just doing it for someone. Instead, figure out how to help them to help themselves. Also, make sure you share what they learn with the rest of the team. If one person has a question, very often someone else has the same question.
Note
We talk about user studies in depth in Chapter 8, User Experience.
As monitoring becomes more widely used, people may start using the monitoring system in new and exciting ways. Monitoring graphs may be used in executive summaries presented at board meetings. Developers may ask to integrate not just production data, but also to monitor data from their development environments to help debug performance issues.
Keep an eye out for new use cases, as you want to make sure the tools are performing at a level your teammates find useful. Also, this is a good time to remind you to continue to perform quarterly audits of the things you are monitoring. If you find issues with how queries are using the system, work with them to understand misconceptions and to fix bugs that might exist in their code.
Your monitoring service is just another product. This is true for all of your infrastructure. It will improve with market research, usability studies, and constant iteration based on feedback from your customers.