可观测平台下告警降噪实践——GOPS分享

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
云拨测,每月3000次拨测额度
简介: 本文介绍阿里云SLS丁来强(花名成喆)在GOPS2021上海站分享时的议题内容,结尾有PPT下载链接。

BC8I0148.JPG

背景与趋势

这部分首先介绍了数字化下系统运维对工程师挑战(包括一专多能、需要更多观测分析),然后介绍了可观测的定义(更早、更全面数据的采集与观测),再到可观测系统的挑战(各种监控系统并存孤立以及门槛高),并总结了传统告警运维系统的六大痛点。详细内容可以参考这篇的背景部分,这里不再赘述。

被观测系统的复杂性:

各种孤立并存的监控系统:

传统监控运维系统的痛点:

方案基础

本节介绍了整体方案的基础前提:一个统一的可观测平台。以便在这个基础上再去解决告警风暴、监控质量差、通知单一重复等问题。

典型的可观测平台解决方案

基于上一节的背景和趋势介绍,我们可以看到一个典型的可观测平台应该具备这样的特性:

  • 对包括日志、时序、链路、跟踪和事件的统一的存储、处理、分析、展示以及响应的基础中台能力。
  • 支撑上层业务方(开发运营、监控、安全、用户运营)的观测分析需求(与定制能力)。
  • 同时可以对接上下游系统的生态支持。


数据统一接入与查询分析

这样的可观测平台,具备将各种异构的数据(日志、指标、时序、事件等)进行统一存储和管理的能力:

基于统一的存储,我们可以构建统一的查询和分析语法,从而一套语法适配不同的数据,并且让不同的数据之间进行联合查询也变成了可能。如图,可以以标准SQL为基础,进行了部分DSL扩展和 SQL 函数扩展,并融合了PromQL,从而让不同类型的数据查询和分析变得统一。

例如下面的例子:

  • 我们可以通过标准 SQL 语句对日志进行查询分析
  • 通过 PromQL 扩展的 SQL 函数对指标数据进行分析
  • 再通过嵌套查询,对指标数据的分析结果进行再聚合
  • 还可以进一步通过机器学习函数,给查询和分析赋予 AI 的能力


告警统一监测与管理通知

在云原生可观测性平台上我们就提供了一套现代化的智能运维告警系统。新版告警提供对日志、时序等各类数据的告警监控,亦可接受三方告警,对告警进行降噪、事件管理、通知管理等

可以看到新版告警由4个模块组成:

  • 告警监控:对存储在平台中的各类数据进行监控,产生高质量的告警。
  • 开放告警:接收平台外的现有十几种监控系统的告警(例如Zabbix、Grafana告警、Promethues告警等)
  • 告警管理:对上述两种方式的告警进行集中管理:包括路由合并、降噪抑制、事务管理等。
  • 通知管理:对告警进行人性化通知多渠道通知,包括动态分派、告警升级、节假日与值班组等。


统一的可观测态势大盘

在此基础上我们就可以得到基于业务的统一的告警态势大盘:


智能监控

有了一个可观测基础平台,现代化告警系统就可以从两个环节对告警降噪进行治理

  1. 首先是告警监控环节,也就是告警产生的源头进行降噪。
  2. 其次是告警管理环节,也就是对来源前一个环节(告警监控+开放告警接收的三方告警),进行全局基于业务的降噪


传统告警监控的困难和挑战

这里我们详细解读一下传统告警监控的挑战:

  • 监控对象和监控指标急剧增加。如果要全方位的覆盖这些监控对象和指标,需要配置大量的监控规则,并且它们的阈值也可能是各不相同的,因此会有很大的工作量。

  • 监控规则无法自适应:基于人为定义的阈值,很大程度上依赖于人的经验,随着系统的演化和业务的发展,这些规则往往不能很好地适应,由此不可避免地导致漏报、误报等问题。无法做到数据的自适应,因此需要人为介入,不断调整阈值。例如下图:

  • 上面是一个指标,有规则性的毛刺。如果通过阈值来判断是否需要告警,当一个毛刺点异常的时候,可能由于不满足阈值,导致告警漏报。
  • 下面是另一个指标,可能随着系统的进化,新版本发布之后,该指标的值会发生一个陡增。此时如果是固定阈值告警的话,会将陡增之后的所有数据都认为是异常点,导致告警频繁触发。此时需要人为介入去调整阈值。
  • 监控规则泛化能力弱:不同的业务、甚至同一业务的不同版本,指标的规律性、阈值都有可能是不同的。因此我们需要为不同的业务、不同的版本去做监控规则的适配。例如下图,虽然两个指标整体上有着比较相似的波动规律,但是由于它们的取值范围、以及局部的抖动情况会有差异,因此需要分别去做监控。



智能监控1:智能巡检

基于上述问题,智能巡检可以一定程度的优化,其具备以下几个优势:

  • 智能前置:现在有很多系统是在告警触发后,进行智能的管理,但是这无法避免告警误报、漏报等问题。智能巡检可以将 AI 的能力前置到监控层,从而在源头上避免潜在的告警问题,挖掘出真正有效的数据价值。
  • 监控自适应:可以基于历史数据自动学习和进化,进行动态的阈值判断,从而让告警更加精准。另外对数据的学习也是实时的,可以更加快速地发现异常问题。
  • 动态反馈:除了自动学习之外,还可以通过用户的反馈,对告警进行确认或者误报标记,将 AI 能力与人的经验相结合,相辅相成,进一步完善模型,减少误报。

在一些数据波动比较大,指标没有固定阈值的场景下(例如用户访问量、外卖订单量等),智能巡检的优势可以得到很好的体现。例如下图,指标本身呈现出周期性地波动,假如一个新版本上线了之后,由于bug导致网络流量异常抖动。如果基于固定阈值来判断,此时处于指标值的上下界范围内,就很难发现问题;但是基于智能巡检,就可以很容易地判定这是一个异常点。


实现思路

智能巡检的基本思路如下:

我们采用无监督学习算法,自动识别实体的数据特征,根据数据特征选取不同的算法组合,针对数据流实时建模,完成异常任务检测。并根据用户的打标信息(对告警进行确认或者误报反馈),训练监督模型,对算法进行不断优化,从而提高监控的准确率。

目前异常检测我们使用了两种算法,它们的比较如下:

流式图算法

流式分解算法

适用场景

适用于一般性时间序列的异常检测场景,包括:

  • 机器级别的监控指标的异常巡检,例如CPU占用率、内存利用率、硬盘读写速率等。
  • 业务指标的异常巡检,例如QPS、流量、成功率、延时等。
  • 黄金指标的异常巡检。

适用于对具有周期性的数据序列进行巡检,且要求数据的周期性较为明显。例如游戏的访问量、客户的订单量。

相关论文

Time-Series Event Prediction with Evolutionary State Graph

RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series


智能监控2:增强型规则引擎监控

对于时序类异常检测,智能巡检可以比较好的解决。但对于以下类型的监控,还需要使用增强型规则引擎来减少噪音:

  • 经典类监控:确定性的经典规则(例如基于关键字异常的监控)、需要支持多目标、自动恢复等经典功能的监控(例如某台机器宕机监控以及上线的恢复通知),并在此基础上使用黑白名单、机器学习算法降噪的监控。
  • 业务类监控:基于业务的定制化程度高的监控,例如大量异常非常见客户国家的访问,某些非VIP客户的购买异常记录等。
  • 安全类监控:基于安全规则的监控(例如海量数据库拖库监控)、配置合规审计监控(例如创建了公网IP的ECS网络主机实例需要告警)等。

使用基于统一的查询分析引擎以及扩展的告警引擎(包括多源协同、数据感知和灵活规则等),可以很好的覆盖这类场景并降低噪音:

智能告警管理

智能告警管理从以下出发点进行降噪:

  1. 智能监控环节可以较好的降低噪音,但来源于三方的告警一般是未经过这样的处理,因此需要在智能告警管理环节进行降噪。
  2. 智能告警监控环节在宏观方面还是可能也产生较多告警(例如多个业务并行),告警智能管理也可以进一步合并或协同降噪。
  3. 全局角度,客户还需要借助智能管理完成在分派(值班)、升级、通知渠道、节假日感知层面的进一步降噪优化。

我们可以通过告警智能管理来解决上述问题,如图所示:

智能降噪机制

告警智能降噪包含以下几种机制:

  • 智能合并可以有效的将重复的大量的告警合并,减少告警风暴。例如某服务的2个主机从20:00和20:01分别每分钟不停触发高CPU告警,收到2小时125条告警,经过降噪仅发送4次。

  • 关联抑制可以有效的将许多关联的告警自动抑制,减少告警风暴,例如某K8S集群发生OOM后,自动发送一条告警,而该集群上海量的上层应用告警会被自动抑制:

  • 灵活静默可以根据配置在特定时间、节假日等屏蔽掉特定的告警通知,减少告警风暴的干扰:

动态分派

动态分派保证了有效触达外,也可以通过以下方式降噪:

  • 多渠道:支持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道,同时还支持通过自定义 Webhook 进行扩展。可以根据告警的严重度和特定场景动态以合适的渠道通知到人。
  • 动态通知:可以根据告警属性动态分派通知,将正确的告警在正确时间给正确的人,有效减少无效通知。例如:测试环境的告警,通过短信通知到张三,并且只在工作时间通知;而生产环境的告警,通过电话通知到张三和李四,并且无论何时,都要进行通知。
  • 通知升级:长时间未解决的告警要进行升级,而不是持续的无效重复通知。例如某告警触发后,通过短信通知到了某员工,但是该问题长时间未被处理,导致告警一直没有恢复,此时需要通知升级,通过语音的方式通知到上一层负责的领导。

值班管理

许多运维团队由多人负责告警的处理,可以通过值班管理按需分派通知,减少对非值班的同学的告警噪音影响。值班管理在常规功能外提供了灵活的机制进一步提高降噪效果:

  • 节假日感知(例如法定节假日与自定义感知换班)
  • 工作时间感知(例如自定义上班时间才换班)
  • 代班与以上或细腻度支持(例如特定时间段的换班)


总结

本议题介绍了在一个现代化的可观测平台上告警降噪的整体方案与技术实践,平台提供了包括日志、时序、链路、事件等统一的数据接入与存储、提供了统一的查询分析语法,并在此基础上分别从智能告警监控(包括智能巡检与加强引擎)与智能告警管理(包括智能降噪、动态分派与值班管理等)环节展开介绍了如何解决传统告警的告警风暴、监控质量低、不人性化等典型问题。

参考

目录
相关文章
|
1月前
|
运维 监控 Cloud Native
SysOM 的可观测和智能监控实践
随着云原生的发展,给运维带来了什么挑战?
|
9月前
|
SQL 数据采集 运维
「应用实时监控 ARMS 」斩获「根因分析技术」先进级认证
「应用实时监控 ARMS 」斩获「根因分析技术」先进级认证
|
9月前
|
Kubernetes 监控 安全
eBPF ,让观测性走向神坛
Hello folks,我是 Luga,今天我们来介绍一下“下一代”可观测性工具 - eBPF,作为一种强大的内核技术,eBPF 启用了全新类别的可观测性模型,除此之外, 其程序能够无缝地与各种内核关联,以收集有关正在发生的事件数据。
182 1
|
11月前
|
Arthas 缓存 Prometheus
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践1:如何基于OpenTemeletry和ARMS实现全链路的追踪和应用诊断【下】
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践1:如何基于OpenTemeletry和ARMS实现全链路的追踪和应用诊断【下】
456 0
|
11月前
|
监控 Java
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践1:如何基于OpenTemeletry和ARMS实现全链路的追踪和应用诊断【上】
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践1:如何基于OpenTemeletry和ARMS实现全链路的追踪和应用诊断【上】
387 0
|
11月前
|
运维 机器人 调度
《阿里云可观测最佳实践》——7.节卡机器人(下)
《阿里云可观测最佳实践》——7.节卡机器人(下)
111 0
|
11月前
|
运维 机器人
《阿里云可观测最佳实践》——7.节卡机器人(上)
《阿里云可观测最佳实践》——7.节卡机器人(上)
122 0
|
11月前
|
弹性计算 Prometheus 监控
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践2:如何基于Prometheus和Grafana做统一的监控和告警
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践2:如何基于Prometheus和Grafana做统一的监控和告警
231 0
|
数据采集 运维 监控
治理告警风暴,告警降噪的一些典型手段
很多公司希望提升服务稳定性,而上线了各类监控系统,指标的、链路的、日志的,而且只是指标层面可能就会有多个监控系统,这么多监控系统、这么多监控目标,如果没有良好的治理,很快就会产生告警风暴的问题,如何通过一些手段达到告警降噪的效果呢?
316 0
|
2天前
|
存储 SQL Prometheus
幸福感大提升-SLS时序存储体验升级
时序引擎在可观测场景中的重要性Metrics作为IT可观测性数据的三剑客之一,是可观测场景的重要组成部分,相比Log、Trace数据,具备成本更低、数据源更丰富、适用面更广的特点,SLS在2年多前发布了时序存储引擎,并完全兼容了Prometheus的语法。目前已经有1万+的用户、10万+的实例,每天...
幸福感大提升-SLS时序存储体验升级