将尽可能多的数据展示在仪表盘上可能很诱人，尤其是当像 Prometheus 这样的系统能够为你的应用程序提供如此丰富的埋点能力时。但这可能会导致控制台因信息过多而难以理解，即使是系统专家也难以从中提取有意义的信息。
不要试图呈现你拥有的所有数据，对于运维控制台，请思考最可能的故障模式以及如何使用控制台来区分它们。利用你的服务结构。例如，如果你的在线服务系统中有一个庞大的服务树，那么某个下层服务的延迟是一个典型问题。与其在一个大型仪表盘上显示所有服务的信息，不如为每个服务构建单独的仪表盘，其中包含它们与之交互的每个服务的延迟和错误。然后你可以从顶层开始，向下追溯到有问题服务。
我们发现以下指导原则非常有效
如果你发现自己超出了这些限制，那么降低不太重要信息的可见性可能是有意义的，或者将某些子系统分拆到新的控制台。例如，你可以绘制聚合数据而不是分解数据，将其移至右侧表格，或者如果它很少有用，甚至可以完全删除数据——你始终可以在表达式浏览器中查看它！
最后，一套控制台很难服务于多种目的。值班时你想知道的信息（什么坏了？）与开发功能时你想知道的信息（有多少人遇到边缘情况 X？）往往截然不同。在这种情况下，两套独立的控制台可能很有用。
本文档是开源的。请通过提交 issues 或 pull requests 来帮助改进它。