规 则的源头做好优化，自然是事半功倍。很多公司的告警规则配置没有原则可循，每次故障复盘先看告警是 否漏报，一线工程师为了不背锅，自然是尽量多地提高告警覆盖面，但这么做的后果，就是告警过多，无 效告警占多数，长此以往，工程师疲惫不堪。 那么告警规则的配置应该遵照一个什么原则呢？虽然每个公司业务不同，总有一些通用的原则可循吧？的 确如此，这里我分享一下我个人的做法，希望对你有所启发。 Nightingale 的告警规则配置页面，可以看到一个专门的 Runbook 配置，Grafana 的告警配置页面， 也有一个 Runbook 的选项，就能看出他们对它的重视程度。 这个原则看起来是不是很合理？但是真要落地的时候，又会发现紧急需要处理的告警事件通常容易对应 Runbook，但是有些告警规则产生的告警确实没有那么紧急，有些只是想作为一个通知，好像又确实难以 对应一个固定的 按照报表和巡检 的逻辑来处理，比如把这类“告警”发到一个单独的邮件组或者单独的聊天群组，平时都不用关注，只要 每天早上上班或晚上下班之前稍微看一眼就行，这样就可以减少打扰。 制定了这个原则之后，如果大家不遵守怎么办呢？还是有很多告警没有对应的 Runbook，作为管理人 员，我们应该怎么处理？我的建议是分产品线统计一个指标：“Runbook 预置率”，就是各个产品线有 多少告警规则配置了

利用夜莺扩展能力打造全方位监控系统 喻波 滴滴 专家工程师 目 录 运维监控需求来源 01 监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 美团故障？滴滴故障？腾讯故障？ 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失？尽快发现故障并止损！故障处理过程中，监控是『发现』和『定位』两个环节 的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 环节出问题都能及时感知

能覆盖⼤大部分监控场景 • 固定⼏几种数据类型 ✦ Counter ✦ Gauge ✦ 等.. • 时序数据 ✦ 具有统计特性 ✦ 具有规律律性 metric数据特征 选型原则 • 基于开源⽅方案，⼆二次开发 • 具备现代时间序列列数据库的特性 • 活跃项⽬目,具有成熟的⽣生态环境 结论 • prometheus • ⽀支持任意维度label • cncf基⾦金金会