服务监控常见类型

监控概念

监控对象

既然要监控，那么要监控哪些对象呢?(从上至下)

基础监控

通常是抬对服务器本身的健康状况的监控。主要包括CPU利用率、内存使用量、I/O读写量、网卡带宽等。对服务器的基本监控也是必不可少的，因为服务器本身的健康状况也是影响服务本身的一个重要因素，比如服务器本身连接的网络交换机上联带宽被打满，会影响所有部署在这台服务器上的业务。

用户端监控。

通常是指业务直接对用户提供的功能的监控。以京东首页为例，它向用户提供了聚合关注的所有人的商品并按照某种规范浏览的功能，对首页商品显示功能的监控就属于用户端的监控。

接口监控。

通常是指业务提供的功能所依赖的具体RPC接口的监控。继续以微博首页Feed为例，这个功能依赖于用户关注了哪些人的关系服务，每个人发过哪些微博的微博列表服务，以及每条微博具体内容是什么的内容服务，对这几个服务的调用情况的监控就属于接口监控。

资源监控

通常是指某个接口依赖的资源的监控。比如用户关注了哪些人的关系服务使用的是Redis来存储关注列表，对Redis的监控就属于资源监控。

监控指标

响应时间

大多数情况下，可以用一段时间内所有调用的平均耗时来反映请求的响应时间。但它只代表了请求的平均快慢情况，有时候我们更关心慢请求的数量。
为此需要把响应时间划分为多个区间，比如0~ 10ms、10ms~ 50ms、50ms~ 100ms、100ms~500ms、500ms以上这五个区间，其中500ms以上这个区间内的请求数就代表了慢请求量，正常情况下，这个区间内的请求数应该接近于0;在出现问题时，这个区间内的请求数会大幅增加，可能平均耗时并不能反映出这一变化。除此之外，还可以从P90、P95、P99、P999角度来监控请求的响应时间，比如P99=500ms，意思是99%的请求响应时间在500ms以内，它代表了请求的服务质量，即 SLA.

请求量

请求量监控分为两个维度，一个是实时请求量，一个是统计请求量。

实时请求量用QPS (Queries Per Second)即每秒查询次数来衡量，它反映了服务调用的实时变化情况。

统计请求量一般用PV(Page View)即一段时间内用户的访问量来衡量，比如一天的PV代表了服务一天的请求量，通常用来统计报表。

错误率(失败数)

错误率的监控通常用一段时间内调用失败的次数占调用总次数的比率来衡量，比如对于接口的错误率一般用接口返回错误码为503的比率来表示。

系统运行的繁忙程度、健康程度，反应在一系列的运行期指标上，不管是CPU负载过高、磁盘I/O过于频繁、或者内存使用过多，导致频繁的FGC，或者qps过高，都会导致系统的服务质量下降，因此当对应的指标超过假定的阈值的时候，开发或者运维人员必须接入进行处理。