控制檯和儀表盤

注意從 Prometheus 3.0 開始，控制檯模板和庫不再與 Prometheus 捆綁在一起。如果您希望使用控制檯模板，必須透過指定 --web.console.templates 和 --web.console.libraries 命令列標誌來提供您自己的模板和庫。維護此文件頁面是為了提供歷史參考並展示控制檯模板的功能。請注意，來自 Prometheus 2.x 分支的任何引用控制檯庫都不再維護，並且可能包含已知的安全漏洞（CVE）。

在儀表盤上展示儘可能多的資料是很誘人的，尤其是當像 Prometheus 這樣的系統提供了對應用程式進行如此豐富的檢測能力時。這可能會導致控制檯由於資訊過多而難以看懂，甚至該系統的專家也很難從中獲取有意義的資訊。

與其試圖展示你擁有的每一項資料，不如在設計運維控制檯時，思考最可能出現的故障模式是什麼，以及你將如何使用控制檯來區分它們。利用你服務的結構優勢。例如，如果你在一個線上服務系統中有一個龐大的服務樹，那麼底層某些服務的延遲是一個典型問題。與其在單個大型儀表盤上顯示每個服務的資訊，不如為每個服務構建單獨的儀表盤，其中包括它們所呼叫的每個服務的延遲和錯誤。然後，你可以從頂部開始，逐步向下追溯到出現問題的服務。

我們發現以下指南非常有效：

• 一個控制檯上的圖表不要超過 5 個。
• 每個圖表上的曲線（線段）不要超過 5 條。如果是堆疊圖/面積圖，可以適當放寬限制。
• 使用提供的控制檯模板示例時，避免右側表格中的條目超過 20-30 個。

如果你發現自己超出了這些限制，降低較不重要資訊的可見性是有意義的，也可以將某些子系統拆分到新的控制檯中。例如，你可以繪製聚合資料而不是細分資料，將其移動到右側表格中，或者如果它很少有用，甚至可以完全刪除資料 —— 你隨時可以在表示式瀏覽器中檢視它！

最後，一套控制檯很難同時服務於多個目的。當你值班（On-call）時想知道的事情（什麼壞了？）往往與你在開發功能時想知道的事情（有多少人遇到了邊界情況 X？）大不相同。在這種情況下，準備兩套獨立的控制檯會很有用。