舆情监控(括弧笑脸) 我们的挑战 • 技术栈多 • 产品模块复杂 • 业务爆发式增⻓长 • 运维要求⾼高 当前情况: • 覆盖率低 • 误报，漏漏报多 • 告警⻛风暴暴 监控问题爆发: 重新定义的监控系统 ✦ 完整的监控体系 ✦ 科学的告警策略略 ✦ 统⼀一的告警中⼼心 完整的监控体系 • 虚拟机 • 物理理设备 • 容器器 • 专线质量量 • 机房出⼝口质量量 • cncf基⾦金金会 metric • 40w+/s的指标采集 • 10k+ 监控⽬目标 • 10+ prometheus节点 现状: • 性能 • ⾼高可⽤用 • 分布式 • 使⽤用成本 问题: ? 性能问题 • 本地ssd prometheus Shard A prometheus Shard B prometheus Shard C targets 在线⼈人数
 … ⻩黄⾦金金指标 业务指标 少量量事件 dashboard 报表 告警 统⼀一的告警中⼼心 解决什什么问题? • 告警源头多 • 告警⻛风暴暴, ⼤大量量重复告警 • 发送告警渠道多 • 重要告警没有及时到达 • 优化告警没有数据依据 问题 • 告警标准化 • 告警收敛 • 告警渠道管理理 • 告警升级 • 告警报表 核⼼心功能 API⽹网关

这种产品存在的价值。这些产品都是以 Duty 命名，核心就是支持告警 OnCall 值班处理的场景。 对于告警事件的后续处理，有哪些问题和需求以及何为最佳实践？我们从思路方法和工具实践两个方面分 别进行探讨，下面先行探讨思路方法，看看要解决这些问题和需求，我们有哪些可能的解法。 思路方法篇 告警事件的后续处理：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 ，甚至连个长线的 TODO 都没有。这类告警多了人就疲 了，当重要的告警来临的时候，也容易忽略。这样的规则如果不经过治理，日积月累，就会产生很多无用 的告警。 第二个常见的原因是底层出问题导致所有的上层依赖都告警，越是底层影响越大，比如基础网络如果出问 题，发出几万条告警都是正常的。 第三个原因是渠道错配。一些不重要的告警也使用打扰性很高的渠道发出，用户可能会觉得单一渠道不可 产生一堆关联告警。 了解了常见原因，下面我们来看一下有哪些常见解法。 优化告警规则 类似 PagerDuty FlashDuty 这种产品，一定程度上是可以解决一些告警过多的问题，但如果能从告警规 则的源头做好优化，自然是事半功倍。很多公司的告警规则配置没有原则可循，每次故障复盘先看告警是 否漏报，一线工程师为了不背锅，自然是尽量多地提高告警覆盖面，但这么做的后果，就是告警过多，无

频率是 10s， 而其他的机器采集频率是 30s。 ? 通过 range query + Table 视图，可以让我们直观看到原始上报的监控数据以及上报的具 体时刻（对于排查监控数据采集相关的问题尤为有用），如果在 Graph 视图，返回的数据取 决于 step 参数，查询时传给时序库的 step = 10，返回的图形就是每 10s 一个点，step = 20 就是每 20s 一个点，返回的数据的时间间隔取决于 instant-vector 和一个标量之间的比较，比如 mem_available_percent{app="clickhouse"} 的结果： 如果我们认为内存可用率小于60就是有问题的，想找出所有有问题的数据，只要在 promql 中 拼上 < 60 即可： 1 如上的方法，其实就是告警引擎的核心逻辑。告警规则里会要求用户配置promql以及执行频 率，告警引擎就会根据执行频率周 素组成的向量，在vector2中没有完全匹 配标签集的元素，两个vector中的所有匹配元素都被删除。姑且可以理解为一个减法，vector1 - vector2。 举个例子，还是磁盘利用率的问题，对于超过1个T的大盘，剩余量小于300G就告警，promql 怎么写？ disk_free{app="clickhouse"}/1024/1024/1024 < 300 unless di

的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 环节出问题都能及时感知 产品要求 01.端上、链路、资源、组件、应用多维度跨云监控 端上 卡顿 崩溃 链路 连通性 链路质量 服务端 硬件资源 组件服务 业务应用 夜莺介绍：国产开源监控系统 夜莺Server数据处理 夜莺设计实现 技术难点及细节 第六部分 0１. 规则集中化管理及自动发现 夜莺 技术难点及细节 0２. 采集器 夜莺 技术难点及细节 0２. 数据序列化及传输问题 夜莺 技术难点及细节 Thank you