Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾讯云的云监控、阿里云的云监控，甚至有些云厂商会提供多个割裂的监控系统，比如阿里云不但 有云监控，还有 ARMS，还有 SLS。 大部分公司都不会只使用一套监控系统，网络设备的监控可能采用的 Zabbix，Kubernetes 用的 Prometheus（Kubernetes 可能有多套，以至于 Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 思路方法篇 告警事件的后续处理：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环 处理等等。看起来需求很多，最核心的痛点有两个： ● 告警太多，打扰太多 ● 告警疏漏，无法闭环 我们先来看第一个痛点，首先分析一下造成告警太多、打扰太多的原因是什么，然后针对原因提出对应的 方案。 告警太多的常见原因 最常见的原因，是告警规则设置得不

利用夜莺扩展能力打造全方位监控系统 喻波 滴滴 专家工程师 目 录 运维监控需求来源 01 监控痛点：全面完备、跨云 02 夜莺介绍： 国产开源监控系统 03 夜莺设计实现：Agentd 数据采集 04 夜莺设计实现：Server 数据处理 05 夜莺设计实现：技术难点及细节 06 运维监控需求来源 第一部分 如果贵司的业务强依赖IT技术，IT故障会直接影响营业收入， 的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 环节出问题都能及时感知 产品要求 01.端上、链路、资源、组件、应用多维度跨云监控 端上 卡顿 崩溃 链路 连通性 链路质量 服务端 硬件资源 组件服务 业务应用 夜莺介绍：国产开源监控系统 夜莺介绍：国产开源监控系统 第三部分 国产开源监控产品相对比较匮乏，夜莺希望重新定义国产开 源监控，支持云原生监控，经受了滴滴大规模生产检验 Nightingale 夜莺是新一代国产智能监控平台，既可以解决传统物理机虚拟机的场景，也可以解 决容器的场景。衍生自Open-Falcon和滴滴Odin监控，经受了包括小米、美团、滴滴 在内的数百家企业的生产环境验证，简单可依赖，好用到爆！ 3500+

告警规则: 磁盘容量量预计将于3⼩小时后饱和 0 now -1h +3h predict_linear(node_filesystem_free{}[1h], 3 * 3600) < 0 异常检测 异常流量量 abs(requests - requests:holt_winters_rate1h offset 7d) > 0.3 * requests:holt_winters_rate1h

15:05:22 这个时刻，每个机器都有 一个可用率数据点，共计 5 个数据点。 上面的图是查询的最近一小时的，我们切换到 Table 视图，得到如下结果： 这个表格的内容，是这 5 台机器在当前这个时间点的最新值，当前我做查询的时刻是：2022- 08-25 15:48:03 用 Chrome 开发者工具可以看到发的请求参数： 但是，监控数据是周期性上报的，比如每 10 秒上报一次，在 2022-08-25 体时刻（对于排查监控数据采集相关的问题尤为有用），如果在 Graph 视图，返回的数据取 决于 step 参数，查询时传给时序库的 step = 10，返回的图形就是每 10s 一个点，step = 20 就是每 20s 一个点，返回的数据的时间间隔取决于 step 参数而非原始数据的上报间隔。 Range Query 理论上是没法绘制 Graph 的（当然有些时序库可能会做容错处理），因为从原 理上说不通。绘图的时候，我们要选择一个时间范围，比如最近一小时，然后传给后端一个 step 参数用于控制分辨率，即数据间隔，比如 step=60，即表示希望每个 series 每分钟返回一 个点，但如果是 Range Query，相当于在某个时刻返回多个点，这就无所适从了。 Prometheus 文档中有一个章节专门介绍函数，各个函数的介绍中，都会写明是用于 instant- vector，还是用于 range-ve