关于构建监控系统的一点感想（二）：可用性监控

发表于 阅读次数： Waline： 本文字数： 1.8k 阅读时长 ≈ 6 分钟
掌握系统延迟监控的关键技巧。详细对比Blackbox探测和负载均衡器日志方法,分析优缺点。介绍时间轴平均值、百分位分析和功能模块细分三大使用维度。提供实用PromQL示例和可视化建议,助您优化系统性能,提升监控精度。适合IT团队和技术人员参考的实用指南。 Cop

前面一篇笔记写了一点关于构建监控系统的想法，今天详细记录一下里面提到的关于系统“可用性”的监控。

系统可用性监控主要有三种实施方法： 1. 通过对日志解析和分析做 2. 通过外部黑盒系统做 3. 在开发的阶段就开发相应的功能。下面一个一个具体说一下。

通过日志做可用性监控

这种方法总得来说上手最简单。但是也有明显的缺陷。

实施方法

这里假设被监控系统有比较完善的日志。以下就以nginx日志为例，其他类的也行，比如apache，或者一些公有云厂商的负载均衡器日志等等都行。

以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" "-"

里面的字段就不做详细解释了，网上有很多关于Nginx日志配置的资料。
我们只看三个需要的字段：

  • 时间：有了这个字段，我们就可以把日志解析后按照时间存储起来，分析的时候也可以按照时间来划分不同的时间段 。 样例日志中时间是这样的： [19/Aug/2021:09:12:07 +0000]
  • 请求路径： 请求路径一般就对应着系统中的一个功能，这个字段可以帮我们区分不同的功能， 比如样例日志中可以看出来这是登录功能： “GET /user/login”
  • 状态码： 状态码可以告诉我们每一次请求是成功的还是失败的。样例日志中状态码是200，表示请求成功。

讲到这里想来应该能够理解怎么样通过日志进行可用性监控了，具体的实施方法其实有很多。
比如，如果是nginx或者apache，可以采用prometheus对应的exporter做监控，这是最简单的；
如果是自开发的日志系统，可以考虑把日志解析后存入ElasticSearch，然后通过Kibana或者Grafana做分析；
如果是公有云的负载均衡器，一般公有云都提供了完善的日志解析和分析方案，可以直接使用；另外，公有云一般都有相对完善的监控服务，能够满足大部分一般需求。

缺陷

可以看到，通过日志做可用性监控还是比较简单的，最容易出成果，但是也有明显的缺陷：
1. 对被监控的对象有侵入性
如果被监控对象的日志正好符合我们的需求，那么问题可能不大，但是如果日志不符合我们的要求，这个时候就要要求应用团队或者开发团队修改相应的配置或者代码来产生这些日志，这在大的团队里面可能会带来的很大的沟通成本，而且对应用本身也确实有一定的侵入性。

2. 不可靠性
我们设想一个场景。
假设我们的后端服务是通过一台Nginx做负载均衡或者请求转发，Nginx背后是一台Web Server。当Nginx正常工作、正常产生日志的时候，我们这个方案是没有问题的。但是如果Nginx本身挂了或者这台服务器死机了，不能产生日志了，这个时候就有问题了。

因为没有新的日志产生，不论用Prometheus监控还是ElasticSearch分析，我们都不能从数据中发现问题，这个时候就等于没有监控了，我们也不知道是出问题了，还是说就是单纯地没有日志产生。

而且也会对计算SLO产生影响。比如我们要计算过去一天 可用性 这个SLO，但是由于其中一个小时Nginx宕机没有产生日志，这个时候就没办法进行计算了，

通过外部黑盒系统做可用性监控

简单来说就是在被监控对象之外模拟真实用户的行为去使用被监控系统。

比如，我要监控一个web应用的登录功能，我就写一个脚本定期去登录这个web。

实施方法

目前我尝试过的方法有两个：一个是利用BlackBox做探测，第二个就是自己写代码实现

1. BlackBox探测
blackbox exporter 简介
blackbox github地址

关于blackbox详细的内容和配置这里推荐两篇资料，有需要的可以详细看一下。

我简单说一下blackbox适合哪些场景。
blackbox可以通过HTTP、DNS、ICMP等协议进行探测，所以最适合一些简单功能的黑盒监控，比如某一个web应用的登录功能的可用性监控，并且配置简单，上手容易。
但是这也成了它的缺点，因为blackbox只能通过HTTP等协议经常探测， 所以只能进行简单、单一的功能的可用性监控，对于比较复杂的功能往往就无能为力了。

2. 自己写代码模仿用户行为实现可用性监控
这种方法也很容易理解，还是以监控web的登录功能为例，除了使用blackbox，也可以自己写代码操控浏览器输入账号密码来实现。
以我目前的经验来看，通过对功能的拆分，可以利用blackbox完成很多可用性监控，这个时候就已经能看到一定的成果了，但是也确实有一些功能只能通过自己写代码模拟用户行为来实现。这么做就是成本有点高，要考虑投入产出比。

在系统开发阶段就设计好监控的需求并开发

这是最理想的方案，但是也是最难的方案。

这个方案目前还没有实际在项目中做过，没有经验可谈，只记录一些思考。

  1. 方案的设计
    这个方案有两种可能的实现路径，一是通过日志实现，比如在web的登录模块添加一个记录日志的功能，每次发生登录行为的时候就记录一条日志；二是在系统中开发一个自带的exporter，可以让Pormetheus来获取数据。
  2. 难点
    这个方案的难点不在于技术，而在于人。尤其是产品经理。
    因为一般产品经理追求的是对用户有用的功能上的快速迭代，不注重后期运维的需求，尤其是在产品开发的初期，更是不太会考虑这些。但是等到产品变得很完善，代码量很大之后，想要再回头去添加监控的功能就很难了。