如今，信息化技术应用早已在社会生活的各个层面呈爆发式增长，从聊天、刷微博到打车、点外卖，这些应用场景的实现无不得益于其后端庞大系统服务的支持。而在这些后端系统中，微服务架构系统毫无疑问占据着绝对的数量优势，因为传统的单体架构系统不管是在业务上还是在性能上都难以承载我国巨大的信息消费市场的技术功能需求。
无论是互联网行业的开疆拓土，还是银行保险等传统金融行业的科技化自我重塑，甚至是更宽、更广层面上的政企数字化转型，它们都将各自的上层建筑建立在以微服务架构系统为根基的信息系统之上。
由此，以微服务架构来构建系统，实现服务的快速开发、部署与生产环境下的自动扩/缩容，最终为上层提供灵活、稳定和高可靠的数据支撑，这是目前整个信息技术行业所践行的主线。在这条主线上，如何更好地实现微服务系统的测试与质量保障工作是一个必须提出和予以解答的问题。
基于微服务的监控模式主要分为以下四类：健康检查、日志监控、链路追踪、监控指标。本文带大家讨论一下监控指标。
当我们在搜索引擎中输入“监控”时，首先出现的两个结果如下。
1）观察及检查（某事物）在一段时间内的进度或品质。
2）保持定期监控。
首先我们需要了解监控什么数据，从系统以及各种环境中获取需要的数据和状态是监控的核心，这些数据和状态被称为指标监控。
我们可以根据实际场景，按照系统层级结构划分，将指标监控的监控对象从底层向上层依次归类于基础层、中间层、应用层、业务层这几个层面，具体如图1所示。
图 1 指标监控分层划分
1.指标的概念与特征
微服务领域中的指标涉及两个要点：各类数据指标、量化对比。故指标应具备以下 3 个显著的特性。
1）可对比：指标能够在不同的微服务或同一个微服务的多个实例之间进行比较。例如， 当同一个微服务有多个实例运行时，对不同实例入栈请求数的监控。再如，当某个实例面临大量请求时，对比正常工作状态下的请求数，这时我们依据负载均衡的指标阈值进行合理的请求分配。
2）易理解：指标所衡量的对象、计算方法和输出的结果值都是容易被理解的。
3）理想的比例：理想的比例是可预见的，例如我们设置某个接口成功和失败请求的比例为 9 : 1。
2.监控指标分层
我们可以从业务人员、开发人员以及运维人员的角度来理解指标的关注面。
（1）从业务人员角度出发
业务人员更关注业务层指标，比如客户转化率、登录数、下单数、交易成功数、退单率等，这些都是从产品本身的业务来定义，开发人员再利用 APM 框架进行埋点，最终收集数据，在 APM 系统中以各类直观的图片呈现以供查看，业务人员通过这些数据来及时判断市场的状况，并进行策略的调整。
（2）从开发人员角度出发
开发人员的关注点则是系统是否出现 Bug，是否存在严重的性能问题。因此需要对请求的延迟居高不下、请求失败率过高、代码出错等情况进行监控。开发团队对整个项目代码进行讨论分析，并对可能存在问题的代码进行埋点，最终在发生问题后，开发人员就可以通过埋点标记查看具体问题的详细数据，并及时修复问题。
（3）从运维人员的角度出发
运维人员的关注方向在于硬件层面能否支撑整个服务集群的正常运转。面对成百上千个微服务实例，每个实例都有自己的 CPU、内存、硬盘等信息，运维人员需要通过这些数据度量和监控硬件层面的健康状况。
下面将着重介绍微服务监控的指标，从基础设施到运行时监控指标，再到业务场景下对应服务的监控指标。
3.基础设施监控
基础设施监控是针对运行服务底层设施的监控，比如容器、虚拟机、物理机等，监控的指标主要有内存使用率、CPU 使用率等资源的状态。我们通过对资源的监控和告警能够及时发现资源瓶颈，从而进行扩容操作避免影响服务，同时资源的异常变化也能辅助定位服务问题，如内存泄漏等。
而 CIM（Core Infrastructure Monitoring，核心基础设施监控）中的核心指标则更是我们
需要重点关注的，主要包含以下几个指标。
1）Avg. CPU usage：平均 CPU 使用率；
2）Peak CPU duration：峰值 CPU 持续时间；
3）Avg. memory usage：平均内存使用量；
4）Inbound and outbound bandwidth usage：入站和出站带宽使用情况。
以上所提及的指标就能满足大部分服务对于底层基础设施监控的需求，利用监控服务设置好合理的阈值能够帮助我们在特殊情况下快速做出反应。例如通过流量的变化趋势可以清晰地了解到服务的流量高峰以及流量的增长情况，流量也是资源分配的重要参考指标。耗时是服务性能的最直观体现，耗时比较大的服务往往最需要进行优化。比如，部署在 AWS 上的服务遇到大量并发请求并触发负载均衡机制时，就需要启动多个服务实例帮助服务缓解性能问题。平均耗时往往参考价值不大，我们通常采用中位数，包括性能指标 TP90、TP95、TP99 等。
4.中间层监控
中间层监控主要是对应用服务所依赖的中间件进行监控，如 Nginx、Redis、MySQL、RocketMQ、Kafka 等，它们的稳定也是保证应用程序持续可用的关键。
我们就以 Nginx 为例来聊聊如何对中间层进行监控。Nginx 可以说是当今应用最为广泛的中间层应用，因其采用了异步非阻塞工作模型，具备高并发、低资源消耗的特性，同时高度模块化的设计使 Nginx 具备很好的扩展性。Nginx 可以作为反向代理服务器来转发用户请求，在处理请求的过程中实现后端实例的负载均衡；也可将 Nginx 配置为本地静态服务器，来处理静态请求。
Nginx 的核心监控指标如表1 所示。
表 1 Nginx 核心监控指标
1）请求延迟监控。请求延迟监控主要关注 $request_time，并绘制 TP 指标图，来确认TP99 指标值。另外，我们还可以增加对 $upstream_response_time 指标的监控，来辅助开发人员定位延迟问题的原因。
2）服务错误率监控。考虑到 Nginx 是应用最广的 Web 服务器，我们不但要对 Nginx 本身运行状态进行监控，还必须对 Nginx 的各类错误响应进行监控，HTTP 错误状态码以及error.log 中记录的错误详细日志都应被监控以协助解决对应问题。
我们可以用心跳监控的方式监控固定时间间隔内服务端发生的错误代码（例如：4××
代码表示客户端错误，5×× 代码表示服务器端错误），这样我们就可以了解客户端收到的结果是否正确。如果某段时间内错误率飙升，则可能是应用出现了漏洞。
如果希望通过 access.log 和 error.log 文件来分析错误，那么建议使用 ELK，其中 Logstash 可以收集 Nginx 的 access.log 和 error.log 的错误信息，之后利用 Kibana 或 Grafana 展示错误信息。
3）流量。通过持续监控 Nginx 所接受请求，时刻关注流量异常波动，捕获流量突增、突降的情况，来判断服务是否被恶意攻击，并可以对服务的可用性进行评估。我们可以对服务设置阈值，当流量环比增长或降低到阈值设定的区间之外时，就能够及时进行告警。
4）基础活跃指标。如图 2 所示，Nginx 数据收集过程显示了一个客户端连接的过程， 以及开源版本的 Nginx 如何在连接过程中收集指标。
图 2 Nginx 数据收集过程
在 Nginx 的配置文件中，将 stub_status 状态设置为 On 后，我们就可以在浏览器中输入 http://127.0.0.1/nginx-status 查看指标信息。
Active connections: 500
server accepts handled requests 3074 2061 8423
Reading: 20 Writing: 30 Waiting: 200
对上述 nginx_staus 返回参数的说明请参考表2。
表 2 Nginx 配置参数列表
通过以上指标我们可以了解 Nginx 详细的工作状态，再结合 ELK 分析 Nginx 日志，并进行可视化展示。
5.应用层监控
应用层监控一般可划分为运行时监控与 JVM 监控指标。
大部分微服务基于 Spring Cloud 组件架构，监控 JVM 运行时关键性能指标就能够帮助我们优化应用服务。
JVM 监控指标包括堆内存指标、非堆内存指标、直接缓冲区指标、内存映射缓冲区指标、GC（Garbage Collection，垃圾回收）瞬时和累计详情及 JVM 线程数等。具体 JVM 监控指标如表 3 所示。
表 3 JVM 监控指标
监控 JVM 的工具很多，JDK 本身提供了很多便捷的 JVM 性能调优监控工具，除了 JPS、Jstat、Jinfo、Jmap、Jhat、Jstack 等小巧的工具，还有集成式的 Java VisualVM 和 JConsole。
如果服务部署在云上，也可以利用云厂商提供的监控功能来查看 JVM 的实时状态。如图 6-11 所示是利用了阿里云提供的 JVM 监控。
此外可以利用 Prometheus、Zabbix 等专业监控服务监控 JVM，当然也可以基于当前最流行的 ELK 日志系统，利用 Jolokia 监控 Spring Boot 应用的 JVM 运行时状态。
图3阿里云 JVM 监控
6.业务层监控
业务层监控也是监控系统关注的重要内容，在实际场景中如果只是做到让应用程序稳定运行是远远不够的，我们常常还要对具体业务产生的数据进行监控，例如：网站所关注的 PV、UV 等参数；后端的交易系统所关注的订单量、成功率等数据。对于业务核心监控指标，其设定因具体的业务和场景存在差异而有所不同，故我们在制定业务层监控的策略时需要构建适合该业务特点的业务监控系统。
资源分享
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】
3467
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
