0 前言

• 先看监控的需求来源，即监控系统可做什么
• 再跳出监控，从可观测性，看监控与日志、链路间的关系及它们各自的作用
• 最后介绍开源社区几个有代表性的方案以及它们各自的优缺点，便于你之后做技术选型。

1 监控需求来源

系统出问题我们能及时感知。随时代发展，对监控系统提出更多诉求：

• 通过监控了解数据趋势，知道系统在未来的某个时刻可能出问题，预知问题
• 通过监控了解系统的水位情况，为服务扩缩容提供数据支撑
• 通过监控来给系统把脉，感知到哪里需要优化，比如一些中间件参数的调优
• 通过监控来洞察业务，提供业务决策的数据依据，及时感知业务异常

目前监控系统越来越重要，同时也越来越完备。不但能很好地解决上面这几点诉求，还沉淀很多监控系统中的稳定性相关的知识。当然，这得益于对监控体系的持续运营，特别是一些资深工程师的持续运营的成果。

2 可观测性

指标监控

监控系统，只是指标监控，通常折线图，如某机器CPU利用率、某数据库实例的流量或者网站的在线人数，都体现为随时间变化趋势图。

指标监控只能处理数字，但历史数据存储成本较低，实时性好，生态庞大。开源有Zabbix、Prometheus。

日志

可得很多信息，了解软件运行情况、业务运营情况。如：

• 操作系统的日志中，可以得知很多系统级事件的发生
• 接入层的日志中，可以得知有哪些域名、IP、URL 收到了访问，是否成功以及延迟情况等
• 服务日志中可以查到 Exception 的信息，调用堆栈等，对于排查问题来说非常关键

但是日志数据通常量比较大，不够结构化，存储成本较高。

处理日志如ELK和Loki，商业产品Splunk和Datadog。

链路追踪

微服务一个问题具体是哪个模块导致。链路追踪以请求串联上下游模块，为每个请求生成一个随机字符串作请求ID。服务之间互相调用时，把该ID逐层往下传递，每层分别耗费多久，是否正常处理，收集附到该请求ID。后面追查问题，拿请求ID提取串联的所有信息。

经常也会从日志提取指标，转存到指标监控系统，或从日志中提取链路信息来做分析。

3 开源方案选型

3.1 老代表Zabbix

擅长设备、网络、中间件监控。早年监控系统主要用来监控设备和中间件，所以Zabbix应用广泛。

构成

Zabbix Server与可选组件Zabbix Agent。Zabbix Server通过SNMP、Zabbix Agent、JMX、IPMI等多种方式采集数据。

配套组件，Zabbix Proxy、Zabbix Java Gateway、Zabbix Get、Zabbix WEB等，共同组成Zabbix整体架构：

优点

• 对各种设备的兼容性较好
• 架构简单，使用数据库做时序数据存储，易于维护，备份和转储都较易
• 社区庞大，资料多。12年开源，发展时间久，海量资源

缺点

• 使用数据库做存储，无法水平扩展，容量有限。若采集频率较高如10秒一次，上限大约可监控600台设备，还要把数据库部署在一个高配机器，如SSD或NVMe盘
• Zabbix面向资产的管理逻辑，监控指标的数据结构较固化，无灵活的标签设计，面对云原生架构动态多变环境，力不从心

3.2 老国产代表Open-Falcon

Zabbix后，开发初衷解决Zabbix容量问题。最初来自小米，14年开源，当时小米有3套Zabbix，1套业务性能监控系统perfcounter。Open-Falcon想大一统：

基于RRDtool做了分布式时序存储组件Graph，可将多台机器组成一个集群，大幅提升海量数据处理能力。负责转发的组件Transfer，Transfer对监控数据求取一个唯一ID，再对ID哈希，就可生成监控数据和Graph实例对应关系，Open-Falcon最核心的分片逻辑。

告警用Judge模块，发送告警事件Alarm模块，采集数据Agent，心跳模块HBS，聚合监控数据模块Aggregator，负责处理数据缺失的模块是Nodata。和用户交互的Portal/Dashboard模块。

Open-Falcon把组件拆散，组件较多，部署较麻烦。不过每个组件的职能单一，二开易。

优点

• 可处理大规模监控场景，比Zabbix的容量要大得多，不仅可以处理设备、中间件层面的监控，也可以处理应用层面的监控
• 组件拆分散，大都Go开发，Web部分用Python，易二开。

缺点

• 生态不大，是小米公司在主导，很多公司二开，但都没回馈社区
• 开源软件治理架构不够优秀，小米公司核心开发人员离职，项目停滞，小米公司后续也没有大的治理投入，相比托管在基金会的项目，缺生命力

3.3 新代方案代表Prometheus

设计思路来自Google Borgmon，Borgmon为Borg而生，Prometheus为k8s而生。对k8s直接支持，提供多种服务发现机制，大幅简化k8s监控。

k8s下Pod创建销毁频繁，监控指标生命周期大幅缩短，类似Zabbix这种面向资产的监控系统力不从心，且云原生环境大都微服务设计，服务数量变多，指标量爆炸，对时序数据存储高要求。

1.0设计较差，但2.0重新设计时序库，性能、可靠性都大幅提升，社区涌现越来越多Exporter采集器。

优点：

• k8s监控标配
• 各种Exporter，支持各种时序库作为后端存储，支持多种语言SDK，供业务代码嵌入埋点

缺点：

• 易用性差，如告警策略需要修改配置文件，协同起来比较麻烦。当然了，对于IaC落地较好的公司，反而认为这样更好，不过在国内当下的环境来看，还无法走得这么靠前，大家还是更喜欢用Web界面来查看监控数据、管理告警规则。
• Exporter参差不齐，通常是一个监控目标一个Exporter，管理起来成本比较高。
• 容量问题，Prometheus默认只提供单机时序库，集群方案需要依赖其他的时序库。

3.4 新国产代表Nightingale

Open-Falcon的延续，因为开发是一拨人，但定位不同：

• Open-Falcon 类似Zabbix面向机器设备
• Nightingale不止解决设备和中间件的监控，也解决云原生监控。

但k8s下Prometheus已大行其道，重复造轮无意义，所以 Nightingale 和 Prometheus 整合，打造更完备方案。当下主要把 Prometheus 当时序库，作为 Nightingale 的一个数据源，如用 VictoriaMetrics 时序库也可。

优点：

• 有比较完备的UI，有权限控制，产品功能比较完备，可以作为公司级统一的监控产品让所有团队共同使用。Prometheus一般是每个团队自己用自己的，比较方便。如果一个公司用同一套Prometheus系统来解决监控需求会比较麻烦，容易出现我们上面说的协同问题，而Nightingale在协同方面做得相对好一些。
• 兼容并包，设计上比较开放，支持对接 Categraf、Telegraf、Grafana-Agent、Datadog-Agent 等采集器，还有Prometheus生态的各种Exporter，时序库支持对接 Prometheus、VictoriaMetrics、M3DB、Thanos 等。

缺点：

• 考虑到机房网络割裂问题，告警引擎单独拆出一个模块下沉部署到各机房，但很多中小公司无需这么复杂架构，部署维护起来较麻烦
• 告警事件发送缺少聚合降噪收敛逻辑，官方解释是未来会单独做一个事件中心的产品，支持Nightingale、Zabbix、Prometheus等多种数据源的告警事件，但目前还没放出

选型：

• 主要监控设备，推荐Zabbix
• 监控k8s，可选Prometheus+Grafana
• 既兼顾传统设备、中间件监控场景，又兼顾k8s做成公司级方案，推荐Nightingale

4 总结

监控产品的需求来源，即监控问题域，从及时感知系统出现的问题，到现在希望预知问题，并可洞察业务经营数据，监控越来越重要。指标监控因历史数据存储成本较低，实时性好，生态庞大。指标监控的开源方案：