Galileo Finch

go big or go home

初探监控系统

2018-11-26 Galileo Finchmonitor

初探监控系统

监控系统在整个系统架构中,担任眼睛般的重要地位。不管是用户端的监控,接口调用监控,还是对系统资源的监控,都是不可缺少的。没有强大的监控能力,就没有办法掌控各个服务的情况,当出现异常的时候,也不能进行快速的问题定位。

同时带来以下问题,我们的监控对象是什么,监控指标是请求量、错误率还是什么其他的指标。监控的维度是全局监控,还是分机房监控,或者以时间维度进行监控?

那要如何组成一个适用的监控系统呢?

  • 监控对象
  • 监控指标
  • 监控维度
  • 监控系统组成:

    • 数据收集
    • 数据传输
    • 数据处理
    • 数据展示

监控对象

监控对象可以分为四个层级:

  • 用户端监控 通常是指业务直接对用户提供的功能的监控。比如用户登录操作的监控。

  • 接口监控 通常是指业务提供的功能所依赖的具体RPC(Remote procedure call)接口的监控。

  • 资源监控 通常是接口调用相关资源的监控。比如redis、db。

  • 基础监控 通常是指对服务器本身健康状态的监控。包括CPU利用率、内存使用量、IO读写量以及网卡和带宽等。

监控指标

在搞清楚要监控的对象之后,我们要了解具体需要哪些监控指标:

  • 请求量。请求量可以细分成两个维度:

    • 实时请求量,使用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。

  • 错误率。错误率的监控通常用一段时间内调用失败的次数占调用总次数的比率来衡量。

监控维度

一般来说,我们要从多个维度对业务进行监控。具体可以分一下几个维度:

  • 全局维度。从整体角度监控对象的请求量,平均耗时以及错误率。全局监控一般是为了对监控对象的调用情况有整体了解。

  • 分机房维度。一般为了业务的高可用性。服务可能部署不止一个机房。因为不同机房的地域不同,一个监控对象的各个指标可能也不一样,所以可能需要深入到机房内部进行监控细分。

  • 单机维度。即便是在同一个机房内部,可能也会存在年份和批次不同的机器,同样各种指标也会有差异。

  • 时间维度。同一个监控对象,在每天的同一时刻各个指标通常也不一样,这种差异可能是业务变更导致的,也可能是运营活动导致的。为了了解指标的变化,就要那当前时间的数据与一天前或者一周前的数据做比较。

  • 核心维度。一个系统当然也有其核心关注点,也就是我们一般说的业务重要程度。核心业务和非核心业务在部署上一般也是隔离的。

必须明确要监控哪些对象、哪些指标、并且还要从不同的维度进行监控,才能掌控服务的调用情况。

监控系统的原理

要对服务进行监控,首先要收集到每次调用的详细信息,包括调用的响应时间、调用是否成功、调用的发起者和接收者,收集的过程叫做数据采集。数据采集到之后,要把数据通过一定的方式传输给数据处理中新进行处理,这个过程叫做数据传输。收到传输过来的数据之后,数据处理中心再按照服务的维度进行聚合,计算分析出不同服务的请求量、响应时间以及错误信息并存储起来,这个过程叫做数据处理。最后再通过接口或者Dashboard的形式对外展示服务的调用情况,也就是数据展示

1、数据采集

  • 服务主动上报,这种处理方式通过再业务代码或者在服务框架里加入数据收集代码的逻辑。在每一次服务调用完成之后,主动通知服务的调用信息。
  • 代理收集,这种方法通过代理解析服务调用后的调用日志,再上报服务的调用信息。

无论哪种方式,主要的问题也就是采样率,采样率决定了监控的实时性和精确度。一般来说,采样率越高,同样的监控的实时性和精确度也就越高。但采样对系统本身性能也会有一定影响,尤其是数据需要写入到本地磁盘,过高的采样率会导致系统写入磁盘的I/O过高,进而影响正常服务的调用。所以设置合理的采用率是数据采集的关键,最好根据系统空闲,动态的控制采用率。

2、数据传输

  • UDP传输,这种方式是数据处理单元提供服务器的请求地址,数据采集后通过UDP协议于服务器建立链接,发送采样数据。

  • Kafka传输,这种方式是数据采集后发送到指定的Topic,然后数据处理单元订阅对应的Topic,就可以从Kafka消息队列读取对应的数据。

无论哪种传输方式,数据结构都尤为重要,尤其是对带宽敏感以及解析性能要求比较高的场景,一般数据传输采用的格式有两种:

  • 二进制协议,最常用的PB(protocol buffers)对象,它的邮件是高压缩比和高性能,可以减少传输带宽并且序列化和反序列化效率特别高。

  • 文本协议,最常用的JSON字符串,优点是可读性比较好。当时相比PB对象,传输占用带宽高,而且解析能力也要差一点。

3、数据处理

数据处理是对收集来的原始数据进行聚合和存储。

  • 接口维度聚合,这个维度是把实时收到的数据按照接口名维度实时聚合在一起,这样就可以得到每个接口的实时请求量,平均耗时等信息。

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

聚合后的数据需要持久化到数据库中存储,所选用的数据库一般分两种:

  • 索引数据库,比如Elasticsearch,以倒排索引的数据结构存储,需要查询的时候,根据索引来查询。
  • 时序数据库,比如OpenTSDB,以时序序列数据的方式存储,查询的时候按照时序如1min、5min等维度来查询

4、数据展示

收集好了相关数据当然要进行展示了,主要通过Dashboard的方式展示给用户。数据展示有多种方式,比如曲线图、饼状图、格子图展示等。

  • 曲线图。一般是用来监控变化趋势的
  • 饼状图。一般是用来监控占比分布的
  • 格子图。主要做一些细粒度的监控

总结

今天主要分析了监控系统的基本构成,需要考察的技术难点。但是实际还没有探讨实现系统的架构,以及如何选型。是使用ELK呢还是GraphiteTICKPrometheus?这么多技术架构,每个架构负责怎样的功能,又该如何选型呢。