告警OnCall事件中心建设方法白皮书事件 ONCALL 中心建设方法 一站式处理值班 OnCall,智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统,刨去商业软件不说,开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等,还有云厂商提供的监控系统,比如华为云的云 监控、腾 监控系统的重心,通常是采集、存储、可视化、生成告警事件,但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括:多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 级、协同闭环处理等等。监控系统或多或少都有一些这方面的能力,但是通常都不完备,而这,正是 PagerDuty FlashDuty 这种产品存在的价值。这些产品都是以 Duty 命名,核心就是支持告警 OnCall 值班处理的场景。 对于告警事件的后续处理,有哪些问题和需求以及何为最佳实践?我们从思路方法和工具实践两个方面分 别进行探讨,下面先行探讨思路方法,看看要解决这些问题和需求,我们有哪些可能的解法。 思路方法篇 告警事件的后续处理:多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 处理等等。看起来需求很多,最核心的痛点有两个: ● 告警太多,打扰太多 ● 告警疏漏,无法闭环0 码力 | 23 页 | 1.75 MB | 1 年前3
B站统⼀监控系统的设计,演进
与实践分享技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低 • 误报,漏漏报多 • 告警⻛风暴暴 监控问题爆发: 重新定义的监控系统 ✦ 完整的监控体系 ✦ 科学的告警策略略 ✦ 统⼀一的告警中⼼心 完整的监控体系 • 虚拟机 • 物理理设备 • 容器器 • 专线质量量 • 机房出⼝口质量量 • 交换设备 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm ⾃自研 客户端 播放器器 如何推进? 服务端监控 场景 分析监控场景对应监控⼿手段 类型 metric类型 ⽇日志类型 ⾃自定义类型 ⼿手段 时间序列列数据 ⽇日志处理理流 ⾃自研 ⽤用户端监控 apm ⾃自研 客户端 播放器器 alert_manager 告警平 服务 cache db平台 rms资 外围系统 监控⽬目 规则⽣生 告警规 api 规则管理理 获取监控⽬目标 IDC_1 agent prometheus target target target IDC_2 获取 监控⽬目标 告警规则 web push rule push rule 获取监控数据 获取监控数据 推送告警 降低使⽤用成本0 码力 | 34 页 | 650.25 KB | 1 年前3
PromQL 从入门到精通一个点,step = 20 就是每 20s 一个点,返回的数据的时间间隔取决于 step 参数而非原始数据的上报间隔。 Range Query 理论上是没法绘制 Graph 的(当然有些时序库可能会做容错处理),因为从原 理上说不通。绘图的时候,我们要选择一个时间范围,比如最近一小时,然后传给后端一个 step 参数用于控制分辨率,即数据间隔,比如 step=60,即表示希望每个 series 每分钟返回一 运算符 PromQL 支持基本的算术运算符和比较运算符,可以对不同的即时向量做运算,这为监控系统 带来了巨大的进步,算术运算符让很多计算不需要在采集端做了,可以轻易挪到服务端,而比较 运算符则为告警逻辑提供了支撑。 算术运算符 + (addition) - (subtraction) * (multiplication) / (division) % (modulo) 如上的方法,其实就是告警引擎的核心逻辑。告警规则里会要求用户配置promql以及执行频 率,告警引擎就会根据执行频率周期性执行,每次执行的时候就是拿着promql去查询,promql 中带有阈值,即上例中的 <60,所以如果所有机器的内存可用率都很高,比如维持在80~90, 那这个promql是不会返回查询结果的,此时监控系统就认为一切正常。如果返回了结果,比如 上例中返回了3条结果,告警引擎就会认为有异常产生,生成3个告警事件。0 码力 | 16 页 | 2.77 MB | 1 年前3
1.6 利用夜莺扩展能力打造全方位监控系统专家工程师 目 录 运维监控需求来源 01 监控痛点:全面完备、跨云 02 夜莺介绍: 国产开源监控系统 03 夜莺设计实现:Agentd 数据采集 04 夜莺设计实现:Server 数据处理 05 夜莺设计实现:技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术,IT故障会直接影响营业收入, 稳定性体系一定要重视起来,而监控,就是稳定性体系中至 关重要的一环 27万美元,制造业会损失42万美 元 美团故障?滴滴故障?腾讯故障? 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失?尽快发现故障并止损!故障处理过程中,监控是『发现』和『定位』两个环节 的关键工具。故障处理过程的首要原则是『止损』,因此,过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点:全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控,不管哪个 夜莺设计实现 Server 数据处理 第五部分 夜莺Server数据处理 01. 服务器 02. API 夜莺Server数据处理 03. AlarmRule Control 夜莺Server数据处理 04. CollectRule Control 夜莺Server数据处理 04. CollectRule Control 夜莺Server数据处理 04. CollectRule0 码力 | 40 页 | 3.85 MB | 1 年前3
共 4 条
- 1













