事件 ONCALL 中心建设方法 一站式处理值班 OnCall，智能降噪 北京快猫星云科技有限公司 前言 市面上有众多监控系统，刨去商业软件不说，开源的就有 Nagios、Zabbix、Open-Falcon、 Nightingale、Grafana、Prometheus、Elastalert 等等，还有云厂商提供的监控系统，比如华为云的云 监控、腾 的告警规则很多，大概率也有问题，说明系统架构不够鲁棒，出点什么事都要立刻介 入，系统没有自愈能力。这样的系统，需要配备更多运维人员，而且还很难跟老板讲清楚价值。怎么办？ 这就需要制定运维准入规则，哪个系统要交给运维人员来运维，首先要提供一些信息。 ● 相关联系人，出了问题能够及时找到人，联系不上的话得能直接联系研发领导。 ● 服务相关信息，比如代码仓库、系统架构、依赖哪些服务、依赖哪些系统参数、哪些 数、哪些 JVM 参数、常 见问题还有处理办法等等。 然后进行准入评审及准入测试，如果系统架构有明显问题，就没办法通过准入要求，不接受运维，如果老 板要求必须接，那就只能加人了，或者明确说明在架构调整好之前，不负责 SLA，反推业务改造。 上面介绍的两个告警规则优化原则，是最重要的两个原则。照做的话，可以搞定大部分无效告警。 除了原则方面，另一个应对过多告警的方法

参考文档：https://valyala.medium.com/prometheus-vs-victoriametrics-benchmark-on-node-exporter-metrics-4ca29c75590f 总体架构 总体架构 T H A N K S !

• prometheus • ⽀支持任意维度label • cncf基⾦金金会 metric • 40w+/s的指标采集 • 10k+ 监控⽬目标 • 10+ prometheus节点 现状: • 性能 • ⾼高可⽤用 • 分布式 • 使⽤用成本 问题: ? 性能问题 • 本地ssd prometheus Shard A prometheus Shard