关于构建监控系统的一点感想（三）：监控延迟

发表于 2021-11-18 阅读次数： Waline：本文字数： 1.6k 阅读时长 ≈ 6 分钟

监控系统的4个黄金指标详解：延迟、流量、错误、饱和度，及其应用注意事项，帮助您全面提升系统性能和用户体验。

所谓“延迟”其实就是指响应时间，比如一个web页面的响应时间，一个api接口的响应时间等等。

这篇笔记分如何实施和如何使用两部分来讲关于延迟的监控。

笔记中不会写实施的详细的步骤，因为这样的内容网上非常多，更多的是记录在使用中一点感想和建议，如果读者正好也在做类似的事情，可能会在思路上能够提供一点点的帮助

监控延迟的实施方法

实施方法主要有两种，一是通过blackbox做探测，二是通过负载均衡器或者日志获取延迟相关的数据来做监控。

通过blackbox监控系统延迟

在介绍通过blackbox做可用性监控的时候详细的介绍过blackbox，这里不再做赘述。

简单来说，blackbox可以探测一个具体的链接，然后返回状态码和响应时间，其中的响应时间就可以用来监控延迟。

这里写一个样例PromQL做参考：

avg(probe_http_duration_seconds{job="baidu",instance="www.baidu.com"})

具体的语法我这里不做解释，如果不会的话可以看看文末推荐的《Prometheus中文文档》。

我想说的是，blackbox做探测时获取到的“耗时”其实有5种（也就是5个阶段），分别是connect、processing、resolve、tls和transfer，如图：

在上面的PromeQL中，我在最前面加上了avg，也就是对着五种时间做平均，严格来说这么做不错误的，因为这会弱化单独每一项的异常，但是由于真正看dashboard的人不是很懂监控相关的内容，如果我把每一种数据都在dashboard上展示出来，图就会变得有点乱，不便于理解；不过我在做告警的时候还是针对每一项单独做的，这样可以保证任何一个阶段的延迟变长时都能被检测到

优点
这种方法的优点就是上手简单，通过一些简单的配置就能实现延迟监控
缺点
缺点跟可用性监控里面也一样，通过blackbox做的探测会额外增加系统的负载，并且很难得到系统全部的api（或者web页面）的延迟数据

通过负载均衡器的日志监控系统延迟

在介绍可用性监控的时候也提到过通过Nginx实现的方法，这里在实施方法上其实和可用性监控是一样的。不再赘述。

依然以Nginx为例，一下是样例日志

10.10.10.10 - username [19/Aug/2021:09:12:07 +0000] "GET /user/login" 200 459 "https://10.132.52.62/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36" "-"

日志中的“459”其实就是这个请求的响应时间，也就是所谓的延迟，只要有了这个数据，Nginx Exporter会帮我们进行解析，剩下的就是如何制作dashboard和使用的问题了。

其实关于延迟监控还有一种方法就是项目在写代码的时候就考虑这个事情，这是最完美的，但是也是最难的，因为产品经理和开发人员一般都是以业务需求为首要工作，很难把监控这样一个需求排进开发档期。

如何使用延迟监控

团队构建监控系统说到底是为了使用它，而不只是为了做一张dashboard看看那么简单（虽然制作漂亮的dashboard也非常重要）。

关于延迟的使用有三个维度：按时间轴查看平均值，查看百分位，按照系统功能模块查看。

按照时间轴查看延迟的平均值

这个维度其实在上面的blackbox做延迟监控里面提到了，就是将所有的延迟都加起来然后求平均值，再按照时间轴做dashboard。

这么做的优点是简单、直观、可以看出在整站延迟情况。尤其是当需要向不是很懂技术的人展示系统的整体运行情况的时候，这样的dashboard就很有用。

但是缺点就是当某一个api或者页面的延迟升高时，在这样的dashboard上表现不出来，只有当全站都出现问题的时候才能看出问题。因为这里会把所有的数据相加再求平均。比如，一个系统一共有200api，现在登录api延迟变为原来的10倍，这其实已经非常严重了，但是由于一共有200api，登录接口延迟对全站的影响为1 / 200 * 10 = 1/20, 这样的变化是很难观查出来的。

按照百分位查看延迟

所谓“百分位”，就是当前有多少请求的延迟低于某一个数值。比如，90%请求的延迟低于100ms, 95%请求的延迟低于200ms，99%请求的延迟低于1s等等

这么做可以有效避免“长尾效应”带来的误导。比如99%的请求都低于100ms，但是剩余1%请求的延迟是10s，这个时候就可以知道绝大部分的请求都是正常的，但是有一小部分的请求非常规律性地异常，可以针对性地对这些请求做优化。

这里放一张k8s nginx ingress上请求延迟的百分位截图。
图中，左边第一列是百分位，第二列是服务名（被我涂掉了），右边依次是最小值，最大值和平均值。

按照系统的功能查看延迟

这一点其实也很好理解，就和前面提到的可用性监控一样，如果把全站的数据都放在一起看，只能看到全站的整体情况，如果某一个子功能或者api出了问题我们是不知道的。所以对于一些比较关键的模块或者api应该但是做dashboard和告警。

这里还是以通过Nginx和Nginx exporter做延迟监控为例，Nginx日志中的请求路径一般就可以用于区分不同的模块和api。