Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 级、协同闭环处理等等。监控系统或多或少都有 中心功能更强大，我们留待工具实践篇再详细阐述。 接下来我们聊一下“告警疏漏、无法闭环”的问题，核心就是告警发出来得有人处理，所谓的闭环，就是 指告警发出、认领、协作处理、问题恢复、复盘改进的整个过程。 虽然事件降噪的几个手段落实之后，事件数量确实变少了，但是处理告警事件显然不是一个让人愉快的事 情，不愉快的事情就要团队共担，所以第一个手段就是排班，专人做专事。 排班，专人做专事 散，不能基于这些散乱的告警分别做协同，把多个 alert 收敛成一个 incident（故障），基于 incident 做协同才比较方便。但是，event 到 alert 是有一个固定的收敛逻辑的，可以通过程序自动收敛，而 alert 到 incident 却很难自动收敛。不过业界也会有一些常见的做法，下面我举几个例子。 1、根据时间做收敛 把告警中心收到的所有告警，按照时间维度做收敛

美团故障？滴滴故障？腾讯故障？ 运维监控需求来源 01.监控的原始需求来自业务稳定性 如何减少服务停摆导致的经济损失？尽快发现故障并止损！故障处理过程中，监控是『发现』和『定位』两个环节 的关键工具。故障处理过程的首要原则是『止损』，因此，过程中的『发现』和『定位』都是面向尽快『止损』来 实现。 监控痛点：全面完备、跨云 第二部分 端上、链路、资源、组件、应用多维度跨云监控，不管哪个 Agentd Agentd LoadBalance 1. 单机版Prom 2. 集群版m3db 3. 集群版n9e-tsdb 3种存储方案，按需选择 Agentd 夜莺设计实现 Agentd 数据采集 第四部分 监控系统的核心功能，是数据采集、存储、分析、展示，完 备性看采集能力，是否能够兼容并包，纳入更多生态的能力， 至关重要 夜莺数据采集 01.监控数据采集，all in

18秒，但是99分位时间是10秒，相差巨大，更容易暴露问 题。这里所谓的99分位延迟10秒，可以理解为，99%的请求都在10秒内返回。 从监控系统角度，如何来存储和计算出99分位值呢？如果每分钟有1亿个请求，难道真的要在监 控系统中存储这1亿个请求，然后排序，然后求取分位值？那这个代价就太大了。监控数据是采 样数据，对准确性要求没有那么的高，有没有什么办法可以降低这个代价呢？这就是 Prometheus Prometheus 官方文档即可。最后扩展介绍一 个 MetricsQL（MetricsQL 是 VictoriaMetrics 提供的一种查询语言，兼容 PromQL 并对其做 了增强，如果你的存储是 VictoriaMetrics，则可以使用这些扩展函数） 中的扩展函数。 count_gt_over_time 假设原始需求：某个指标（ 假设指标名字是 interface_status ）每分钟上报一次，如果