看來今天終於是可以把 Grafana 的章節結束掉了，之前提到我覺得目前找到的 dashboard 不大符合我的需求，所以要來改造一下。

原本的問題

先來講講本來的設計有什麼問題。

延遲的計算

第一點是在原來的 dashboard 裡面，請求所花的時間並沒有根據錯誤與成功的請求來分開，這可能會導致我們預估錯誤，因為有些錯誤可能會因為省略了一些後續處理，例如說前端傳來的數值有誤，所以檢查的時候就直接回傳 400 了。然而又有些錯誤可能會需要花異常多的時間，例如說因為資料庫的問題而導致了 request timeout。這些極端的情形都可能會掩蓋真正的問題，因此若可以把他們分開的話會比較好。

按照 handler 分類

第二點是，把所有的 handler 的數據都顯示出來也不大合理，舉例來說當我今天 caddyfile 裡面的 block 寫成這樣，那麼依照 handler 來看他實際上會產生三個請求，依序經過 subroute、rewrite 跟 reverse_proxy，若是在統計 metric 的時候沒有考慮這些，可能造成一些誤差與雜訊。

route /api/* {
  uri strip_prefix /api
  reverse_proxy web:8080
}

有些不需要的資訊

第三點算是我個人的意見，我在原本的 dashboard 裡面有看到其中一個 panel 是在記錄 caddy_http_requests_in_flight 這項指標，表示現在某 server 同時處理的請求數量，然而我目前還沒想到我有什麼原因會需要它，所以打算刪了。

太舊了

太舊也是一個問題，去翻原本的 dashboard 會發現有一些 panel 使用的是 Graph (old) 這種 panel，而根據官方文件，它之後會被 Time series 取代掉。

改造過後的成果

我在建立 dashboard 的時候是參考了 RED method，它跟 google 提出的 golden signal 很像，RED 三個字分別代表了 Rate, Error, Duration，對應到 golden signal 就是 Traffic, Errors, Latency 三個指標，去掉 Saturation 的原因是因為 RED method 更關注在服務本身的數據，從使用者的角度去觀察，它更適合用在微服務的場合。若是需要比較詳細的介紹，我想可以參考這篇 grafana 的文章。

最後的成果長這樣，其實跟原本的也大同小異...或許吧，但至少我覺得加了漸層比較好看（？），總之把它放進正式環境跑看看一陣子，若是有問題的話到時候再看看怎麼修正吧。