杂一些生产实践场景，希望对你有所帮助。 ? 本文作者：秦晓辉，Open-Falcon、Nightingale 等开源项目创始人之一，极客时间《运 维监控系统实战笔记》作者；当前在创业（快猫星云联创），为客户提供监控/可观测性产品 方案，有需求的朋友欢迎联系我的微信 picobyte。 数据类型 Prometheus 有四种数据类型：Gauge、Counter、Histogram、Summary，其中最关键的是 的常规知识，尽量融入了一些生产实践的场景，当然，PromQL 还有 更多函数没有介绍，大家可以阅读其文档学习。 我是来自快猫星云（https://flashcat.cloud/）的秦晓辉，在监控/可观测性道路上，伴你前行 :-)

除了原则方面，另一个应对过多告警的方法就是靠产品工具了，比如告警事件在哪些时间段发送、如何过 滤、如何屏蔽、如何抑制等等，通常，监控系统和统一的 OnCall 中心（ PagerDuty FlashDuty 这种产 品）在这些功能上会有一定的重叠，不过监控系统在这方面做得参差不齐，整体能力偏弱，使用统一的 OnCall 中心功能更强大，我们留待工具实践篇再详细阐述。 接下来我们聊一下“告警疏漏、无法闭环 通过排班、认领、升级这些机制，可以确保告警递达指定的人，但要处理告警的话，只有值班人员自己就 未必搞得定了，需要有协同机制把相关人都拉进来一起处理才可以。对于某个故障，可能同时有多个告警 事件产生，大家基于一个统一的故障协同，而不是基于一堆事件分别协同，这就需要把这多个事件收敛成 一个故障，下面我们来聊一下这个收敛逻辑。 告警收敛逻辑 一般收敛逻辑是三级收敛，event -> alert -> 的一些现场信息，相比收到告警之后手工登录机器查看要高效得多。 如上，是从思路方法层面，对事件的处理做了逻辑讲解。要求所有的监控系统实现这些能力不太现实，而 且会造成一个一个的事件孤岛，所以典型的做法是把所有监控系统生成的事件统一聚合到一个平台来处 理，这就是 OnCall 中心，下面我们以 FlashDuty 来举例，讲解 OnCall 中心的工具实践。 工具实践篇 称手好用的工具是可以大幅提升效率的，同时