Prometheus 可能有多套）或者 Nightingale， 日志的监控可能用的 Elastalert，如果上云了，可能还会有多套不同的云监控（尤其是多云场景下）。 监控系统的重心，通常是采集、存储、可视化、生成告警事件，但通常都不具有完备的事件后续处理能 力。这里说的后续处理主要包括：多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升 级、协同闭环处理等等。监控系统或多或少都有 ncident），最终通知用户的是一个个故 障，大幅降低了打扰性。 不同的告警事件，通常有不同的分发逻辑，比如不同时段不同的分发逻辑：白天用短信通知，晚上用电话 通知，比如对象存储的告警要发给存储团队，物理机故障要发给运维团队。这都可以灵活定义。 也可以配置聚合窗口，比如延迟 120 秒，如果在延迟等待期内，告警自动恢复或被人工处理，则不会发送 该条告警。

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

Agentd Agentd LoadBalance 1. 单机版Prom 2. 集群版m3db 3. 集群版n9e-tsdb 3种存储方案，按需选择 Agentd 夜莺设计实现 Agentd 数据采集 第四部分 监控系统的核心功能，是数据采集、存储、分析、展示，完 备性看采集能力，是否能够兼容并包，纳入更多生态的能力， 至关重要 夜莺数据采集 01.监控数据采集，all in