B站统⼀监控系统的设计,演进
与实践分享获取监控数据 获取监控数据 推送告警 1. 降低编写规则的成本 2. 降低多idc维护成本 规则管理理⻚页⾯面 例例⼦子 - 业务监控 稿件 账号 Feed PAAS托管 服务树 container http server sdk 注册 获取target 采集数据 吞吐量量 响应时间 错误率 饱和度 熔断 限流 投稿数量量 订单数据 在线⼈人数 … • 重要告警没有及时到达 • 优化告警没有数据依据 问题 • 告警标准化 • 告警收敛 • 告警渠道管理理 • 告警升级 • 告警报表 核⼼心功能 API⽹网关 服务树 告警收敛 屏蔽规则 事件管理理 告警渠道 报表系统 ⼯工单系统 鉴权 频控 标准化 时间维度 业务维度 关联关系 rms 告警升级 企业微信 钉钉 邮件 短信 ACK应答0 码力 | 34 页 | 650.25 KB | 1 年前3
PromQL 从入门到精通RX packets 后面的值是 OS 启动以来收到的总的包量,TX packets 后面的值是 OS 启动以来发 出去的总的包量,都是很大的值,我们通常不太关注这个值当前是多少,更关注的是最近 1 分 钟收到/发出多少包,或者每秒收到/发出多少包。 1 2 3 4 5 6 7 8 而对于监控数据采集器而言,一般是周期性运行的,比如每 10 秒采集一次,每次采集网卡收 到/发出 历 mem_available 的5条记录,对于每一条,去 mem_total 的5条记录中找标签相同的记录,进 行除法运算。除法运算得到5条结果(0~1之间的数字),然后跟100相乘(得到百分比大 小),100这个数字称为标量,5条结果和标量计算,会把每一条结果分别乘以100,得到最终 的结果,这个最终结果其实就是 mem_available_percent。 如果分子和分母对应的s vector2,其结果是一个向量,包含vector1的所有原始元素(标签集+值)以及 vector2中所有在vector1中没有匹配标签集的元素。 举一个例子,比如系统负载,有最近1分钟、最近5分钟、最近15分钟的负载,需求是:最近1分 钟的负载大于8或者最近5分钟的负载大于8,就告警,promql写法: system_load1{app="clickhouse"} > 8 or 1 2 3 1 2 s0 码力 | 16 页 | 2.77 MB | 1 年前3
1.6 利用夜莺扩展能力打造全方位监控系统02 夜莺介绍: 国产开源监控系统 03 夜莺设计实现:Agentd 数据采集 04 夜莺设计实现:Server 数据处理 05 夜莺设计实现:技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术,IT故障会直接影响营业收入, 稳定性体系一定要重视起来,而监控,就是稳定性体系中至 关重要的一环 运维监控需求来源 01.监控的原始需求来自业务稳定性 左图是2013年的一个新闻,讲 左图是2013年的一个新闻,讲 Google宕机的影响。2020年也出现 过aws大规模宕机的情况,影响不 止是55万美元,直接影响大半个 互联网! 2018年有美国调研机构指出,如 果服务器宕机1分钟,银行会损失 27万美元,制造业会损失42万美 元 美团故障?滴滴故障?腾讯故障? 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失?尽快发现故障并止 损』来 实现。 监控痛点:全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控,不管哪个 环节出问题都能及时感知 产品要求 01.端上、链路、资源、组件、应用多维度跨云监控 端上 卡顿 崩溃 链路 连通性 链路质量 服务端 硬件资源 组件服务 业务应用 夜莺介绍:国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏,夜莺希望重新定义国产开0 码力 | 40 页 | 3.85 MB | 1 年前3
告警OnCall事件中心建设方法白皮书
这种产品存在的价值。这些产品都是以 Duty 命名,核心就是支持告警 OnCall 值班处理的场景。 对于告警事件的后续处理,有哪些问题和需求以及何为最佳实践?我们从思路方法和工具实践两个方面分 别进行探讨,下面先行探讨思路方法,看看要解决这些问题和需求,我们有哪些可能的解法。 思路方法篇 告警事件的后续处理:多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 每天早上上班或晚上下班之前稍微看一眼就行,这样就可以减少打扰。 制定了这个原则之后,如果大家不遵守怎么办呢?还是有很多告警没有对应的 Runbook,作为管理人 员,我们应该怎么处理?我的建议是分产品线统计一个指标:“Runbook 预置率”,就是各个产品线有 多少告警规则配置了 Runbook,有多少没有配置,这个比例要统计出来,然后做成红黑榜,让大家去治 理,治理一段时间之后有经验了, incident 却很难自动收敛。不过业界也会有一些常见的做法,下面我举几个例子。 1、根据时间做收敛 把告警中心收到的所有告警,按照时间维度做收敛,比如按照分钟颗粒度,一分钟内所有告警收敛成一个 故障,下一分钟所有告警收敛成另一个故障。显然,一个故障内的多个告警相互之间可能没有关联关系, 所以这种收敛方法不是太好。 2、根据时间 + 标签做收敛 除了时间维度,再加上某个0 码力 | 23 页 | 1.75 MB | 1 年前3
共 4 条
- 1













