笔者从 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 了。这个想法近期会落地，有兴趣的可以联系我做天使客户，天使客户天使对待。
结语
本文是从监控系统的构建角度，从采集->传输->存储->可视化->告警->事件分发不同阶段做了简要分析，给了一些可能的解法，希望对大家有帮助。如果你对监控系统的构建有更好的想法，欢迎留言交流。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
