07 | 如何监控微服务调用？

Sep 6, 2018

07 | 如何监控微服务调用？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

07 | 如何监控微服务调用？

2018-09-06 胡忠想来自北京

《从0开始学微服务》

课程介绍



讲述：胡忠想

时长11:49大小5.41M



与单体应用相比，在微服务架构下，一次用户调用会因为服务化拆分后，变成多个不同服务之间的相互调用，这也就需要对拆分后的每个服务都监控起来。
在讲述如何监控微服务调用前，首先你要搞清楚三个问题：监控的对象是什么？具体监控哪些指标？从哪些维度进行监控？下面就从这三个问题开始，一起来看看如何监控微服务调用。
监控对象既然要监控，那么要监控哪些对象呢？根据我的实践经验，对于微服务系统来说，监控对象可以分为四个层次，由上到下可归纳为：
用户端监控。通常是指业务直接对用户提供的功能的监控。以微博首页 Feed 为例，它向用户提供了聚合关注的所有人的微博并按照时间顺序浏览的功能，对首页 Feed 功能的监控就属于用户端的监控。
接口监控。通常是指业务提供的功能所依赖的具体 RPC 接口的监控。继续以微博首页 Feed 为例，这个功能依赖于用户关注了哪些人的关系服务，每个人发过哪些微博的微博列表服务，以及每条微博具体内容是什么的内容服务，对这几个服务的调用情况的监控就属于接口监控。
资源监控。通常是指某个接口依赖的资源的监控。比如用户关注了哪些人的关系服务使用的是 Redis 来存储关注列表，对 Redis 的监控就属于资源监控。
基础监控。通常是指对服务器本身的健康状况的监控。主要包括 CPU 利用率、内存使用量、I/O 读写量、网卡带宽等。对服务器的基本监控也是必不可少的，因为服务器本身的健康状况也是影响服务本身的一个重要因素，比如服务器本身连接的网络交换机上联带宽被打满，会影响所有部署在这台服务器上的业务。
监控指标搞清楚要监控的对象之后，需要监控具体哪些指标呢？根据我的实践经验，通常有以下几个业务指标需要重点监控：
请求量。请求量监控分为两个维度，一个是实时请求量，一个是统计请求量。实时请求量用 QPS（Queries Per Second）即每秒查询次数来衡量，它反映了服务调用的实时变化情况。统计请求量一般用 PV（Page View）即一段时间内用户的访问量来衡量，比如一天的 PV 代表了服务一天的请求量，通常用来统计报表。
响应时间。大多数情况下，可以用一段时间内所有调用的平均耗时来反映请求的响应时间。但它只代表了请求的平均快慢情况，有时候我们更关心慢请求的数量。为此需要把响应时间划分为多个区间，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上这五个区间，其中 500ms 以上这个区间内的请求数就代表了慢请求量，正常情况下，这个区间内的请求数应该接近于 0；在出现问题时，这个区间内的请求数会大幅增加，可能平均耗时并不能反映出这一变化。除此之外，还可以从 P90、P95、P99、P999 角度来监控请求的响应时间，比如 P99  =  500ms，意思是 99% 的请求响应时间在 500ms 以内，它代表了请求的服务质量，即 SLA。
错误率。错误率的监控通常用一段时间内调用失败的次数占调用总次数的比率来衡量，比如对于接口的错误率一般用接口返回错误码为 503 的比率来表示。
监控维度一般来说，要从多个维度来对业务进行监控，具体来讲可以包括下面几个维度：
全局维度。从整体角度监控对象的的请求量、平均耗时以及错误率，全局维度的监控一般是为了让你对监控对象的调用情况有个整体了解。
分机房维度。一般为了业务的高可用性，服务通常部署在不止一个机房，因为不同机房地域的不同，同一个监控对象的各种指标可能会相差很大，所以需要深入到机房内部去了解。
单机维度。即便是在同一个机房内部，可能由于采购年份和批次的不同，位于不同机器上的同一个监控对象的各种指标也会有很大差异。一般来说，新采购的机器通常由于成本更低，配置也更高，在同等请求量的情况下，可能表现出较大的性能差异，因此也需要从单机维度去监控同一个对象。
时间维度。同一个监控对象，在每天的同一时刻各种指标通常也不会一样，这种差异要么是由业务变更导致，要么是运营活动导致。为了了解监控对象各种指标的变化，通常需要与一天前、一周前、一个月前，甚至三个月前做比较。
核心维度。根据我的经验，业务上一般会依据重要性程度对监控对象进行分级，最简单的是分成核心业务和非核心业务。核心业务和非核心业务在部署上必须隔离，分开监控，这样才能对核心业务做重点保障。
讲到这里先小结一下，对于一个微服务来说，你必须明确要监控哪些对象、哪些指标，并且还要从不同的维度进行监控，才能掌握微服务的调用情况。明确了这几个关键的问题后，那么该如何搭建一个监控系统，来完成上面这些监控功能呢？
监控系统原理显然，我们要对服务调用进行监控，首先要能收集到每一次调用的详细信息，包括调用的响应时间、调用是否成功、调用的发起者和接收者分别是谁，这个过程叫作数据采集。采集到数据之后，要把数据通过一定的方式传输给数据处理中心进行处理，这个过程叫作数据传输。数据传输过来后，数据处理中心再按照服务的维度进行聚合，计算出不同服务的请求量、响应时间以及错误率等信息并存储起来，这个过程叫作数据处理。最后再通过接口或者 Dashboard 的形式对外展示服务的调用情况，这个过程叫作数据展示。
可见，监控系统主要包括四个环节：数据采集、数据传输、数据处理和数据展示，下面我来给你讲解下每一个环节的实现原理。
1. 数据采集
通常有两种数据收集方式：
服务主动上报，这种处理方式通过在业务代码或者服务框架里加入数据收集代码逻辑，在每一次服务调用完成后，主动上报服务的调用信息。
代理收集，这种处理方式通过服务调用后把调用的详细信息记录到本地日志文件中，然后再通过代理去解析本地日志文件，然后再上报服务的调用信息。
无论哪种数据采集方式，首先要考虑的问题就是采样率，也就是采集数据的频率。采样率决定了监控的实时性与精确度，一般来说，采样率越高，监控的实时性就越高，精确度也越高。但采样对系统本身的性能也会有一定的影响，尤其是采集后的数据需要写到本地磁盘的时候，过高的采样率会导致系统写入磁盘的 I/O 过高，进而会影响到正常的服务调用。所以设置合理的采用率是数据采集的关键，最好是可以动态控制采样率，在系统比较空闲的时候加大采样率，追求监控的实时性与精确度；在系统负载比较高的时候减小采样率，追求监控的可用性与系统的稳定性。
2. 数据传输
数据传输最常用的方式有两种：
UDP 传输，这种处理方式是数据处理单元提供服务器的请求地址，数据采集后通过 UDP 协议与服务器建立连接，然后把数据发送过去。
Kafka 传输，这种处理方式是数据采集后发送到指定的 Topic，然后数据处理单元再订阅对应的 Topic，就可以从 Kafka 消息队列中读取到对应的数据。
无论采用哪种传输方式，数据格式都十分重要，尤其是对带宽敏感以及解析性能要求比较高的场景，一般数据传输时采用的数据格式有两种：
二进制协议，最常用的就是 PB 对象，它的优点是高压缩比和高性能，可以减少传输带宽并且序列化和反序列化效率特别高。
文本协议，最常用的就是 JSON 字符串，它的优点是可读性好，但相比于 PB 对象，传输占用带宽高，并且解析性能也要差一些。
3. 数据处理
数据处理是对收集来的原始数据进行聚合并存储。数据聚合通常有两个维度：
接口维度聚合，这个维度是把实时收到的数据按照接口名维度实时聚合在一起，这样就可以得到每个接口的实时请求量、平均耗时等信息。
机器维度聚合，这个维度是把实时收到的数据按照调用的节点维度聚合在一起，这样就可以从单机维度去查看每个接口的实时请求量、平均耗时等信息。
聚合后的数据需要持久化到数据库中存储，所选用的数据库一般分为两种：
索引数据库，比如 Elasticsearch，以倒排索引的数据结构存储，需要查询的时候，根据索引来查询。
时序数据库，比如 OpenTSDB，以时序序列数据的方式存储，查询的时候按照时序如 1min、5min 等维度来查询。
4. 数据展示
数据展示是把处理后的数据以 Dashboard 的方式展示给用户。数据展示有多种方式，比如曲线图、饼状图、格子图展示等。
曲线图。一般是用来监控变化趋势的，比如下面的曲线图展示了监控对象随着时间推移的变化趋势，可以看出来这段时间内变化比较小，曲线也比较平稳。
饼状图。一般是用来监控占比分布的，比如下面这张饼图展示了使用不同的手机网络占比情况，可见 Wi-Fi 和 4G 的占比明显要高于 3G 和 2G。
格子图。主要做一些细粒度的监控，比如下面这张格子图代表了不同的机器的接口调用请求量和耗时情况，展示结果一目了然。
总结服务监控在微服务改造过程中的重要性不言而喻，没有强大的监控能力，改造成微服务架构后，就无法掌控各个不同服务的情况，在遇到调用失败时，如果不能快速发现系统的问题，对于业务来说就是一场灾难。
搭建一个服务监控系统，涉及数据采集、数据传输、数据处理、数据展示等多个环节，每个环节都需要根据自己的业务特点选择合适的解决方案，关于监控技术方案的选型我会在专栏后面进行详解。
思考题最后请你思考一下，你所在的技术团队目前采用的监控系统，都监控了哪些业务数据？包含哪些业务指标？都有哪些维度？你觉得是否合理？
欢迎你在留言区写下自己的思考，与我一起讨论。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 13

提建议

06 | 如何实现RPC远程服务调用？

08 | 如何追踪微服务调用？

 写留言

精选留言(30)

金hb.Ryan 冷空氣...
2018-09-07
主要分几块，接口性能、微服务性能、日志汇总，接口性能参考鹰眼自研了一套全链路系统也类似pinpoint，微服务性能基于dubbo做了扩展可以全盘监控，日志采用solrflume做统一日志，然后每块数据作为元数据放入hadoop和storm做历史汇总和实时分析，后面计划加入数据挖掘和数据分析做智能监控：）
作者回复: 自研方案能够满足自己需求就可以
27
snakorse
2018-09-06
使用skywalking框架做apm的路过
作者回复: skywalking是一款优秀的支持java语言的监控系统
19
楼下小黑哥
2018-09-07
目前我们业务主要使用 Dubbo ，故我们采用 Dubbo-Monitor 监控 dubbo 接口相关数据。并采用 Grafana 展示数据。对于第三方接口数据，我们将调用信息发送 Kafaka，然后服务端分析。我们的业务为提供支付服务，所以全局维度我们会监控支付接口请求量，错误率等。而从接口维度，我们会监控相关对接支付通道的成功率，掉单率等。
作者回复: 嗯，错误率是个很重要的业务指标
9
eason2017
2018-09-06
我们的系统是网关系统，是客户端接口请求的入口，在此我们做了如下维度:接口http/https状态，接口的SLA，接口的TPS。这几个维度。网关是基于openresty做的改造，所以，这些数据都可以通过lua脚本记录在共享内存当中，以供Prometheus拉取，通过Granfanna来展示。老师，目前会出现一个问题，就是如果某一台网关机器重启，那么Granfanna的展示图上面就是不正确的了，是通过差值来画图的，刚好重启为零，那么做差值就是负值了，请问老师，您有什么画图的方法可以规避这种情况吗？谢谢🙏
展开
作者回复: 我理解是采集点的频率问题吧，如果没数据的话用前一个点的数据
4
oddrock
2018-09-06
问老师个问题，做服务监控时，是否必须事先要求先制定服务日志的规范和系统日志的规范，包括格式规范、文件位置规范等，让各个微服务去遵守？
作者回复: 是的，日志必须符合规范，位置也是
5
周鸿轩
2019-05-17
与监控系统比较相关的一般还会有一套自动报警服务～
4
陈国林
2020-02-27
【监控系统】在容器环境下用的是 Prometheus + Grafana，另外还有用 InfluxDB + Flink + Grafana 【监控维度】 1. 基础监控 + 集群维度: 整个k8s集群维度、其他集群维度 + 节点维度: k8s master、k8s worker 每个节点维度、每个机器维度 + Pod 维度: 每个 Pod 维度 2. 业务监控 + 整体服务 SLA + 业务自定义一些指标
展开
3
钱
2019-05-21
我们的是基础架构部提供的： 1：UMP 方法性能、可用率、调用量、JVM、业务报警、定时执行、机器存活等监控 2：MDC 单机得各种指标监控，CPU/IO/网络流入流出/延迟/磁盘等都都有 3：CAP 容器的监控类似MDC 4：JSF RPC的监控，有调用链的监控，类似UMP 5：JIMDB 缓存的监控 6：DBS 数据库的监控
展开
共 1 条评论
2
Len
2018-09-07
老师，正如专栏正文中最后一张图显示，假如我们现在已经有了各个接口的 QPS 数据，那么在实际监控报警中该怎么使用呢？每个接口上线前做一个压测确定一个 QPS 基准，然后看每个接口是否超过阀值来报警？
作者回复: 这个QPS不一定准确，可以采用性能或者接口慢速比（比如接口超过1秒的比率）作为报警指标
3
梦想是星空
2018-09-06
有开源的，可用于生产的监控系统吗？
作者回复: 有的，专栏后面会讲zipkin和pinpoint
共 2 条评论
2
Sam_Deep_Thinking
2018-09-06
后面会介绍微服务监控的框架吗？？
作者回复: 有专门一章对比开源监控框架
2
Tony
2019-02-22
new relica通过selenium脚本监控还有contrast监控安全性公司在转型微服务，暂时没有metrics监控，后续考虑用istio，service自带了普罗米修斯监控
1
波波安
2018-10-12
项目使用的dubbo实现的微服务化。用pingpoint做的链路监控。 Pinpoint-Collector：收集各种性能数据 Pinpoint-Agent：和自己运行的应用关联起来的探针 Pinpoint-Web：将收集到的数据显示成WEB网页形式 HBase Storage：收集到的数据存到HBase中其他的也有维护同事写的一些脚本对服务进程状态做监控日志收集采用的elk开源组件。
展开
1
feimeng0532
2018-09-07
用户端监控，也属于接口监控吧，只是有可能聚合接口。。。
1
Goku
2018-09-06
请问您说的PB对象是protocol buffers吗？
作者回复: 是的
2
Mac Kwan
2018-09-06
胡老师，为什么没有谈谈专门给我们程序猿看的错误信息的数据采集分析调试呢
作者回复: 服务追踪系统其实能起到这个作用，后面专栏会讲
1
WeDataSphere
2021-12-01
zabbix😌
Geek_b99704
2021-11-27
目前用的是 Graphite, 监控了多个业务方，包括用户关系，商业化广告等等；业务指标包括请求接口的指标比如慢速比，错误率；服务的指标，包括QPS等；单机指标，包括硬件情况，网络情况等；全量指标等等；目前监控在出现异常的时候不能很好的体现出影响范围，需要改进。
俯瞰风景.
2021-10-07
服务监控的目的是为了更好了解服务调用情况，对监控对象的各项监控指标进行监控，然后整合处理成不同维度的数据，通过可视化的方式展示出来，辅助进行决策。微服务中不同服务之间的调用时复杂的，所以需要通过服务监控把分散的数据集中起来，通过监控数据来了解系统和优化系统。
Sch0ng
2021-08-29
微服务监控是排查问题和治理服务重要参考依据，理想的监控能够在故障发生的第一时间分级告警，然后可以根据大盘迅速定位到故障的点。

