在运维中,告警的重要性不言而喻,它既能对某些潜在的问题提前预警;也能对已发生的问题提供信息,便于快速定位和及时处理问题。

告警的维度

我们把告警分为系统告警和业务告警。

很多监控和告警系统默认都支持系统的告警,如:

  • 硬件异常告警:磁盘,内存,网卡
  • 系统指标维度告警:CPU/内存/磁盘/网络流量/链接数等
  • 系统日志告警
  • ……

业务告警需要根据自身业务需求进行配置,甚至需要做定制化,如:

  • 业务进程存活告警
  • 业务日志告警
  • 访问时延告警
  • 服务异常告警
  • ……

系统告警往往很直观,现象很明显,容易定位出原因;业务告警的现象往往有有种因素引起,一般需要深入定位原因。

此外,系统异常往往会诱发业务异常,二者存在因果关系。每当收到系统告警时,我们应该能初步的判断系统异常对业务层面的影响;每当收到业务告警,我们可以结合是否有系统告警,以便快速定位问题。

告警配置的原则

每当告警发生时,值班同学需要暂停手头工作,查看告警。这种中断非常影响工作效率,增加研发成本,特别对正在开发调试的同学,影响很严重。所以,每当我们收到告警时,我们希望它能真实的反映出异常,即告警不能误报(对正常状态报警);每当有异常产生时,报警应该及时发出来,即告警不能错报(错过报警)。但是误报和错报总是一对矛盾的指标。

  • 从监控范围出发:为了避免误报,就必须增加更多的监控指标,但是增加监控指标后,又带来更多误报的可能性。
  • 从阈值角度出发:对于阈值类监控,阈值过高,误报概率低,但是错报概率高;反之,阈值过低,误报概率低,但是错报概率高;

配置告警之初,我们应尽可能扩大监控告警覆盖面,选取保守的阈值,如此是尽可能避免错报。后续定期对告警进行统计分析,对误报的告警,该屏蔽就屏蔽,该简化就简化,这是一个相对长期的过程。苦李本人结合项目经验和《Google SRE》观点,推荐如下告警设置原则:

  • 真实性:告警必须反馈某个真实存在的现象,展示你的服务正在出现的问题或即将出现的问题。
  • 表述详细:从内容上,告警要近可能详细的描述现象,比如服务器在某个时间点具体发生了什么异常。
  • 可操作性:每当收到告警时,一般需要做出某些操作,对于某些无须做出操作的告警,最好取消。比如磁盘 IO 量瞬间很大,CPU 使用率瞬间飙高,我们往往不会做出操作,对某些业务而言,这类告警意义就不大了。可操作性原则尤为重要,遵循这条原则往往能避免很多误报。

虚拟化告警配置的一些经验

虚拟化集团提供云计算相关虚拟机和容器产品,集群规模近千个物理节点,集群有数十种管理服务。对我们而言,关心如下告警:

  • 所有节点的硬件状况
  • 所有节点某些系统指标,比如内存,磁盘
  • 所有节点进程存活状况
  • 所有节点某些特定日志
  • 中心节点日志
  • 服务可用性:TBD

为了保障业务稳定,我们尽可能的把监控覆盖到最大范围,但是也带来了许多误报,平均每天几十条告警非常影响值班同学的效率。因此我们定期统计和分析告警频率,对于告警频率高的应用,是问题的则把问题解决,误报的告警或优化,或取消。具体如下:

  • 优化告警阈值:适当提高 内存/CPU/网络 IO 告警阈值。
  • 优化日志级别:优化不合理的日志级别,把部分 ERROR 级别的日志调整为 WARNING。
  • 屏蔽某些日志:对难以调整日志级别的应用,根据关键字屏蔽某些频繁的日志告警。
  • 预警增强:对于某些影响业务方的操作,提供预警。
  • 增强紧急预警:有些硬件故障会出现反应在 /var/log/messages 中,根据关键字匹配硬件类告警,以便及时处理。

标签: 运维

添加新评论