1.概述
对于软件开发工程师来说，并不是将软件开发完成上线就完成了工作。重要的是上线之后对软件进行监控，并配置相关报警，保证服务的高可用。
监控可以帮助团队了解系统的状况，实时跟踪和记录服务的性能指标。当服务出现异常或者相关指标超过预设的阈值时，报警可以主动通知运维团队或相关人员，使得他们能够尽快采取行动解决问题，减少或避免对业务的影响。监控是过程，报警是结果；报警是发现问题的一种手段，监控是实现这一手段的前置依赖。
2. 目标
-
终极目标：保证线上服务的高可用，减少故障处理的时间。
-
过程指标：
- 准确率： 正确报警数量/（正确报警数量+误报警数量）
- 召回率：正确报警数量/（正确报警数量+漏报警数量「未通过报警而导致的事故」）
在监控报警体系中，准确率可以保证相关报警都是有效的，而不会导致冗余的报警噪声。召回率保证了报警的全面性，避免相关指标没有覆盖到。
3. 建设流程
报警监控建设本身是一个持续的过程。随着业务的不断发展，其对应的监控报警指标也会发生相应调整。整体可以按照四个过程不断循环：梳理指标、监控建设、报警建设、调整指标。
梳理指标
为了保证监控报警的全面性，可以从以下几个方面来整理相关指标：
- 业务指标
不同的业务场景对应着不同的业务解决方案，服务的最终目标是保证业务的稳定可用。首先要明确业务的最终目标。对目标进行拆解，从而细化为具体的业务指标，保证业务指标的稳定。指标的意义在于度量一个功能的用户体验，需要我们细化拆解，找到定义和度量用户体验的合理方式。
例如，我们做的是一个博客。产品指标是提升用户留存。我们的业务指标则包括登录失败率、博客发布失败率、博客展示失败率、页面渲染时长等。
- 应用层指标
应用层监控往往采用 RED 方法，其适用于云原生应用以及微服务架构应用的监控和度量，主要关注以下三个关键指标：
-
Rate 请求速率：服务每秒接收的请求数，为性能监控和故障排除提供上下文
- 请求速率：每秒请求的次数，即 qps
- 请求速率波动：请求速率的波动变化情况，常见的有环比、跌零检测
-
Errors 错误率：每秒失败的请求数，主要用于识别、定位、修复系统问题
- 请求失败率：时间范围内服务所有请求的平均失败率，表示服务的稳定状况
- 请求错误分布：不同类型请求错误的数量和比例，按照错误类型进行聚合，发现系统问题
- 正确率/错误率波动：正确率/错误率的波动变化情况
- 错误日志率：单位时间内服务/接口产生的错误日志条数
- 错误日志波动：错误日志产生速率的波动变化情况
-
Duration 请求耗时：每个请求的耗时，为用户体验和性能监控提供重要依据
- 平均处理耗时：时间范围内所有请求的平均耗时
- 最大处理耗时：时间范围内的最大请求耗时
- 响应时间分布：不同请求的处理耗时分布情况
- 请求耗时波动：请求耗时的波动变化情
-
中间键指标
-
服务进程：使用 go 开发服务端进程为例
- gc 耗时：排查因 gc 导致的服务不可用
- gc 频率: 观察 gc 触发频率
- goroutine 数量：查看是否有 goroutine 泄漏
- 内存申请：查看进程对应的内存申请
- panic 次数：服务中 panic 触发次数
-
持久化存储：以 mysql 为例
- 慢查询
- 主从延时
- 锁等待
- 事务耗时
- 连接数过多
-
缓存
- 缓存命中率
- 热 key：访问频率特别高的 key, 会导致单实例负载过高
- 大 key: 增加缓存实例复杂
- key 逐出过多: 过多的 key 被逐出会导致混存失效
- 内存使用率
-
-
系统层指标
系统层监控往往采用 USE 方法，其侧重于监控系统资源，关注系统组件的运行状况，主要关注以下三类指标：
-
Utilization 利用率：用于处理工作的资源数量，资源包括：CPU、内存、硬盘、网络等
- CPU 利用率：单位时间内，pod 内进程使用 cpu 核心数/总核心数，比较粗略的统计
- 内存利用率：系统中内存的使用情况
- 磁盘利用率：系统中磁盘的使用情况
- 网络带宽利用率：系统中网络带宽的使用情况
-
Saturation 饱和度：由于缺乏可用资源而导致系统无法处理的工作量，类似于积压。饱和通常表现为排队或延迟，并可能导致工作错误
- CPU 负载：在单个时间点使用或等待使用一个内核的进程数。如果大于 1，则表示 CPU 的工作量超过了处理能力
- CPU 受限次数：CPU 资源受限次数，即 pod 在一个 CPU 时间片内，超出了分配的 CPU quta 导致受限
- IO 等待时间：IO 操作等待时间
-
Errors 错误：资源出现问题，导致系统报错乃至于不可用
- 内存 OOM 次数：发生内存溢出问题的次数
- 磁盘写入错误次数：磁盘写入操作发生错误的次数
- 网络丢包率：网络数据包丢失比率
监控建设
监控就是对上面的指标进行展示，可以快速掌握基础的业务信息和服务的各项指标是否健康，同时可以用于服务排查线上问题。在搭建监控看板时要记录重点，而不是罗列全部内容。布局要合理，搭建看板时要明确想通过看板发现什么问题。
例如：想搭建一个看板，对整体服务有个概览。通过下面的看板，可以直观知道应用层、基础组建、业务上对应的状态。当服务可用性降低时，即出现调用失败率下降，可先看看是特定接口、特定 pod、特定集群的问题；同时查看对应的 qps 是否上涨；系统负载是否升高；排除这些问题之后，可以去看下是否是下游服务存在问题。
报警建设
监控看板可以帮助我们对当前服务状态有一个直观感受，但是它并不能帮助我们主动的发现问题。这时候就需要报警，当线上出现问题时，能够及时的通知相关同学进行处理。报警主要关注三个方面。服务 SLA：例如，接口成功率，它保证整个服务链路是通的，无故障的；数据波动：用于发现异常的接口流量，发现一些流量上非预期的行为；业务指标异常：用于发现业务上非预期行为。
-
报警规则
- 规则名：好的规则名可以提高报警的处理速率。命名可以包含「业务场景」+「指标」+「阈值」。例如：用户登录成功率低于 98%。
- 阈值：一个合理的阈值可以避免冗余的报警，同时需要根据业务的不断发展调整对应的阈值。例如：产品发布了一个新的活动，文章发布接口同比上涨了 20% 则是符合预期的，无需进行处理。
- 检测周期：由于指标对应的场景不同，往往需要不同的检测周期。一般重要性较高的指标，需要较高的检测频率，便于及时发现问题。
-
报警通知
- 报警处理
满足了报警规则之后则需要通知到具体的人进行处理。为了保证问题有人及时进行跟进处理，需要确定明确的值班制度，可以同时安排两位同学「一主一备」。同时明确值班同学的职责，针对值班期间遇到的问题进行跟进，明确报警原因、处理进度、处理手段。最后按周或月维度统计准确率和找回率。
总结
对于研发同学来说，服务上线需要及时进行监控和报警的建设。本文从业务视角出发，主要介绍了监控报警中的常用指标、搭建监控看板、报警配置，完善服务的监控报警体系。