控制台和仪表盘

将尽可能多的数据展示在仪表盘上可能很诱人,尤其是当像 Prometheus 这样的系统能够为你的应用程序提供如此丰富的埋点能力时。但这可能会导致控制台因信息过多而难以理解,即使是系统专家也难以从中提取有意义的信息。

不要试图呈现你拥有的所有数据,对于运维控制台,请思考最可能的故障模式以及如何使用控制台来区分它们。利用你的服务结构。例如,如果你的在线服务系统中有一个庞大的服务树,那么某个下层服务的延迟是一个典型问题。与其在一个大型仪表盘上显示所有服务的信息,不如为每个服务构建单独的仪表盘,其中包含它们与之交互的每个服务的延迟和错误。然后你可以从顶层开始,向下追溯到有问题服务。

我们发现以下指导原则非常有效

  • 一个控制台上最多不要超过 5 个图表。
  • 每个图表上最多不要超过 5 条曲线。如果是堆叠图/面积图,可以适当增加。
  • 使用提供的控制台模板示例时,右侧表格中的条目不要超过 20-30 个。

如果你发现自己超出了这些限制,那么降低不太重要信息的可见性可能是有意义的,或者将某些子系统分拆到新的控制台。例如,你可以绘制聚合数据而不是分解数据,将其移至右侧表格,或者如果它很少有用,甚至可以完全删除数据——你始终可以在表达式浏览器中查看它!

最后,一套控制台很难服务于多种目的。值班时你想知道的信息(什么坏了?)与开发功能时你想知道的信息(有多少人遇到边缘情况 X?)往往截然不同。在这种情况下,两套独立的控制台可能很有用。

本文档是开源的。请通过提交 issues 或 pull requests 来帮助改进它。