在仪表盘上显示尽可能多的数据可能很诱人，尤其是在像 Prometheus 这样的系统能够对你的应用程序进行如此丰富的仪表化时。这可能会导致控制台因信息过多而难以理解，即使是系统专家也很难从中得出意义。
与其尝试表示你拥有的每一条数据，不如为操作控制台考虑最可能的故障模式，以及你将如何使用控制台来区分它们。利用你服务的结构。例如，如果你在在线服务系统中有庞大的服务树，则某些较低服务的延迟是一个典型问题。与其在单个大型仪表盘上显示每个服务的信息，不如为每个服务构建单独的仪表盘，其中包含它们与之通信的每个服务的延迟和错误。然后，你可以从顶部开始，向下找到有问题的服务。
我们发现以下准则非常有效：
如果你发现自己超过了这些限制，那么可以考虑降低不太重要的信息的可见性，可能会将一些子系统拆分到新的控制台。 例如，你可以绘制聚合而非分解的数据，将其移动到右侧表格，或者甚至完全删除数据（如果它很少有用） - 你始终可以在表达式浏览器中查看它！
最后，一组控制台很难服务于多个主人。 当你值班时（哪里坏了？）想知道的东西，往往与你开发功能时（有多少人遇到了 X 的极端情况？）想要的东西非常不同。 在这种情况下，两组独立的控制台可能很有用。
此文档是开源的。请通过提交问题或拉取请求来帮助改进它。