实时警报通知:微信告警通知的重要性解析
1088
2023-03-12
本文目录一览:
其实在一线运维工作中,常常是福不双至,故障不单行。每有运维问题发生的时候,往往会密集发生多个告警。当这些告警来袭的时候,一线运维人员要针对它的类型、等级、告警对象和内容等进行检查并选用合适的方法来应对。
告警等级较高时,比如持续出错的应用告警,在查验后会立即分派通知相关的负责人在第一时间开具事件工单,做对应的流程追踪;而遇到低等级或次要的系统告警,则可以暂缓处置,留作观察。
传统的处置方式需要用经验来判断问题的影响范围和严重性,再通过人工进行派单以及通知下游处理人员,这样效率低下,无法满足现今业务响应速度的要求了。
究其原因,有些周期性发生的高频问题,往往并不是最棘手的,是可以延后处置的。反而偶发的问题,比较需要特别关注(如果这是原始定级较高的故障,更应该第一时间关注)。
所以,在告警发生的时候,可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别,看是否需要立即关注。再配合自动化工具,将推荐等级与原始等级都高的告警加上筛选规则,进行自动化开单处置。发现推荐等级与原始等级有背离的部分,可以筛选出来做复盘,对告警原始的等级进行优化,或者转化成升降级的规则逻辑来处置告警等级。
随着企业数字化转型的加速,IT运维数据也迎来了爆发式增长,随之产生了更多的挑战。对于众多企业来说,在IT建设的过程中都部署过各种运维工具,但各类监控数据只会保存并做固定阈值的简单告警,这些数据互相之间不通,无法对数据进行统一分析。传统运维工作依赖工程师的经验,难以复制和留存。
部署智能运维系统后,能有效地解决这些痛点,提高运维效率。即便是现有的工程师数量也能应对数百倍增长的数据和系统。
完整的智能运维系统包含统一告警分析:
(1)数字运维中台统一告警分析:提供数据治理服务、流批一体化服务和AI算法平台服务。
(2)统一监控中心:将监控对象与运维数据关联,实现对象视角的全面可观测性方案
(3)告警辨析中心:智能化集中告警,构建闭环告警管理
(4)指标解析中心:集中管理监控指标,AI算法智能化检测分析
(5)日志精析中心/日智速析专家:海量数据处理,串联及多维分析,实时聚类检测
(6)运营决策中心:多源数据接入,多设备统一管理,自定义观测场景
简单说来,就像智能手机最终替代传统手机一样,未来的IT运维也会由智能运维统领。除了实现运维工作的降本增效外,更能提供业务视角的观测,彰显运维数据的业务价值。(这一点已在多个客户处被验证)
测试环境中出现了一个异常的告警现象:一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态,但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计,告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能:1. 手动解决了告警2. 告警只产生了一次,第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间,如果还没到达自动解决时间,则将该时间重置为 24h 后首先,因为了解到测试环境没有手动解决过异常告警,排除第一条;其次,由于该告警持续处于 active 状态,所以不会是因为告警只产生了一次而接收到已解决状态的告警,排除第二条;最后,告警的告警的产生时间与自动解决时间相差不是 24h,排除第三条。那问题出在什么地方呢?
分析
下面我们开始分析这个问题。综合第一节的描述,初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长,导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手,找出告警在哪个处理阶段耗时过长。首先,一条告警的产生需要两方面的配合:
metric 数据
告警规则
将 metric 数据输入到告警规则进行计算,如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件,数据的提供和计算则会分开,数据还是由 Prometheus Server 提供,而告警规则的计算则交由 Thanos Rule(下文简称 Ruler)处理。下图是 Ruler 组件在集群中所处的位置:
看来,想要弄清楚现告警的产生到 AlertManager 之间的过程,需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是:You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。
不难推测,Ruler 应该是在 Prometheus 上封装了一层,并提供一些额外的功能。通过翻阅资料大致了解,Ruler 使用 Prometheus 提供的库计算告警规则,并提供一些额外的功能。下面是 Ruler 中告警流转过程:
请点击输入图片描述
请点击输入图片描述
首先,图中每个告警规则 Rule 都有一个 active queue(下面简称本地队列),用来保存一个告警规则下的活跃告警。
其次,从本地队列中取出告警,发送至 AlertManager 前,会被放入 Thanos Rule Queue(下面简称缓冲队列),该缓冲队列有两个属性:
capacity(默认值为 10000):控制缓冲队列的大小,
maxBatchSize(默认值为 100):控制单次发送到 AlertManager 的最大告警数
了解了上述过程,再通过翻阅 Ruler 源码发现,一条告警在放入缓冲队列前,会为其设置一个默认的自动解决时间(当前时间 + 3m),这里是影响告警自动解决的开始时间,在这以后,有两个阶段可能影响告警的处理:1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段(网络延迟影响)由于测试环境是局域网环境,并且也没在环境上发现网络相关的问题,我们初步排除第二个阶段的影响,下面我们将注意力放在缓冲队列上。通过相关源码发现,告警在缓冲队列中的处理过程大致如下:如果本地队列中存在一条告警,其上次发送之间距离现在超过了 1m(默认值,可修改),则将该告警放入缓冲队列,并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之,如果所有本地队列中的告警,在最近 1m 内都有发送过,那么就不会推送缓冲队列中的告警。也就是说,如果在一段时间内,产生了大量重复的告警,缓冲队列的推送频率会下降。队列的生产方太多,消费方太少,该队列中的告警就会产生堆积的现象。因此我们不难猜测,问题原因很可能是是缓冲队列推送频率变低的情况下,单次推送的告警数量太少,导致缓冲队列堆积。下面我们通过两个方面验证上述猜想:首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次,即平均 10s 推送一次。结合缓冲队列的具体属性,一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*10s = 16m,AlertManager 在接收到告警后早已超过了默认的自动解决时间(3m)。其次,Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况:
thanos_alert_queue_alerts_dropped_total
thanos_alert_queue_alerts_pushed_total
thanos_alert_queue_alerts_popped_total
通过观察 thanos_alert_queue_alerts_dropped_total 的值,看到存在告警丢失的总数,也能佐证了缓冲队列在某些时刻存在已满的情况。
解决通过以上的分析,我们基本确定了问题的根源:Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题,我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列,我们通过估计一个告警数量的最大值,得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn,实体上的告警规则数量分别有 y1、y2、y3、...、yn,那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn),最多推送(y1 + y2 + y3 + ... + yn)次,所以要使缓冲队列不堆积,maxBatchSize 应该满足:maxBatchSize = (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn),假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x,即 maxBatchSize 的最小值为 x。也就是说,可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体,对于 DMP 平台,一般来说是 MySQL 实例。
注意事项
上面的计算过程只是提供一个参考思路,如果最终计算出该值过大,很有可能对 AlertManager 造成压力,因而失去缓冲队列的作用,所以还是需要结合实际情况,具体分析。因为 DMP 将 Ruler 集成到了自己的组件中,所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件,那么需要对源码文件进行定制化修改。
每天都有海量的数据出现,依靠传统的人工方式去呈现数据价值,可能一辈子都处理不完。我们需要新的软件和技术,去更深入的理解和利用大数据集合。最佳的方法是提高数据可视化的水平。康拓普数据洞察平台,专注于大数据可视化技术,致力于帮助客户挖掘和利用数据价值,指导客户如何利用数据可视化工具让大数据更加人性化。
纵观生活,大数据的应用十分普遍:淘宝运用大数据为客户推荐商品信息,百度用大数据帮助大家精准搜索,谷歌地图用大数据指引出行。不知不觉中,数据可视化已经遍布我们生活的每一个角落,毕竟用户更关心数据结果的展示而非大数据。
比如我们常用的智能手机,它既是一款数据采集工具,同时也是一个多媒体的数据可视化展示平台:比如我们看的新闻中有大量的数据图表;我们娱乐的影视剧和电子游戏,频繁出现的数据可视化元素,让作品更具科技感;在教育与科普方面,数据可视化的应用更广,因为大家已经对传统单调的讲述方式失去兴趣,喜欢更加直观、高效的信息呈现形式。
未来,随着智能手机、平板电脑和车载电脑等平台日渐普及且不断融合,新的交互手段将成为数据可视化的趋势。那么,我们如何更加快速、深入、全面的展示大数据背后的信息呢? 答案是我们需要更加人性化的数据可视化设计。
如何设计更加人性化的数据可视化效果?
其实,数据可视化早已存在,我们用的PPT、EXCEL中就可以将数据的各种属性和变量呈现出来。对于大数据,这远远不够。
近年来,大数据可视化发展迅速,随着数据可视化平台的拓展,应用领域的增加,表现形式的不断变化,以及增加了诸如实时动态效果、用户交互使用等,数据可视化像所有新兴概念一样边界不断扩大,不断有酷炫夺目的可视化案例出现。但是,数据可视化的图形设计,并不是越酷炫越好,而是要贴合用户需求。
大数据可视化应该更贴近用户的使用习惯和使用需求,就像交通指示牌一样,让车主准确到达目的就行,而无需复杂的图形。因此,在大数据可视化设计时,也需因地制宜:
首先,对于简单明了的大数据集合,可以用饼图、直方图、散点图、柱状图等最原始的统计图表,它们是数据可视化的最基础最常见的应用。
其次,遇到复杂或大规模异型数据集,比如商业分析、财务报表、人口状况分布、媒体效果反馈、用户行为数据等,就要先进行数据采集、数据分析、数据治理、数据管理、数据挖掘等一系列复杂数据处理,然后由设计师设计一种表现形式,是立体的、二维的、动态的、实时的,还是允许交互的?最后由数据工程师创建对应的可视化算法及技术实现手段。
这些复杂的制作步骤,目前的大数据可视化平台可以帮你实现。“康拓普大数据洞察平台”,内置大量丰富的可视化图表,满足客户不同场景的需求,是一款超级实用的大数据可视化工具。
康拓普数据洞察平台,为您定制更贴合需求的数据可视化
康拓普数据洞察平台,基于大数据和互联网时代设计,它是一款自助式的大数据可视化工具,为您提供丰富的图标效果展示,帮助您洞察大数据的潜力和价值。平台支持多终端( PC、平板、手机端)、跨平台(iOS、安卓、Windows)对数据进行可视化展现。
康拓普数据洞察平台,支持多个报表在页面上灵活布局,自由组合,一目了然,快速响应用户需求。还可以帮助非专业的人士通过图形化的界面轻松搭建专业水准的可视化应用,满足各行业在日常业务中的监控、调度、会展演示等多场景使用需求。
以上由物联传媒转载,如有侵权联系删除
发表评论
暂时没有评论,来抢沙发吧~