控制台与仪表板

注意从 Prometheus 3.0 开始，控制台模板和库不再内置于 Prometheus 中。如果您希望使用控制台模板，必须通过指定 --web.console.templates 和 --web.console.libraries 命令行标志来提供您自己的模板和库。本说明文档仅作为历史参考，旨在展示控制台模板的功能。请注意，来自 Prometheus 2.x 分支的任何参考控制台库均不再维护，并可能包含已知的安全漏洞 (CVE)。

当看到 Prometheus 能够为您的应用程序提供如此丰富的仪表化数据时，可能会诱使您在仪表板上显示尽可能多的数据。这可能会导致控制台由于包含过多信息而变得难以理解，即使是系统专家也难以从中提取有意义的信息。

对于运维控制台，不要试图展示您拥有的每一条数据，而应思考最可能的故障模式是什么，以及您将如何使用控制台来区分它们。充分利用服务的结构。例如，如果您在在线服务系统中拥有一个庞大的服务树，那么某个底层服务的延迟就是一个典型问题。与其在单一的大仪表板上显示每个服务的信息，不如为每个服务构建单独的仪表板，其中包含它们所交互的每个服务的延迟和错误信息。这样，您就可以从顶部开始，一路向下追踪到有问题的服务。

我们发现以下准则非常有效：

• 一个控制台上的图表数量不超过 5 个。
• 每个图表上的数据序列（线条）数量不超过 5 条。如果是堆叠/区域图，可以适当放宽限制。
• 使用所提供的控制台模板示例时，右侧表格中的条目数尽量不要超过 20-30 个。

如果您发现超出了这些限制，则有必要降低不太重要信息的可见性，或者将一些子系统拆分到新的控制台中。例如，您可以对聚合数据而非细分数据进行绘图，将其移至右侧表格，如果某项数据很少有用，甚至可以将其完全删除——您可以随时在表达式浏览器中查看它！

最后，一套控制台很难同时满足多种需求。当您处于值班（oncall）状态时，想要了解的信息（什么坏了？）往往与开发功能时（有多少人遇到了极端情况 X？）的需求大相径庭。在这种情况下，构建两套独立的控制台会很有帮助。