Day 16：架设 Grafana (2)

看来今天终於是可以把 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 的文章。

最後的成果长这样，其实跟原本的也大同小异...或许吧，但至少我觉得加了渐层比较好看（？），总之把它放进正式环境跑看看一阵子，若是有问题的话到时候再看看怎麽修正吧。