告警能力中台设计与实践(二)——事件树系统

一、现有告警平台分析

在设计核心的告警数据模型时,本质上是对业务逻辑与整理数据流的梳理与设计。对于这部分不可高屋建瓴、想当然,需要有成熟的
取其精华、根据自身业务需求再做优化与改进才是正道。

笔者所在的部门SRE平台恰巧已有相关告警能力,在详细分析后可以获悉如下特性:

  • 服务进行告警策略的配置时,会同时配置告警收敛和恢复策略;
    • 所谓收敛策略,就是相同告警(内容一致)在多长时间内不重复发送;
    • 所谓恢复策略,就是多长时间内未产生告警自动恢复;
  • 在告警的收敛周期内,所有的告警消息会压缩在同一条告警事件中;
  • 在恢复周期定义的时长内未有新告警产生,该告警事件会自动恢复;

上述的基本流程与设计对于告警核心功能而言已经足够,但对于更高维度的告警抽象、事件关联、响应与信息反馈,这种模式仍存在某些痛点:

  • 告警汇聚层次较低
    • 虽然支持以服务为维度的聚合,但展开后依然是以告警单元事件为数据颗粒;
    • 举个例子,当我们想吃大包子时,我们希望重新调配、制作馅料,而不是把一堆小包子放一起直接包起来;
    • 如果不能对数据做重新梳理、聚合,当几十个服务、上百个指标同时故障,整体告警会变得不可观测:
  • 无法支持根因事件的关联
    • 事件仅仅是一层的、与特定服务、特定环境、特定策略相绑定,没有以服务或指标维度再做事件的抽象;
    • 很多时候,告警故障的产生并不是随机的,而是由某个核心服务的故障导致的连锁反应;
    • 这个时候,只要核心服务故障恢复,我们就可以认为当前整个故障传播链上的告警均已恢复;
    • 但当前告警能力并不支持这样,只能手动或自动地等待所有事件自行恢复;

总的来说,结合告警发送及时性与全面性、告警消息量与体验、以及告警根因事件响应的相关诉求,我们在告警消息与事件的基础上,引入事件树系统,基于事件节点进行告警事件的自动汇聚与消息通知推送,并支持服务手动的根因事件创建与关联。

二、事件与事件树系统

1、消息与事件

(1)告警消息

当第三方服务发起告警请求时,会调用中台所提供的OpenAPI,此时,我们会将所有的告警请求均进行记录、生成一条告警消息-AlarmMsg并保存起来。对于告警消息,其具备如下特点:

  • 是一种信息表达,代表在某个时间点,xx服务、xx环境下产生了满足xx指标、xx条件的相关异常;
  • 无状态
  • 告警消息是否触发通知操作,根据告警策略与收敛策略决定;
    • 在发起告警后,会生成一条或多条告警通知记录-AlarmRecord
  • 告警消息本身会作为最小粒度,汇聚到原子事件下;

(2)告警事件

对于告警事件(AlarmEvent)而言,首先根据基本性质,我们可以将事件分为两类:

  • 原子事件
  • 聚合事件

同时,事件本身除了能够手动创建、关联外,主要通过自动生成来完成整体事件树的构造,根据聚合粒度,事件本身还可以分类为:

  • 单服务单指标(L1)
    • 属于原子事件;
    • 故障类型为单个服务、单个指标下的相关告警;
    • 样例:构建检查服务接口状态500类型异常;
  • 单服务多指标(L2)
    • 属于聚合事件;
    • 单个服务多个指标类型出现故障的相关告警;
    • 主要为标记在一段时间内同一个服务所有故障的汇聚情况;
    • 样例:构建检查服务异常告警事件;
  • 多服务多指标(L3)
    • 属于聚合事件;
    • 多个服务、多个指标出现故障时的相关告警;
    • 是单服务多指标的再向一层的抽象汇聚,一般是抽象到服务组(产品)层级,可在一定程度上代表局点的健康状态;
    • 样例:构建产品异常告警事件;
a、原子事件

对于原子事件而言, 指的是在特定的告警策略下对应告警消息所关联的对应事件,其具备如下特点:

  • 是事件的最小单元,不可再分
  • 自动生成;
  • 有状态,存在生命周期;
    • 支持自动或手动恢复;
    • 当事件状态转为恢复后,不再开启、直接归档;
  • 单服务单指标
    • 也即基于特定微服务、特定环境、特定指标(告警策略);
  • 事件本身存在等级,与告警策略等级保持一致;
  • 在事件树体系中,原子事件一定是叶子节点
b、聚合事件

所谓聚合事件,是基于原子事件进行聚合、或基于其他聚合事件聚合而成的更高层级的父节点,其特点如下:

  • 可自动生成、也可手动生成;
    • 自动生成类型:单服务多指标、多服务多指标;
    • 手动生成类型:人为地选择多个节点作为子节点而生成,节点含义人为指定;
  • 有状态,且父节点状态与子节点状态相关联;
    • 当父节点手动标记恢复时,所有父节点下子节点状态同步更新为恢复;
    • 当父节点下所有子节点状态均为恢复时,其父节点状态也同样会更新为恢复;
  • 在事件树中为父节点,且不可能为叶子节点;

作为事件树的重要组成部分,原子事件与聚合事件的具体生成与关联办法,会在下部分中详细说明。

2、事件树体系

(1)事件树基本定义

首先,所谓的事件树体系,就是针对不同层级的告警事件汇聚而出现的。

在事件树中,我们能够做到:

  • 自动的对告警事件生成L1、L2、L3三个层级的事件;
  • 对不同层级告警事件的操作,能递归地作用于下面所有的子事件;
    • 例如,当对父亲节点的状态标记为已恢复时,其下面所有服务、所有指标的相关告警事件均会直接标记为已恢复;
  • 能够自由的根据告警产生的根因分析情况,选择或创建对应的根因事件节点,并将对应受影响服务告警事件做关联进行跟踪、处理;

其次,对于事件的数据接口定义层面,我们主要包含:

{"event_name" # 事件名称"event_uuid" # 事件节点uuid"event_level" # 事件层级,可选:L1 L2 L3 L4(自定义类型事件层级)"alarm_level" # 事件对应告警层级"parent_uuid" # 父亲节点uuid,可为空"service_info" # 事件关联服务信息"started_at" # 事件开始事件"recovered_at" # 事件恢复事件"responser" # 事件响应人"closer" # 事件关闭人"event_desc" # 事件描述"alarm_reason" # 事件告警根因
}

(2)事件生成过程

在生成事件节点与事件树时,具体流程如下:

  1. 当告警产生时,会自动生成单服务、单指标事件,也即叶子节点;
  2. 在生成叶子节点后,首先会尝试查找对应父节点——也即单服务多指标事件节点:
    • 如果找到,则说明当前告警时间区间内已经完成了总体事件树的生成构造,直接将叶子节点的父节点关联到对应聚合事件节点即可;
    • 如果没有找到,则说明当前事件为告警时间区间内的第一个产生事件,直接根据服务、产品等信息,生成相对应的父节点,并尝试找到对应L3层级的祖父节点——找到关联、未找到则创建;
  3. 而后,如果产生了同样服务、同样指标的告警,会直接收敛聚合到对应叶子节点下;
  4. 如果产生了同样服务、不同指标的告警,会自动再走上面的流程、并关联到对应的L2层级节点上;
  5. 如果产生了不同服务、但相同产品的对应告警,则会生成对应L2层级节点,并同样关联到对应根节点上;

总的来说,自动生成构建的事件树一定是一个三层的树形结构,从上到下分别对应着:

  • L3:多服务多指标事件节点;
    • 根节点,有且只有一个;
  • L2:单服务多指标事件节点;
    • 中间层节点,可能存在多个;
  • L1:单服务单指标事件节点;
    • 叶子节点,原子事件;

(3)事件恢复过程

对于事件的恢复机制,我们主要有自动与手动两种方法:

a、自动恢复

当同一个产品在某个故障周期内产生一系列告警时,会自动生成一颗事件树。
很多时候,告警本身并不是很重要:例如CPU使用率短暂飚高等,在告警产生后很快就回落了,因此也不再产生新的告警。

对于最基础的告警体系而言,告警本身是存在生命周期概念的,因此在上一篇章中我们所定义的恢复时间周期概念下,如果一个告警原子事件在一段时间内没有产生新的告警请求,那么我们就认为该原子事件已恢复:

  • 这里,我们是通过定义一个原子事件状态巡检任务来进行时间与状态检查的。

同时,每当这样的告警原子事件恢复时,都会自动触发一轮事件树状态检查任务,事件树会递归地检查自身的孩子节点状态:

  • 如果所有孩子节点的状态均为“已恢复”,则该父亲节点的状态也会同步修改为“已恢复”;
  • 如果存在状态为“告警中”的孩子事件节点,则不做任何操作、维持父亲节点“告警中”的相关状态;

最后,有一些时候服务会持续不断的产生轻微类型的告警,可能导致某一棵事件树上挂了大量的告警信息,既不方便观察、也不方便处理,更会影响后续新的告警事件的产生与事件树的生成。
对于这种情况,我们会每天定时自动关闭持续告警事件,并对服务做相关标记、提醒服务可能存在的相关问题,从而避免上述问题。

b、手动恢复

除了上述的自动恢复外,本身较为紧急的告警事件,我们是希望服务OnCall响应、处理、并手动标记恢复的。

因此,对于手动恢复告警事件,支持对各个层级的告警事件进行操作:

  • 从上到下,递归地将父亲节点下所有孩子、孙子事件节点标记为恢复;
  • 从下到上,递归地探查当前父亲、祖父节点所有孩子是否已恢复已更新其父亲、祖父节点状态;

(4)事件的手动创建与关联

除了上述自动生成的三层服务树结构外,很多时候在服务OnCall或SRE完成告警根因与异常分析后,明白多个告警之间的关联关系与因果关系,因此希望能够有一个统一的事件节点来跟踪这一系列的告警事件。

这时,对于告警警情的跟踪,只需要跟踪该根因事件即可:
例如,某个下午出现了多个服务接口5xx异常告警,经过快速分析后发现实际是其中一个上游服务A的OpenAPI出现异常,导致调用该接口的相关服务对应业务也都出现了报错告警。
对于这种情况,只要该上游服务的接口问题修复,那么下游服务的一系列问题也自然恢复。

但是,由于本身告警根因并不容易挖掘发现,而且我们自动生成的告警事件树也仅仅是基于指标与服务自身维度围绕构建的,这种业务逻辑层次的关联关系我们很难去自动构造事件树,因此对于上面的问题,就会有数棵逻辑上有关、但数据与形式上无关的事件树被构造出来。

基于上述问题,我们提供了事件树的手动关联机制。
例如在上面的场景中,对于多个告警事件树,支持用户直接创建新的类型为L4的事件节点,说明具体事件类型,并将多个L3层级的事件树根节点关联到该节点上。
这样,就人为地构造出了一棵四层的事件树结构,该树形结构同样支持上面的手动与自动恢复机制。
这种手动创建、关联而成的四层事件树结构,方便在较大规模、相互联系故障发生时,有一个更加抽象、统一的观测视角,在把控告警全局的同时,在根因问题恢复时也方便一键恢复所有受影响服务告警事件。

需要注意的是,对于事件树而言,我们设计与实践的核心思想在于“规范化”、“条理化”,因此我们对告警事件做了严格的层级与类型分类,事件树只有自动生成的三层或手动创建的四层,并不支持无限制的节点生成与关联。
这样有限层级的事件树方面处理和展示的同时,也避免了过深层的事件树而造成的事件树检查递归时间复杂度过高、性能损耗等问题。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/686510.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

AutoKeras(Python自动化机器学习)多模态数据和多任务

要点拓扑 AutoKeras 拓扑 要点 常规机器学习:scikit-learn示例探索性数据分析和数据预处理,线性回归,决策树图像分类ResNet模型示例,合成数据集DenseNet模型示例绘图线性回归和决策树模型使用Python工具seaborn、matplotlib、pan…

论文阅读:四足机器人对抗运动先验学习稳健和敏捷的行走

论文:Learning Robust and Agile Legged Locomotion Using Adversarial Motion Priors 进一步学习:AMP,baseline方法,TO 摘要: 介绍了一种新颖的系统,通过使用对抗性运动先验 (AMP) 使四足机器人在复杂地…

Github项目推荐-Tiny-Rdm

项目地址 GitHub - tiny-craft/tiny-rdm: A Modern Redis GUI Client 项目简述 一个开源的Redis管理工具,有漂亮的界面和丰富的功能。使用的编程语言如下 项目截图

【IIS中绑定SSL证书】

下载SSL证书: 打开服务器IIS: 点击导入 在IIS中新增网站:

【制作100个unity游戏之25】3D背包、库存、制作、快捷栏、存储系统、砍伐树木获取资源、随机战利品宝箱8(附带项目源码)

效果演示 文章目录 效果演示系列目录前言砍树功能源码完结 系列目录 前言 欢迎来到【制作100个Unity游戏】系列!本系列将引导您一步步学习如何使用Unity开发各种类型的游戏。在这第25篇中,我们将探索如何用unity制作一个3D背包、库存、制作、快捷栏、存…

NodeJS背后的人:Express

NodeJS背后的人:Express 本篇文章,学习记录于:尚硅谷🎢 文章简单学习总结:如有错误 大佬 👉点. 前置知识:需要掌握了解: JavaScript基础语法 、Node.JS环境API 、前端工程\模块化 …

CSP约束满足问题、回溯搜索、最少剩余值MRV、度启发式、最少约束值启发式

文章目录 约束满足问题 CSP示例:地图着色约束图CSP的种类约束类型举例:密码算法现实世界的CSP标准搜索公式回溯搜索改进回溯搜索的效率最少剩余值启发式度启发式最少约束值启发式Forward checking—前向检验Constraint propagation — 约束传播约束满足

React和Vue 中的 router 实现原理如何

React 和 Vue 中的路由器(Router)实现原理类似,都是基于监听 URL 变化,然后根据不同的 URL 加载相应的组件或页面。下面是它们的一般实现原理: React Router 实现原理: History API: React Rou…

【Linux】程序地址空间 -- 详解 Linux 2.6 内核进程调度队列 -- 了解

一、程序地址空间回顾 在学习 C/C 时,我们知道内存会被分为几个区域:栈区、堆区、全局/静态区、代码区、字符常量区等。但这仅仅是在语言层面上的理解,是远远不够的。 如下空间布局图,请问这是物理内存吗? 不是&…

【共享目录讲解】

共享目录讲解 1. 介绍2. 文件系统和网络3. 创建共享目录的步骤4. 回归共享目录概念的主要要素5. 实际应用6. 技术的限制和考虑 1. 介绍 共享目录(Shared Directory)是在计算机网络中使得不同用户和不同计算机可以访问同样数据集的一个特性。这通常用于本…

Acwing 周赛143 解题报告 | 珂学家 | 状压DP

前言 整体评价 被这个T2难住了, 幸好最后磨出来了,感觉蛮头痛的。T3是道状压题,这个反而容易写。 A. 时间 思路: 模拟 取模,但是对0要改成12 n int(input())r n % 12print (12 if r 0 else r)B. 数对推理 思路: 按题意模拟 如果一组…

【Linux】指令 【scp】

scp 是一条用于安全复制文件的命令。 scp hadoop.tar.gz datanode:/software这条命令的含义是将本地的hadoop.tar.gz文件复制到远程主机datanode的/software目录下。 scp:这是Secure Copy的缩写,用于在主机之间安全地复制文件。hadoop.tar.gz&#xff…

C++运算符重载(日期类的运算符重载为例)

一、运算符重载简介 C为了增强代码的可读性,引入了运算符重载。 运算符重载是一个拥有特殊函数名的函数,其函数名为 operator重载的运算符,其余的返回值类型和参数列表与普通函数类似。调用时可以使用函数名调用,也可以直接使用…

Kubernetes 元信息与控制器模型

一、资源元信息: Kubernetes 的资源对象组成:主要包括了 Spec、Status 和元数据。其中 Spec 部分用来描述期望的状态,Status 部分用来描述观测到的状态。 元数据主要包括了:Labels 用来识别资源的标签;Annotations 用…

EasyUI动态加载组件

要实现如下的效果,在表格中显示进度条 主要是需要再次初始化组件,借用ChatGPT的意思是: 在许多 JavaScript UI 框架中,包括 EasyUI,在动态地创建或插入新的 DOM 元素后,通常需要手动初始化相关的组件或特性…

DPU技术的进步:赋予未来创新力量

随着云计算和虚拟化技术的发展,网卡在功能和硬件结构方面也经历了四个阶段,即网卡、智能网卡、基于FPGA的DPU和DPU SoC网卡。本文将重点介绍这些不同类型的网络适配器和处理器,在硬件、可编程能力、开发和应用方面的特点。 网卡的演进和应用…

第四节笔记:XTuner 大模型单卡低成本微调实战

视频链接:https://www.bilibili.com/video/BV1yK4y1B75J/?spm_id_from333.788&vd_source3bbd0d74033e31cbca9ee35e111ed3d1 课程笔记: 1.Finetune简介 指令微调: 开始的大模型可能不知道问的是问题 这三种角色的划分只有在微调训练阶…

LeetCode、452. 用最少数量的箭引爆气球【中等,贪心,区间问题】

文章目录 前言LeetCode、452. 用最少数量的箭引爆气球【中等,贪心,区间问题】题目链接与分类思路贪心,连续区间数量问题 资料获取 前言 博主介绍:✌目前全网粉丝2W,csdn博客专家、Java领域优质创作者,博客…

Unity 减低GC和优化

文章目录 在Unity中,垃圾收集(Garbage Collection, GC)是一项重要的内存管理机制,但过度的GC活动可能会导致性能瓶颈。优化Unity项目中的GC涉及减少不必要的对象分配和生命周期管理。以下列举了五个实例来详细说明如何降低GC负担并…

数学建模【线性规划】

一、线性规划简介 线性规划通俗讲就是“有限的资源中获取最大的收益”(优化类问题)。而且所有的变量关系式都是线性的,不存在x、指数函数、对数函数、反比例函数、三角函数等。此模型要优化的就是在一组线性约束条件下,求线性目标…