笔者从 14 年开始做监控，从 Open-Falcon 到后来的 Nightingale，到现在接近 10 年，认知在持续迭代，最近又有一些新想法，跟大家分享一下我眼中的理想的监控系统到底是什么样的。

关于采集器

市面上有众多采集器，比如 telegraf、categraf、grafana-agent、datadog-agent 以及 Prometheus 生态的各类 Exporter，但没有一个是完美的。采集器的理想形态应该是做成两个进程组件，一个部署到所有 OS 上，以 Daemonset 方式来跑，采集机器上的 OS 指标、日志、eBPF 等数据，因为这些数据必须要和操作系统、文件系统交互，所以一个部署到所有机器上的 agent 必不可少，后面计划让 Categraf 往这个方向演进。还需要另外一个进程组件，做探针类的采集，比如采集 MySQL、Redis、Kafka、ElasticSearch 等组件的数据，这个进程组件可以作为 Sidecar 模式和被采集对象部署到一起，也可以在中心作为 Deployment 部署，采集远端的监控目标，要支持良好的对象目标发现，引入 Prometheus 中的各类 SD 机制，最近新起了一个开源项目是cprobe，就是专门做探针采集器。

传输中转

如果只是指标数据，量比较小，一般可以直接让采集器直连 TSDB 推数据。如果担心服务端挂了，采集器就需要把数据临时缓存起来，等服务端好了再继续推，这种需求并不是所有的采集器都能很好的满足，推荐使用 vmagent 或 Vector 做个中转，vmagent 有缓存和重试机制，如果后端是 VictoriaMetrics 的话，vmagent 写数据到 VM 后端会走一个压缩比更高的协议而非 Prometheus remote write，另外 vmagent 支持接收不同协议的监控数据，兼容并包，这也是一个优点。Vector 的话，一般用于清洗和转发日志，替换 logstash 的，当然 Vector 也可以中转指标。

小结：各机房之间网络链路很好，让采集器直推服务端即可，如果要做的更鲁棒一些，中间可以加 vmagent 或 Vector 做中转。

存储

性能监控数据通常是写到各类时序库，比如 VictoriaMetrics、Prometheus、Thanos、M3DB，如果是新用户，一般就建议使用 VictoriaMetrics，稳如老狗。当然了，业务监控数据（比如订单量、交易支付量）可能存在 OLTP 或 OLAP 的库里，业务数据也是一个很好的监控数据源。另外，日志一般就是存 ElasticSearch、ClickHouse 中，日志告警也是有很强的场景诉求的。

小结：从监控系统构建的角度，存储是个大杂烩，不同的数据写不同的存储，而这，就需要上层的可视化平台和告警平台能够对接这些存储，做统一分析和告警。

可视化

Grafana 就好。能够很好的支持各类存储的可视化。Nightingale 也可以，在 TDengine 等个别数据源的支持上体验更好，但 Grafana 整体能力更强大，生态也更好。

告警

首先，因为存储是个大杂烩，告警系统就需要能够对接各类存储，比如做指标告警可能要对接 Prometheus、VictoriaMetrics，做日志告警可能要对接 ElasticSearch、Loki、ClickHouse，做业务指标的告警可能要对接 MySQL、Postgres。而且要处理不同的告警方式，比如阈值告警、数据缺失告警、数据存在告警、智能算法告警等等。目前只有 Nightingale 和 Grafana 走在这个路上，但是也远远没有达到理想的状态。

除了对接不同的数据源做指标、日志、智能告警，还要支持模板仓库沉淀经验，支持不同的生效时间（甚至要考虑节假日），支持灵活的评估表达式，支持自定义 labels、annotations，支持留观时长，支持是否推送恢复事件的控制，支持事件生成次数和频率的控制，等等等等。后面会让 Nightingale 逐渐往这些方面演化迭代。对于不想自己搭建告警系统的用户，我后面会搞一个 SaaS 服务给大家用。

事件分发

告警事件产生之后，还有后面的分发过程，除了要能够灵活的根据标签做分发，还需要做告警聚合降噪、认领、告警升级、排班OnCall、IM协同等工作。因为告警引擎通常产生告警事件就完事了，不会对后续的事件处理做太多功能支持，这就需要一个单独的产品来做这些事情，这个产品也能够聚合接收各类监控系统的事件，比如 Zabbix、Prometheus、Nightingale、Grafana、各类云监控。

这类型的产品国外首选 PagerDuty 和 OpsGenie，国内首选 FlashDuty 和 睿象云，屁股决定脑袋，笔者个人自然更推荐 FlashDuty，其产品介绍地址在这里：

https://flashcat.cloud/product/flashduty/

另外，我有想法直接让 FlashDuty 内置告警引擎，来直接对接各类存储做告警，这样大家就不用自己搭建告警系统了，直接用 FlashDuty 就可以完成告警+事件分发。大家只需要着力做好数据采集、存储、展示就 OK 了。这个想法近期会落地，有兴趣的可以联系我做天使客户，天使客户天使对待。

结语

本文是从监控系统的构建角度，从采集->传输->存储->可视化->告警->事件分发不同阶段做了简要分析，给了一些可能的解法，希望对大家有帮助。如果你对监控系统的构建有更好的想法，欢迎留言交流。