如何做好业务监控

2022年5月11日 277次阅读来源: Rylan11

系列文章目录

文章目录

一、什么是监控？

1.1. 定义

     监控是整个运维乃至整个产品生命周期中最重要的一环，事前及时预警发现故障，事后提供详实的数据用于追查定位问题。

1.2. 目标

实时&持续的反馈系统情况
保证业务持续稳定&安全
如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

引言：
可以从三个方向去考虑：

1、减少故障发生的可能

2、减少故障恢复时间

3、降低故障的外部影响

系统可用性

99.999 5.25 min
99.99 52.5 min
99.9 8.75 hour

二、监控的指标

硬件层(主机)、系统层(容器层)、应用层、业务层；

2.1.指标

硬件层

 服务主机，主机层黄金指标包括：CPU使用率（Total，User，System），CPU load，Memory（total，used，rss），网络流量，Disk-IO count/Traffic（TX，RX），file_node

主机Top 命令使用详解https://blog.csdn.net/Rylan11/article/details/81608286

系统层(容器层)

容器资源被内核CGroup限制，它的黄金指标与主机系统指标接近。容器黄金指标包括 CPU使用率(Total, User, System), CPU Throttling Time，CPU Throttling Count ，网络流量（TX，RX），Memory（limit，used，rss），Disk-IO count/Traffic（TX，RX）

CPU 压制时间/压制次数，衡量CPU是否达到瓶颈的最直观指标。

参考：
cfs_period_us & cfs_quota_us
https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718

应用层

  关键的黄金指标包括 （1）响应时间（2）流量/吞吐（3）依赖 错误率/成功率(系统错误码 4XX 5XX;错误日志 )  (4)  错误日志

(1) 响应时间：

   又分为客户端侧的响应时间统计和服务端侧的响应时间统计。客户端侧站在调用方的视角计算端到端的响应耗时，包括网络交互耗时和服务端的执行耗时。服务端侧的响应时间仅包括服务提供方的响应时间。服务端的响应时间细化后又可继续拆解，例如服务队列等待时间，服务方法，前后置filter执行时间，业务方法执行时间等
  更进一步，在有条件的情况下还需要区分不同失败类型的请求响应时间，例如满足fail-fast失败条件的请求会被快速返回，它的响应时间反而会很快。而超时的请求，因为直到满足超时才返回响应，响应时间会较慢。针对不同失败类型的错误码来统计响应时间将会更有效的帮助研发和运维团队甄别应用的性能问题

(2)流量：

    是衡量流经网络的请求数量(QPS/QPM)。这些可能是对web server的HTTP请求，或对服务框架的RPC请求，也可能是发送到处理队列的消息。高峰流量的时间可能会对基础架构造成额外压力，并可能将其推向极限，从而触发下游效应。这是一个关键信号，因为它可以帮助系统区分容量问题和不正确的系统配置，即使在低流量时也可能导致问题。对于分布式系统，它还可以帮助您提前规划容量以满足即将到来的需求

(3) 错误率主要统计5xx/4xx二个错误指标的数量，5xx指服务端出错，4xx指客户端出错。

(4) 错误日志数

对于Java应用：
JVM GC Count，JVM GC Time，JVM Heap Usage都是最核心的JVM黄金指标，还包括：线程池数、sql耗时、redis 耗时等。

业务层

 每个业务层都有自己业务场景下核心的业务指标，直接体现业务的监控状态。  订单数量/成功率 、 支付数量/成功率 、下单的成功数/失败数

2.2 精度

秒级

 秒级指标的特点是实时性高，成熟的监控系统，能做到秒级粒度，秒级统计延迟。但秒级粒度也存在缺陷，秒级数据无法很好的体现趋势和走向，例如较小幅度的阴跌场景，秒级很难发现。同时秒级的指标的写入压力和存储成本较高，在同等维度下是分钟级的60倍。而且秒级粒度的数据没有后续的统计分析的价值，往往保留较短的实效性

分钟级

  分钟级粒度的指标也是大部分监控系统推荐和默认的监控粒度，是监控实效性和实施成本的一个合理权衡，经过几个连续分钟级指标的观测，可以基本体现趋势和走向。但分钟级粒度的指标存在一定的延时性，同时由于经过分钟级的均值统计后，其数据会丢失部分精确性，无法精确观测到毛刺现象

2.3 统计方式

     通常而言，监控时序数据往往是一个波动的数值。所以当我们需要处理性能数据时，通常需要借助于统计的手段来辅助我们分析。常见监控时序数据的统计方式有原始值(observation), 最大值/最小值(max/min), 总和(sum)，平均值(avg), 数量(count), 百分比(%), 百分位(percentile)

    面对不同类型的监控时序指标，采用合理的统计方式非常关键，否则容易引入噪音，误导决策。例如统计某应用集群级别的响应时间，如果只统计平均响应时间，统计值极易被集群中某几个极高或极低的极值干扰，从而导致均值数据偏高或偏低，无法很好体现集群整体情况。这种情况下，采用百分位统计就非常适合，通常可采用50分位，95分位，99分位三挡分位数，能很好的排除极值干扰，体现集群整体真实的响应时间水位。

埋点工具：
Metrics提供了Gauge、Counter、Meter、Histogram、Timer等度量工具等。
Micrometer (多 tag)、dropwizard-metrics

Metrics 介绍：

https://blog.csdn.net/ruthywei/article/details/80967063

PT 介绍：
https://blog.csdn.net/Rylan11/article/details/101458344
https://stackoverflow.com/questions/17435438/what-do-we-mean-by-top-percentile-or-tp-based-latency
https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/

三、怎么做

3.1 监控痛点

  大型TO C 网站，停摆 几分钟甚至十几分钟，可能给企业带来几十万甚至几百万的经济损失，而且带来的是平台商誉和用户体验上的损失。

《如何做好业务监控》

第一发现问题慢，业务曲线一般 1 分钟更新一次，有时候因为正常的业务抖动，还需把这种情况确认排除掉，带来很大的滞后性。

第二定位问题慢，系统庞大，大量的人需要介入排查，而且由于依赖复杂，需要反复沟通才能串起来。一方面无关的人卷入进来，人员浪费，另一方面沟通效率低，定位问题时间长。

第三解决问题慢，当定位到问题，对系统进行调整后，验证问题是否解决也不是容易的事。更新大量机器需要时间，然后需要各个研发确认系统有没问题，还要通过滞后的业务曲线看业务是否恢复。有时病急乱投医，往往会发生二次事故，这里的问题是缺乏实时直观的反馈途径。

3.2 痛点解决

《如何做好业务监控》

这里有几个关键词：实时，整体，直观。
首先要实时，马上知道系统当前是否有问题。

 然后要整体监控，把各个部分放一起，能够迅速识别哪些部分是好的，哪些部分不好。有问题的部分，又有可能是它依赖的部分引起的，因此依赖关系也要直观展示，便于定位真正的问题源。

 最后要直观，发生紧急事故时，人脑处于错乱状态，这时候，不能借助专业的头脑或严密的分析才能判断。哪些部分有问题，问题严重程度，以及出问题的原因必须一目了然，不能连累他人。谁家的娃有问题，各找各妈，各回各家。

文章参考：
https://www.infoq.cn/article/pulzj6tjdblexcfehaws

3.3 监控大盘

关键词：

链路成功率、业务成功率、强若依赖、错误原因。

参考：
《如何做好业务监控》

成功率：成功数/总数，不要小看这简单的公式，但是这其实体现了我们刚刚说的 “直观”。而且我们会把所有的我们依赖和相关的都监控起来，也就体现了 “整体”，例如：DB 慢查/异常、redis 异常/慢查/大key、强/若依赖服务、以及错误码等。

四、工具推荐

4.1 监控工具

Zabbix、grafana、CAT、open-falcon(小米)。

总结

以上就是我们强调的在做系统的时候，如何做好业务上的监控，还需要细分的分析业务，把需要我们经常关注的数据监控起来，并且配合适当的报警机制(成功率同比/环比下跌、进入订单数减少 X%、错误率增多等)，有好的监控和报警是我们进行稳定性建设的抓手和参考依据。