你知道监控吗(这样的监控)

[51CTO.com原稿]在经济高速发展的今天，我们正处于信息爆炸的时代。随着经济的发展，信息借助互联网的力量在世界范围内自由流动，从而诞生了各种服务平台和软件系统。
图片来自Pexels由于业务的多样性，这些平台和系统变得异常复杂。如何监控和维护，是我们武汉it日日夜夜需要面对的重要问题。在这样复杂的环境下，监控系统出现了。今天，我们将介绍IT监控系统，包括其功能、分类和分层；同时，还将介绍几个流行的监控平台。监控系统的功能在IT运维过程中，经常会遇到这样的情况：
某个业务模块出了问题，运维人员不知道。发现的时候问题已经很严重了。系统出现瓶颈，CPU使用率持续上升，内存不足，磁盘已满；网络请求的突然增加超过了网关的压力。这些问题一旦发生，将对我们的业务产生巨大影响。因此，每个公司或IT团队都会针对此类情况建立自己的IT监控系统。
监控系统流程图的功能包括：
实时监控服务、系统和平台的运行状态。收集服务、系统和平台的运行信息。通过收集信息的分析结果，预测存在的失效风险并采取措施。根据风险评估，给出失败的预警。一旦出现故障，会在第一时间发出报警信息。通过监控数据、定位故障和帮助制定解决方案。最终使系统能够持续、稳定、安全地运行。监测数据可视化方便统计，按照一定周期导出存档，用于数据分析和问题恢复。监控系统的分类由于监控系统对我们来说意义重大，所以根据不同的场景将监控系统分为三类，即：
类调用链类度量类日志类通常我们在系统和业务层面添加一些日志代码来记录一些日志信息，方便我们发现问题的时候发现问题。这些信息将与事件相关，如用户登录、下订单、用户浏览产品、一小时内的网关流量、用户平均响应时间等。这个类中有许多日志和查询的解决方案。例如，ELK scheme(elastic search Logstash Kibana)使用ELK(Elasticsearch，Logstash，Kibana) Kafka/Redis/RabbitMQ构建日志系统。
ELK结合Redis/Kafka/RabbitMQ通过Spring AOP实现登录日志监控程序。Beats收集日志文件，然后用Kafka/Redis/RabbitMQ发送到Logstash，Logstash将日志写入Elasticsearch。最后，使用Kibana将存储在Elasticsearch中的日志数据以实时数据图的形式显示出来。呼叫链类是针对服务较多的系统，尤其是微服务系统。一个服务调用可能涉及多个服务。a调用，调用C，像一个链条，形成一个服务调用链。呼叫链是通过所有服务记录请求的过程。请求从开始进入服务，经过不同的服务节点，然后返回客户端，通过调用链参数跟踪整个链接行为。以便知道请求失败在哪里，系统的瓶颈在哪里。调用链监控的实现原理如下：Java探针，字节码增强
Java代码运行示意图在介绍这个方法之前，我们先来回顾一下Java代码运行的原理。通常，我们通过“Java编译器”将Java源代码编译成一个类文件。然后将这个类的字节码文件加载到“类加载器”中来验证字节码。最后，经过验证的字节码被发送到Java解释器和即时编译器，它们被交给Java运行系统。Java probe，字节码增强的方式是使用Java proxy，它是运行方法之前的拦截器。JVM加载类二进制文件时，使用ASM动态修改加载的类文件，在监控方法前后添加要监控的内容。例如，添加一个计时语句来记录方法的时间消耗。方法时间存储在处理器中，方法的调用序列由堆栈优先特性(先进后出)处理。每次处理请求时，将耗时方法和参数映射输出到文件中，然后根据映射中对应的参数区分耗时服务。最后把对应的耗时文件取下来，转换成xml格式并解析，通过浏览器显示代码层次结构。
Java探针工具示意图备注：ASM是一个Java字节码操纵框架，可以动态生成类或者增强现有类的功能。ASM可以直接生成二进制类文件，并且可以在类被加载到Java虚拟机之前改变类的行为。Java类存储在。类文件，其中包含解析类中元素的元数据：类名、方法、属性和Java字节码(指令)。从ASM类文件中读取信息后，它可以改变类行为，分析类信息，甚至生成新的类。拦截请求，获取每个请求服务中的信息，实现跟踪。这里以Zipkin Slueth为例说明其原理。Sleuth提供链接跟踪。由于请求涉及多个服务的相互调用，这通常是一个链式结构，请求只有在重复调用后才会返回。Sleuth常用来跟踪整个调用过程，方便梳理服务之间的调用关系。
Sleuth服务调用跟踪图例为每个请求生成一个跟踪ID。如上图所示，无论传递多少个服务，这个Trace ID在请求和响应的全过程中都会保持一致。这是为了方便记录呼叫的整个生命周期。听着，每次请求都会有一个Span ID。这里的跨度是Sleuth service跟踪的最小单位。每次传递一个服务，请求和响应的值都会不一样。这是为了区分不同的调用动作。对于调用的每个动作，Sleuth都做了如下标记：
Server Received表示服务器接受，即服务器收到请求。Client Sent是客户端发送的，即服务本身不提供响应，需要调用其他服务来提供响应，所以此时请求是作为客户端发起的。服务器发送是由服务器发送的。如上图所示，侏罗纪世界3收到请求后，由于他是最终的服务提供者，需要作为服务器将请求发送给调用者。Client Received由客户端接受，作为调用客户端接收服务器返回的请求。实际上，Sleuth以上述方式为每个请求记录了一个统一的Trace ID，每个请求的详细步骤被记录为Span ID。每次发起或接收请求时，分别记录服务器接收、客户端发送、服务器发送、客户端接收四种状态，完成对这个服务调用链路的跟踪。
Sleuth服务调用跟踪图例每个被调用的服务节点将通过服务被调用的链路上的父ID记录调用服务的Span ID。因为Span ID是唯一标识最小服务单元的ID，所以知道父服务单元的Span ID就能知道是谁调用了自己。类实现了TimeSeriesData (TSD)的监控方案。其实就是用时间维度记录一系列数据，然后通过聚合运算，查看指标数据和指标趋势。说白了就是描述某一个主体在一段时间内测量值的变化(测量)。由于IT基础设施、运维监控和互联网监控的特点，这种方法被广泛使用。时间序列数据的建模一般分为三个部分，即主体、时间点和测量值。让我们看看这个例子。例如，时间序列数据库的数学模型需要监控服务器的平均进出流量：
整个被监控的数据库被称为“Metric ”,它包含所有被监控的数据。类似于关系数据库中的表。每一条监测数据，称为“点”，类似于关系数据库中的行的概念。每个“点”将定义一个时间戳“Timestamp”，它将被用作指示数据收集时间的索引。“标签”作为维度列，代表监控数据的属性。“字段”用作指示栏，作为测量值，即测量结果。
时间序列数据库模型图例时间序列数据库的存储原理，关系数据库存储使用树，虽然减少了数据查询的磁盘寻道时间，但是无法解决大量数据写入时的磁盘效率。由于监控系统的应用场景，经常会写入大量的数据，所以我们会选择LSMtree(日志结构化合并树)来存储时间序列数据库。LSMtree(Log Structured Merge Tree)字面意思是将记录的数据按照日志结构追加到系统中，然后通过合并树的方式进行合并。我们来看一个LevelDB的例子，方便我们理解。LSM Kramp-Karrenbauer树分为三种类型的文件：
接收写请求的Memtable文件(在内存中)；不可变的memtable文件(在内存中)；磁盘上的表文件(排序的字符串表)；有序字符串表；这个有序的字符串是数据的关键字。桌子有七层(L0到L6)。下一层的总大小限制是上一层的10元倍。
LSMtree LevelDB存储示意图LSMtree写入过程：
将数据添加到日志WAL(预写日志)中，写入该日志是为了防止内存数据丢失，并可以及时恢复。将数据写入memtable。当memtable已满(超过某个阈值)时，它将被转移到不可变的memtable，新的memtable将用于接收新的数据请求。一旦immutable已满，它就会被写入磁盘。并且先存储L0层的SSTable磁盘文件，所以此时不需要合并文件。每层所有文件的总大小是有限的(8MB，10MB，100元MB … 1 TB)。从L1楼层开始，每下一层的容量增加十倍。
如果某一层中的数据文件总数超过阈值，则选择该层中的一个文件，并将其与下一层中的文件合并。这样上层的数据都是比较新的数据，所以查询可以从上层开始，依次往下，这些数据是按时间顺序存储的。监控系统的分层说完了监控系统的分类，再来说说监控系统的分层。用户请求数据返回，并通过系统中的各个级别。
监控系统分层示意图一般我们认为监控系统是五层，当然也有人把它分成三层，意思差不多，仅供参考：
客户端监控、用户行为信息、服务返回代码、客户端性能、运营商、版本、操作系统等。业务监控，核心业务监控，比如登录、注册、下单、支付等等。应用层监控，相关技术参数，如URL请求、服务请求、SQL执行结果、缓存利用率、QPS等。系统监控、物理主机、虚拟主机和操作系统参数。比如：CPU利用率，内存利用率，磁盘空间。网络层监控，网络条件参数。例如：网关流量、丢包率、误包率、连接数等。在流行的监控系统前面，我们谈到了监控系统的功能、分类和分层。相信大家对IT监控系统都有一定的了解。接下来，我们来看看一些好的做法。这里有两种流行的监控系统：
ZabbixPrometheusZabbixZabbix是一个企业级的分布式开源监控方案。它由阿列克谢弗拉季舍夫创立，并由扎比克斯SIA不断发展和支持。Zabbix可以监控网络参数、服务器健康和软件完整性。它提供通知机制，允许用户配置告警，以便快速反馈问题。基于存储的数据，Zabbix提供报告和数据可视化，并支持主动轮询和被动捕获。它的所有报告、统计数据和配置参数都可以通过网页访问。Zabbix的API功能非常完善，大部分操作都提供API接口，方便与现有系统集成。比如通过历史数据查询API，获取在线服务器的使用情况，生成报表；设置条件，过滤问题服务器和问题业务，添加报警。利用Zabbix graph的API生成关键指标的趋势图，方便运维人员实时了解系统情况。报警添加API用于连接监控系统和部署系统。例如，如果新部署了一个新的实例，将自动添加所需的监控策略；相反，当实例脱机时，关联的监视策略将被删除。Zabbix由服务器、代理和代理(可选)组成：
代理负责收集数据并将其传输到服务器。服务器负责接收代理数据，保存或报警。代理负责代理服务器收集代理传输的数据，并转发给服务器。代理安装在受监控的服务器上，用于与服务器通信以传输数据。
Zabbix部署模式Zabbix数据收集主要有两种模式：服务器主动拉取数据和代理主动上报数据。以服务器拉取的数据为例，用户在门户网站中设置要监控的机器，配置监控项目和报警策略。Zabbix Kramp-Karrenbauer服务器会根据策略主动获取Agent的数据，然后存储在MySQL中。同时根据用户配置的策略，确定是否需要报警。用户可以在Web上以图表的形式查看各种指标的历史趋势。在Zabbix中，服务器主动拉取数据的方式称为主动检查。这种方式配置方便，但是会影响Zabbix Kramp-Karrenbauer服务器的性能。所以在生产环境中，一般选择主动推送数据到Zabbix Kramp-Karrenbauer服务器的方法，称为Trapper。即用户可以定时生成数据，然后按照Zabbix定义的数据格式批量发送到Zabbix Kramp-Karrenbauer服务器，这样可以大大提高服务器的处理能力。作为一个选项，代理收集代理数据并将其转发给服务器。当服务器和代理不在同一个网络中时，有必要使用代理进行远程监控，尤其是当远程网络有防火墙时。同时也可以分担服务器的压力，减少服务器处理连接数的开销。普罗米修斯(Prometheus)随着近年来云环境的发展，普罗米修斯得到了广泛的认可。其本质是时间序列数据库，而Zabbix使用MySQL进行数据存储。从上面对时序数据库的分析来看，Prometheus可以很好的支持大量数据的写入。它采用拉模式从应用程序中拉取数据，通过预警模块实现监控和预警。据说单机可以消耗几百万个时间序列。让我们来看看普罗米修斯的几个组成部分：
Prometheus服务器，用于收集和存储时间序列数据，负责监测数据的采集、存储和查询。监控目标配置：Prometheus Server可以通过静态配置管理监控目标，也可以配合服务发现(K8s、DNS、Consul)实现动态管理监控目标。目标存储，Prometheus Server本身就是一个时间序列数据库，将采集的监控数据按时间序列存储在本地磁盘中。监控数据查询，Prometheus Server提供了自定义PromQL语言来实现数据查询和分析。客户端，客户端库。为要监控的服务生成相应的指标，并将它们公开给Prometheus Server。普罗米修斯服务器来拉的时候直接返回实时状态的度量。我通常和约伯一起工作。推送网关，主要用于短期工作。由于这种工作存在的时间很短，可能在普罗米修斯来拉之前就已经消失了。因此，这些作业可以直接将它们的指标推送到Prometheus服务器。出口商，第三方服务接口。向Prometheus发送指标(数据集)。Exporter将监控数据采集的端点以HTTP的形式暴露给Prometheus Server，这样就可以通过Endpoint端点获取监控数据。Alertmanager在收到来自Prometheus服务器的警报后，将处理数据。例如，重复数据删除、分组，然后根据规则发出警报。Prometheus服务器内置的Express Browser UI，通过PromQL实现数据查询和可视化。
普罗米修斯架构图说完普罗米修斯的组成部分，我们来看看普罗米修斯架构：
Prometheus Server定期从作业/导出程序中提取指标。同时，您还可以从Pushgateway接收指标。Prometheus Server将接收到的数据存储在本地时间序列数据库中，并运行定义好的alert.rules，一旦符合警报规则，就会将警报推送给Alertmanager。Alertmanager根据配置文件处理收到的警报，例如，发送电子邮件警报或使用第三方组件发出警报。WebUI/Grafana/APIclients，可以借助PromQL查询监控数据。如下比较最后两个工具：
从上面的对比可以看出Zabbix和普罗米修斯的对比图：
Zabbix更成熟，上手更快。高度集成导致灵活性差，当监控复杂度增加时，定制难度也会增加。而且，所使用的关系数据库对于大规模的监控数据插入和查询是一个问题。Prometheus难用，定制灵活性高，数据聚合可能性多，有时序数据库加持。Zabbix对于监控物理机或者相对稳定的监控环境优势明显。如果监控场景多为云环境，建议使用Prometheus。摘要
监控系统思维导图监控系统对于IT系统运维，从状态监控到数据收集/分析，再到故障报警，以及问题解决，都具有重要意义。最后，将报表归档以协助操作和维护。监控系统分为三类：日志类、调用链类和测量类。它们各有特点，应用场景也不同。因为整个IT系统需要监控，所以分为五层，分别是客户端、业务层、应用层、系统层、网络层。Zabbix和Prometheus是目前比较流行的监控系统，可以根据它们的特点来使用。作者：崔豪简介：十六年的开发和建筑经验。曾任惠普武汉交付中心技术专家、需求分析师、项目经理，后在一家创业公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构和研发；管理。