能学透微服务架构监控治理，监控系统原理及分类、关注对象就知足

服务监控治理

俗话说，流水的架构，铁打的监控，任何软件系统能够稳定运行都离不开监控。在微服务架构下，大型的单体架构拆分为众多微服务后，一个请求往往需要经过更多的服务节点。在这种情况下，我们必须知道是在哪个服务环节出现了故障，这就需要针对每一个服务，以及每一个指标都进行全面的监控。

微服务的引入会带来分布式下服务监控和服务治理的技术挑战，之前系统内部的方法调用转变成分布式网络下的RPC，对于服务之间的交互集成和架构设计有更高的约束和要求。面对规模化的容器集群部署、不同种类的监控数据类型、海量的微服务，服务监控和服务治理成为微服务控制系统的关键组成部分。

服务系统监控、错误排查定位、系统运行数据的可视化展示和追踪一直是分布式架构系统的难点。而对于微服务系统的监控，必须具备处理和展示这些数据的能力，并能够通过这些数据快速地定位问题，这样才能帮助业务及时止损。

在本章中，我们将按照服务的指标监控、日志监控、全链路调用追踪三个层次，讲解如何增强系统的可观测性和监控运维能力。

Spring Cloud微服务体系在生态上对指标监控、日志及调用追踪等监控技术都有很好的支持，我们会在本章中对相关的Spring Cloud技术组件进行介绍。

监控系统概述

监控系统原理及分类

微服务架构本质上就是分布式系统架构，相比传统应用系统，它在服务的规模上、服务之间的网络交互上都有更高的复杂度。目前大部分微服务的运行环境都基于容器化的部署，微服务不仅改变了传统的软件开发模式，也对系统的监控方式产生了重要的影响。可以说监控系统已经成为微服务架构中不可或缺的关键组成部分。

微服务监控和传统应用系统监控相比，最明显的变化就是监控视角的转变。微服务主要存在下面几个关键因素的变化，而这些变化将对监控对象的指标数据采集度量产生重要的影响。

● 粒度视角。在传统应用系统中，监控的粒度以应用系统为监控对象的最小单元，众多服务集成在一个巨石应用的单进程中；而在微服务架构体系中，我们把监控的视角转换成以服务为中心。一个大的应用系统通常由众多微服务和中间件组成，调用链路相对会更加复杂。

● 运行载体。传统应用大部分部署在以VMware为代表的虚拟机或者物理机上，往往机器的IP地址是固定不变的；而在微服务架构中，大部分强调以Docker为服务载体，IP地址是动态变化的，服务之间的调用需要通过服务注册与发现机制完成，要具备更好的灵活性和动态性。

● 资源占用。在非容器环境下，监控系统的典型做法是在运行的主机或虚拟机的用户空间上执行一个代理程序。但是这种做法可能并不适合容器，容器的优点是小，但在每个容器中都安装代理的做法会对物理机产生极大的资源浪费。目前基于容器监控的主流做法有：

①要求服务的代码自备监控端点功能，类似Actuator。

②利用通用的内核级检测方法来查看容器宿主机的运行指标。

● 运维管理方面。传统的监控系统在运维管理方面主要采用手动配置方式。在非容器环境下，应用没有统一的启动方式，这让监控系统很难参与到应用的弹性管理中；而在容器环境下，监控系统可以随时监控容器的运行状态，并且可以深度参与服务的编排管理和弹性增长与缩减等管理，无须人工干预。

虽然传统应用系统和微服务架构下的监控有上述的诸多不同点，但是整体上监控原理和监控架构还是相似的。一个监控系统通常采用的系统架构如下图所示。

对监控系统的主要架构组件说明如下。

● 采集代理（Agent）：采集代理用来从目标系统获取原始的监控数据。它以Agent的方式部署在应用系统，可以对节点机器或者容器进行实时的数据采集，包括指标数据、日志数据、APM调用链数据。

● 消息中间件（Kafka）：Agent在采集到监控数据后，可以将数据传输到消息中间件，这样就可以实现与服务端的解耦。此外，Agent可以不通过消息中间件，而是通过暴露服务接口的方式，例如JMX或者HTTP接口等，使监控服务器以拉取的方式从Agent端点获得监控数据。

● 监控服务器（Server）：采集到的数据会在监控服务器上进行聚合。通常监控服务器的工作比较繁多，包括对采集的数据内容进行加工计算、流式计算，完成对不同监控数据的分类存储、实时预警等监控任务。同时，所有监控数据的来源都是通过监控服务器提供的API展示的。

● 前端控制（Web Console）：前端控制的主要功能包括两部分：一部分是监控实时数据的展示，包括监控指标数据的实时展示，实时日志、历史日志的查询和展示，调用链信息的展示，预警数据的展示；另一部分功能包括下发对Agent和Server的控制指令，例如预警阈值的设定、重启监控对象Agent的命令等。

● 监控数据存储（DB）：海量的监控数据需要有效的、高性能的数据存储方案，以保证数据的实时性和准确性。通常不同的数据存储类型需要不同的数据存储技术。指标类数据对数据的 实 时 性 要 求 比 较 高 ， 对 应 的 开 源 时 序 性 数 据 库 有OpenTSDB、Grafana、Prometheus、InfluxDB等；对于日志类数据，目前Elasticsearch的使用比较广泛，在日志搜索的模糊查询等功能上，都有巨大优势；对于调用链数据，使用文档类型的MongoDB或者日志类型的Elasticsearch都是比较常见的方案。

监控分类

按照监控系统的原理和作用，一般基于监控系统来采用数据存储方案。监控系统大致可以分为指标类（Metrics）、日志类（Log）、调用链类（Tracing）。

指标类

指标类数据主要采用时序性数据库作为存储。它从监控事件发生时间及当前数值的角度来记录监控信息，可以实现聚合运算的目的，用于查看一些指标数据和指标趋势。所以这类监控不是用来查问题的，而是用来看趋势的。

指 标 类 一 般 有 5 种 基 本 的 度 量 类 型 ： Gauges （ 度 量 ） 、Counters（计数器）、Histograms（直方图）、Meters（TPS计算器）、Timers（计时器）。

日志类

在框架代码、系统环境及业务逻辑中一般都会产生一些日志。我们通常把这些日志记录后统一收集起来，方便在需要时进行查询。日志类信息一般是非结构化的文本内容，其输出和处理的解决方案比较多，如ELK Stack方案（Elasticsearch+Logstash+Kibana）。

调用链类

调用链类监控主要记录一个请求的完整流程。HTTP请求在微服务中经过不同的服务节点后，再返回客户端。在这个过程中通过调用链参数来追寻全链路行为，可以很方便地知道请求在哪个环节出了故障、系统的瓶颈在哪儿。这一类监控需要对代码进行埋点，通过抓取日志数据来完成信息收集，一般在大中型项目中较多用到。后面会单独讲解调用链技术。

监控关注的对象

监控系统体系一般都采用分层式的架构方式，也就是说，我们需要对监控的对象进行分层。通常我们会把监控对象大致分为下面几大类。

系统层监控

系统层监控主要包括CPU、内存、磁盘、网络等基础设施层的监控，这也是运维人员比较关注的对象。系统运行的繁忙程度、健康程度、资源吞吐等信息会反映在一系列运行指标上，不管是CPU负载过高、磁盘I/O过于频繁，还是内存使用过多导致频繁的内存回收或QPS过高等，都会导致系统的服务质量下降，因此当对应的指标超过设定的阈值时，开发人员或者运维人员必须进行处理。详细的指标介绍如下。

● CPU利用率：需要重点关注的几个指标包括us（用户空间占用CPU百分比）、sy（内核空间占用CPU百分比）、wa（等待I/O的CPU时间百分比）、st（实时），这些指标代表CPU执行用户程序所占用的时间。通常情况下，希望us越高越好。sy代表的是系统时间，表示CPU在内核态所花费的时间，如果sy过高，则意味着系统在某些地方的设计不够合理，比如频繁地切换用户态和系统态。而对于计算密集型的应用，us一定会偏高，wa代表的是等待时间，表示CPU在等待I/O所花费的时间。系统一般不应该花费大量的时间来等待，如果wa过高，则代表系统设计有不合理的地方。

● 内 存 使 用 ： 需 要 关 注 的 指 标 包 括 total 、 used 、 free 。

free+buffers+cached代表可用内存大小，如果可用内存过小会导致FGC（全堆范围的内存回收），影响系统的响应。对于应用来说，虚拟内存Swap使用过高，则说明需要调用大量内存到磁盘，影响系统的性能。我们可通过vmstat看出虚拟内存的使用情况。

● 磁盘剩余情况及磁盘I/O：磁盘剩余情况也是一个非常重要的指标。如果磁盘没有足够的剩余空间，那么正常的日志写入和系统I/O都将无法正常进行。通过df-h命令即可看到各个分区的占用情况。通过查看磁盘I/O情况可以看出I/O的繁忙情况，I/O的繁忙情况在一定程度上反映了系统的负载情况。一般通过iostat-d-x命令来查看I/O情况。

● 网络traffic：一般情况下，对网络应用而言，网络traffic也值得关注。进程的网络读写I/O是网络请求繁忙程度的重要指标，当网络I/O成为应用的瓶颈时，需要水平扩容服务，提升服务的网络I/O容量。

● 基础设施日志：网络设备通过大量的日志记录当前的运行状态，这些日志都可以作为排查和定位问题的重要数据来源。

例如Nginx负载均衡上的错误日志error.log等，都可以通过日志采集工具归集到日志服务器，进行统计分析。

应用层监控应用层监控指从应用、服务角度进行的监控，应用服务监控指标由服务系统内部产生，一般能够真实地反映当前业务的运行状态。对于Spring Boot微服务架构，可以借助Actuator服务端点技术，提供各种类型的指标数据供监控Admin采集。对于不具备监控数据的应用系统，需要通过手动埋点或自动埋点的方式进行监控数据的提取，通过这些指标可以从服务层面衡量终端用户的体验、服务中断、业务影响等问题。其中，延迟、吞吐、错误、饱和度四个指标也被Google SRE总结为“黄金指标”，对监控业务系统具有重要的指导意义。

下面具体介绍应用层监控数据的主要指标。

● 服务延迟：指用户访问后端服务请求所需的时间，记录用户所有请求所需的时间，重点区分成功请求的延迟时间和失败请求的延迟时间。例如，在数据库或者其他关键服务异常触发

HTTP 500的情况下，用户可能会很快得到请求失败的响应内容。如果不加区分地计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此之外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些错误会明显地影响系统的性能，因此追踪这些错误的延迟也是非常重要的。

● 服务吞吐量：指监控应用单位时间内处理请求的数量，用来衡量服务的容量请求。常用的吞吐量单位有TPS、QPS、QPM等。

○ TPS：Transactions Per Second（每秒事务处理数），指服务器每秒处理的事务次数。一般用于评估数据库、交易系统的基准性能。

○ QPS：Queries Per Second（查询量/秒），指服务器每秒能够处理的查询次数，例如域名服务器、MySQL查询性能。

○ QPM：Queries Per Minute（查询量/分钟），指服务器每分钟能够处理的查询次数。

● 服务错误：指当前服务所发生的错误响应情况，衡量当前服务错误发生的速率。对于失败响应，可以使用响应Code显式表示（如HTTP 500错误）；而有些错误是隐式的（如HTTP响应200，但实际业务流程仍然是失败的）。我们会在单位时间内计算所有发生请求的数量（Total Count）和发生错误响应的数 量 （ Error Count ） ， 然 后 计 算 ErrorRate （ 错 误 率 ）=Error Count/Total Count。

● 饱和度：可以理解为服务的利用率，代表服务系统承受的压力，所以饱和度与服务的吞吐有密切的关系。流量的上升一般会导致饱和度的上升，通常情况下，每种业务系统都有各自的饱和度指标。在很多业务系统中，消息队列长度是比较重要的饱和度指标，除此之外，CPU、内存、磁盘、网络等系统资源的利用率也可以作为饱和度指标的一种体现方式。

JVM监控指标

JVM作为Java应用服务的主要载体，对业务服务的运行状态会产生重要影响。基于JVM运行环境的内存和线程指标，可以实时监控指标趋势，进行性能分析。在JVM监控分析工具中，Java Attach API主要用于Attach到虚拟机进程，进行如下操作。

● 获取JMX Connection：从外部获取JVM Connection，得到MXBean，抓取运行数据（CPU采样分析）。

● 获取VirtualMachine对象：调用接口，得到堆内存分布信息（内存采样分析）。

此外，JVM自带的jmap、jstat、jstack等常用命令可用来查看当前Java进程的运行情况。

● jmap：查看堆内存使用情况。

可 以 查 看 到 MetaspaceSize 、 CompressedClassSpaceSize 、MaxMetaSize。

● jstat：收集统计信息。

可以查看类加载情况的统计、JVM中堆的垃圾收集情况的统计，也可以查看HotSpot中即时编译器编译情况的统计。

● jstack：收集Java线程栈信息。

jstack常用来打印Java进程、core文件、远程调试端口的Java线程堆栈跟踪信息，包含当前虚拟机中所有线程正在执行的方法堆栈信息的集合。

业务日志

业务日志是系统排查当前业务运行状态的一个重要的数据来源，可以通过日志的类型划分不同的日志分级、格式。

● ERROR是最高级别错误，反映系统发生了非常严重的故障，无法自动恢复到正常态工作，需要人工介入处理。系统需要将错误相关痕迹及细节记录在ERROR日志中，方便后续人工回溯解决。

● WARN级别的问题需要开发人员给予足够关注，表示有参数校验问题或者程序逻辑缺陷，当功能逻辑走入异常逻辑时，应该考虑记录WARN日志。

● INFO日志主要记录系统关键信息，旨在保留系统正常工作期间的关键运行指标，开发人员可以将初始化系统配置、业务状态变化信息，或者用户业务流程中的核心处理，都记录到INFO日志中，方便日常运维工作及错误回溯时复现上下文场景。

● 开发人员可以将各类详细信息记录到DEBUG里，起到调试的作用，包括参数信息、调试细节信息、返回值信息等。其他等级不方便显示的信息也可以通过DEBUG日志来记录。

用户层服务类指标

这一类指标主要与用户、业务相关，属于业务层面，大多数是特定业务或者特定场景下比较关注的对象。

用户层的服务指标通常也被称为自定义指标，需要根据业务场景和业务痛点，提取我们关注的监控对象的服务指标，作为衡量和判断当前业务运行情况的依据。例如下面的业务指标指示的“业务运营监控”项目。业务运营人员需要收集所有贷款进件的运营状态是否正常，那么我们需要定义不同业务阶段、不同地域下的不同进件状态指标——存量指标，如下表所示。