监控对象

一般可分为四类：

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

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

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

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