想吃透监控系统，就这一篇够不够?

2021-02-13 分类：网站建设

经济高速发展的今天，我们处于信息大爆炸的时代。随着经济发展，信息借助互联网的力量在全球自由地流动，于是就催生了各种各样的服务平台和软件系统。

图片来自 Pexels

由于业务的多样性，这些平台和系统也变得异常的复杂。如何对其进行监控和维护是我们 IT 人需要面对的重要问题。就在这样一个纷繁复杂地环境下，监控系统粉墨登场了。

今天，我们会对 IT 监控系统进行介绍，包括其功能，分类，分层;同时也会介绍几款流行的监控平台。

监控系统的功能

在 IT 运维过程中，常遇到这样的情况：

某个业务模块出现问题，运维人员并不知道，发现的时候问题已经很严重了。
系统出现瓶颈了，CPU 占用持续升高，内存不足，磁盘被写满;网络请求突增，超出网关承受的压力。

以上这些问题一旦发生，会对我们的业务产生巨大的影响。因此，每个公司或者 IT 团队都会针对此类情况建立自己的 IT 监控系统。

Java 代码运行原理图

在介绍这种方式之前，我们先来复习一下 Java 代码运行的原理。通常我们会把 Java 源代码，通过“Java 编译器”编译成 Class 文件。再把这个 Class 的字节码文件装载到“类装载器”中进行字节码的验证。

最后，把验证过后的字节码发送到“Java 解释器”和“及时编译器”交给“Java 运行系统”运行。

Java 探针，字节码增强的方式就是利用 Java 代理，这个代理是运行方法之前的拦截器。

在 JVM 加载 Class 二进制文件的时候，利用 ASM 动态的修改加载的 Class 文件，在监控的方法前后添加需要监控的内容。

例如：添加计时语句，用于记录方法耗时。将方法耗时存入处理器，利用栈先特性(先进后出)处理方法调用顺序。

每当请求处理结束后，将耗时方法和入参 map 输出到文件中，然后根据 map 中相应参数，区分出耗时业务。

最后将相应耗时文件取下来，转化为 xml 格式并进行解析，通过浏览器将代码分层结构展示出来。

时序数据库数据模型图例

时序数据库的存储原理，关系型数据库存储采用的是 B tree，虽然降低了数据查询的磁盘寻道时间，但是无法解决大量数据写入时的磁盘效率。

由于监控系统的应用场景，经常会遇到大批量的数据写入，所以我们会选择 LSMtree(Log Structured Merge Tree)存储时序数据库。

LSMtree(Log Structured Merge Tree)，从字面意义上理解，记录的数据按照日志结构(Log Structured)追加到系统中，然后通过合并树(Merge Tree)的方式将其合并。

来看一个 LevelDB 的例子，方便我们理解，LSM-tree 被分成三种文件：

接收写入请求的 memtable 文件(内存中)
不可修改的 immutable memtable 文件(内存中)
磁盘上的 SStable文件(Sorted String Table)，有序字符串表，这个有序的字符串就是数据的key。SStable 一共有七层(L0 到 L6)。下一层的总大小限制是上一层的 10 倍。

LSMtree LevelDB 存储示意图

LSMtree 写入流程：

将数据追加到日志 WAL(Write Ahead Log)中，写入日志的目的是为了防止内存数据丢失，可以及时恢复。
把数据写到 memtable 中。
当 memtable 满了(超过一定阀值)，就将这个 memtable 转入 immutable memtable 中，用新的 memtable 接收新的数据请求。
immutablememtable 一旦写满了，就写入磁盘。并且先存储 L0 层的 SSTable 磁盘文件，此时还不需要做文件的合并。

每层的所有文件总大小是有限制的(8MB，10MB，100MB… 1TB)。从 L1 层往后，每下一层容量增大十倍。

某一层的数据文件总量超过阈值，就在这一层中选择一个文件和下一层的文件进行合并。

如此这般上层的数据都是较新的数据，查询可以从上层开始查找，依次往下，并且这些数据都是按照时间序列存放的。

监控系统的分层

谈完了监控系统的分类，再来聊聊监控系统的分层。用户请求到数据返回，经历系统中的层层关卡。

监控系统分层示意图

一般我们将监控系统分为五层来考虑，当然也有人分成三层，大致的意思都差不多，仅供参考：

客户端监控，用户行为信息，业务返回码，客户端性能，运营商，版本，操作系统等。

业务层监控，核心业务的监控，例如：登录，注册，下单，支付等等。

应用层监控，相关的技术参数，例如：URL 请求次数，Service 请求数量，SQL 执行的结果，Cache 的利用率，QPS 等等。

系统层监控，物理

Zabbix 的部署模式

Zabbix 的数据采集，主要有两种模式：Server 主动拉取数据和 Agent 主动上报数据。

以 Server 拉取数据为例，用户在 Web-portal 中，设置需要监控的机器，配置监控项，告警策略。Zabbix-Server 会根据策略主动获取 Agent 的数据，然后存储到 MySQL 中。

同时根据用户配置的策略，判定是否需要告警。用户可以在 Web 端，以图表的形式，查看各种指标的历史趋势。

在 Zabbix 中，将 Server 主动拉取数据的方式称之为 Active Check。这种方式配置起来较为方便，但是会对 Zabbix-Server 的性能存在影响。

所以在生产环境中，一般会选择主动推送数据到 Zabbix-Server 的方式，称之为 Trapper。

即用户可以定时生成数据，再按照 Zabbix 定义的数据格式，批量发送给 Zabbix-Server，这样可以大大提高 Server 的处理能力。

Proxy，作为可选项，起到收集 Agent 数据并且转发到 Server 的作用。

当 Server 和 Agent 不在一个网络内，就需要使用 Proxy 做远程监控，特别是远程网络有防火墙的时候。同时它也可以分担 Server 的压力，降低 Server 处理连接数的开销。

Prometheus(普罗米修斯)

随着这几年云环境的发展，Prometheus 被广泛地认可。它的本质是时间序列数据库，而 Zabbix 采用 MySQL 进行数据存储。

从上面我们对时间序列数据库的分析来看，Prometheus 能够很好地支持大量数据的写入。

它采用拉的模式(Pull)从应用中拉取数据，并通过 Alert 模块实现监控预警。据说单机可以消费百万级时间序列。

一起来看看 Prometheus 的几大组件：

Prometheus Server，用于收集和存储时间序列数据，负责监控数据的获取，存储以及查询。
监控目标配置，Prometheus Server 可以通过静态配置管理监控目标，也可以配合 Service Discovery(K8s，DNS，Consul)实现动态管理监控目标。
监控目标存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列存储在本地磁盘中。
监控数据查询，Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。
Client Library，客户端库。为需要监控的服务生成相应的 Metrics 并暴露给 Prometheus Server。
当 Prometheus Server 来 Pull 时，直接返回实时状态的 Metrics。通常会和 Job 一起合作。
Push Gateway，主要用于短期的 Jobs。由于这类 Jobs 存在时间较短，可能在 Prometheus 来 Pull 之前就消失了。为此，这些 Jobs 可以直接向 Prometheus Server 端推送它们的 Metrics。
Exporters，第三方服务接口。将 Metrics(数据集合)发送给 Prometheus。
Exporter 将监控数据采集的端点，通过 HTTP 的形式暴露给 Prometheus Server，使其通过 Endpoint 端点获取监控数据。
Alertmanager，从 Prometheus Server 端接收到 Alerts 后，会对数据进行处理。例如：去重，分组，然后根据规则，发出报警。
Web UI，Prometheus Server 内置的 Express Browser UI，通过 PromQL 实现数据的查询以及可视化。

Prometheus 架构图

说完了 Prometheus 的组件，再来看看 Prometheus 的架构：

Prometheus Server 定期从 Jobs/Exporters 中拉 Metrics。同时也可以接收来自 Pushgateway 发过来的 Metrics。
Prometheus Server 将接受到的数据存储在本地时序数据库，并运行已定义好的 alert.rules(告警规则)，一旦满足告警规则就会向 Alertmanager 推送警报。
Alertmanager 根据配置文件，对接收到的警报进行处理，例如：发出邮件告警，或者借助第三方组件进行告警。
WebUI/Grafana/APIclients，可以借助 PromQL 对监控数据进行查询。

最后将两个工具进行比较如下：

Zabbix 和 Prometheus 比较图

从上面的比较可以看出：

Zabbix 的成熟度更高，上手更快。高集成度导致灵活性较差，在监控复杂度增加后，定制难度会升高。而且使用的关系型数据库，对于大规模的监控数据插入和查询是个问题。
Prometheus 上手难度大，定制灵活度高，有较多数据聚合的可能，而且有时序数据库的加持。
对于监控物理机或者监控环境相对稳定的情况，Zabbix 有明显优势。如果监控场景多是云环境的话，推荐使用 Prometheus。

总结