电商微服务实战之服务监控

监控对象

一般可分为四类：

用户端监控

业务直接对用户提供的功能的监控。以知乎首页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过高，影响正常服务调用。

所以设置合理采用率是关键，最好可动态控制采样率

系统较闲时，加大采样率，追求监控实时性与精确度

系统负载较高时，减小采样率，追求监控的可用性与系统的稳定性

数据传输

常用方式如下：

UDP传输

数据处理单元提供服务器的请求地址，数据采集后通过UDP协议与服务器建立连接，然后把数据发送过去。

Kafka传输

数据采集后发送到指定的Topic，然后数据处理单元再订阅对应的Topic，即可从Kafka消息队列中读取到对应的数据。

无论哪种，数据格式都十分重要，尤其是对带宽敏感以及解析性能要求比较高的场景，一般数据传输时采用的数据格式有两种：

二进制协议，最常用的就是PB对象，它的优点是高压缩比和高性能，可以减少传输带宽并且序列化和反序列化效率特别高。

文本协议，最常用的就是JSON字符串，它的优点是可读性好，但相比于PB对象，传输占用带宽高，并且解析性能也要差一些。

数据处理

聚合并存储收集来的原始数据。

数据聚合通常有两个维度：

接口维度聚合

把实时收到的数据按接口名维度实时聚合在一起，得到每个接口的实时请求量、平均耗时等信息。

机器维度聚合

把实时收到的数据按照调用的节点维度聚合在一起，这样就可以从单机维度去查看每个接口的实时请求量、平均耗时等信息。

聚合后数据需持久化到DB，所选用DB一般两种：

索引数据库

e.g. Elasticsearch，以倒排索引的数据结构存储，需要查询的时候，根据索引来查询

时序数据库

e.g. OpenTSDB，以时序序列数据方式存储，查询时按照时序如1min、5min等维度来查询。

数据展示

把处理后的数据以Dashboard方式展示给用户。

数据展示有多种方式，比如曲线图、饼状图、格子图。

曲线图

一般是用来监控变化趋势的，比如下面的曲线图展示了监控对象随着时间推移的变化趋势，可以看出来这段时间内变化比较小，曲线也比较平稳。

饼状图

一般是用来监控占比分布的，比如下面这张饼图展示了使用不同的手机网络占比情况，可见Wi-Fi和4G的占比明显要高于3G和2G。

格子图

主要做一些细粒度的监控，比如下面这张格子图代表了不同的机器的接口调用请求量和耗时情况，展示结果一目了然。

总结

服务监控在微服务改造过程中十分重要，没有强大监控能力，就无法掌控各个不同服务的情况，在遇到调用失败时，如果不能快速发现系统的问题，业务就成了灾难。

参考

如何监控微服务调用

微服务 自建电商

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。