利用夜莺扩展能力打造全方位监控系统 喻波 滴滴 专家工程师 目 录 运维监控需求来源 01 监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 完 备性看采集能力，是否能够兼容并包，纳入更多生态的能力， 至关重要 夜莺数据采集 01.监控数据采集，all in one的agentd Agentd 进程存 活 端口监 控 插件脚 本 日志监 控 网络设 备 中间件 类 数据库 类 • 支持在web上配置采集策略，不同的采集可以指定 不同的探针机器、目标机器，便于管理和知识传 承 • 独创在端上流式读取日志，根据正则提取指标的 夜莺Server数据处理 06. data - read 夜莺Server数据处理 夜莺设计实现 技术难点及细节 第六部分 0１. 规则集中化管理及自动发现 夜莺 技术难点及细节 0２. 采集器 夜莺 技术难点及细节 0２. 数据序列化及传输问题 夜莺 技术难点及细节 Thank you

更多函数就不过多介绍了，相对容易理解，参考 Prometheus 官方文档即可。最后扩展介绍一 个 MetricsQL（MetricsQL 是 VictoriaMetrics 提供的一种查询语言，兼容 PromQL 并对其做 了增强，如果你的存储是 VictoriaMetrics，则可以使用这些扩展函数） 中的扩展函数。 count_gt_over_time 假设原始需求：某个指标（ 假设指标名字是

可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 级、协同闭环处理等等。监控系统或多或少都有一些这方面的能力，但是通常都不完备，而这，正是 警太多、打扰太多的原因是什么，然后针对原因提出对应的 方案。 告警太多的常见原因 最常见的原因，是告警规则设置得不合理。比如很多规则触发了告警之后，实际没有后续动作，只是起到 常态化通知的效果，不需要排查，也不需要止损，甚至连个长线的 TODO 都没有。这类告警多了人就疲 了，当重要的告警来临的时候，也容易忽略。这样的规则如果不经过治理，日积月累，就会产生很多无用 的告警。 高，也不如机器来得快，如果有些告警能够直接关联自动化处理逻辑，无疑可以大大增加事件闭环率。 告警自动处理 很多监控系统都可以配置 Webhook，当告警触发之后自动回调某个 HTTP 接口，来串联一些自动化的 逻辑，让告警事件无人值守自动处理。比如某个机房的某个服务挂掉了，Webhook 的逻辑是自动调用切 流的接口，把服务流量切走，这样来达到止损的目的。 告警自动处理的这段逻辑，未必一定

发送告警渠道多 • 重要告警没有及时到达 • 优化告警没有数据依据 问题 • 告警标准化 • 告警收敛 • 告警渠道管理理 • 告警升级 • 告警报表 核⼼心功能 API⽹网关 服务树 告警收敛 屏蔽规则 事件管理理 告警渠道 报表系统 ⼯工单系统 鉴权 频控 标准化 时间维度 业务维度 关联关系 rms 告警升级 企业微信 钉钉 邮件 短信