监控告警

1.监控

1.1 监控的目的

  • 了解业务量级增长
  • 感知系统健康度
  • 告警 -> 及时发现问题

可用性量化: MTTF, MTTR, SLA, SLO

1.2 好的监控体系应该做到哪些?

  • 指标全面,但不冗余.
  • 报警敏感,但不误报
  • 自动发现问题,以及分析原因

1.3 监控指标

USE (Utilization Saturation and Errors): 将注意力集中在处理工作负载的资源上。目标是了解这些资源在存在负载时的行为方式。

  • 使用率,表示资源用于服务的时间或容量百分比。100% 的使用率,表示容量已经用尽或者全部时间都用于服务。
  • 饱和度,表示资源的繁忙程度,通常与等待队列的长度相关。100% 的饱和度,表示资源无法接受更多的请求。
  • 错误数表示发生错误的事件个数。错误数越多,表明系统的问题越严重。

REDRequest Throughput,Error Rate, Duration Time): 它是由资源提供服务的工作负载行为的外部可见视图

四个黄金信号: 延迟(Latency),流量(Traffic),错误(Errors)和 饱和度(Saturation)

1.4 监控体系

需要关注的点非常多(机器指标、数据库监控、接口性能、业务指标、异常日志等等),越想越多,越理越乱。 所以需要分层监控

2.告警

目标: 避免误报、 漏报

2.1 报警级别规范

每一条告警都有自己的级别,大部分公司对告警分级都有设定,例如某司对告警的级别设定为: P0、P1、P2、P3。不同的告警级别代表通知范围不同、处理紧急度不同。

告警级别 告警含义 通知速度 响应速度 误报概率
P0 大事故的发生,需马上处理 电话 + 短信 + ** + 邮件 第一时间做出响应并处理,响应时间 <=10 分钟 0 误报,告警意味着严重的事故 100% 发生
P1 核心路径有波动,需马上处理 短信 + ** 收到报警之后立即响应,响应时间 <=30 分钟 0 误报,告警意味着核心接口服务不稳定,有事故或有抖动
P2 服务有波动,需关注 ** 观察系统指标,快速处理,响应时间 <=1 小时 允许少量误报
P3 服务异常信息通知 ** 尽快处理 允许少量误报

对于不同级别的告警一般是这么进行区分:

  1. 不同阈值相同持续时间。 比如一分钟内 500 次异常定为 P1、1000 次异常定为 P0
  2. 相同阈值不同持续时间。 比如 P2 报警持续 5 分钟升级为 P1、P1 报警持续 5 分钟升级为 P0

2.2 告警治理

保证告警精准触达用户,通过技术手段、数据运营,减少冗余告警,提升告警有效性。

2.3 最佳实践

  1. 配置有效的告警,需要分析指标特征来对症下药,避免一刀切,千篇一律。
  2. 突增突降类指标的监控,需要先定义出“什么是异常?”,再针对异常进行监控,避免直接对原始的、不稳定的指标进行监控告警。
  3. 告警分优先级配置时,针对不同优先级侧重点不同,高优告警侧重于准确且及时,低优告警可接受一定的延迟,换取更低的误告警。
  4. 告警分时段配置时,不同时段侧重点不同。低频时段阈值宽松处理(避免大量误告警)、高频时段调小检测窗口严格处理(强调灵敏性)。
  5. 对于普适性的指标(Host、中间件等)告警配置,尽可能使用模板进行批量配置,以减少工作量,提升配置可维护性
  6. 对于不稳定的指标需进行归一化处理,转换为稳定指标(错误量 → 错误率),提升告警配置的有效性。
  7. 对于告警配置项,尽可能使用相对类配置(如波动百分比、基于基线的百分比等等),避免直接以某个固定值为基础进行比较配置。
  8. 监控做加法,告警做减法:监控开发是可以对系统从下而上,全面的进行监控,因为业务、系统是不断变化的,先期全面的监控能减少后续查漏补缺时的开发工作,并且更加全面丰富的监控指标有助于定位线上故障。但是在配置告警策略时,则应该提取当前关键核心的监控指标,来配置告警策略,减少无效告警数量。

难点: 接口差异,很难通用

Author: weibingo
Link: https://wbice.cn/article/监控告警.html
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.