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-FalconZabbix后开发初衷解决Zabbix容量问题。最初来自小米14年开源当时小米有3套Zabbix1套业务性能监控系统perfcounter。Open-Falcon想大一统基于RRDtool做了分布式时序存储组件Graph可将多台机器组成一个集群大幅提升海量数据处理能力。负责转发的组件TransferTransfer对监控数据求取一个唯一ID再对ID哈希就可生成监控数据和Graph实例对应关系Open-Falcon最核心的分片逻辑。告警用Judge模块发送告警事件Alarm模块采集数据Agent心跳模块HBS聚合监控数据模块Aggregator负责处理数据缺失的模块是Nodata。和用户交互的Portal/Dashboard模块。Open-Falcon把组件拆散组件较多部署较麻烦。不过每个组件的职能单一二开易。优点可处理大规模监控场景比Zabbix的容量要大得多不仅可以处理设备、中间件层面的监控也可以处理应用层面的监控组件拆分散大都Go开发Web部分用Python易二开。缺点生态不大是小米公司在主导很多公司二开但都没回馈社区开源软件治理架构不够优秀小米公司核心开发人员离职项目停滞小米公司后续也没有大的治理投入相比托管在基金会的项目缺生命力3.3 新代方案代表Prometheus设计思路来自Google BorgmonBorgmon为Borg而生Prometheus为k8s而生。对k8s直接支持提供多种服务发现机制大幅简化k8s监控。k8s下Pod创建销毁频繁监控指标生命周期大幅缩短类似Zabbix这种面向资产的监控系统力不从心且云原生环境大都微服务设计服务数量变多指标量爆炸对时序数据存储高要求。1.0设计较差但2.0重新设计时序库性能、可靠性都大幅提升社区涌现越来越多Exporter采集器。优点k8s监控标配各种Exporter支持各种时序库作为后端存储支持多种语言SDK供业务代码嵌入埋点缺点易用性差如告警策略需要修改配置文件协同起来比较麻烦。当然了对于IaC落地较好的公司反而认为这样更好不过在国内当下的环境来看还无法走得这么靠前大家还是更喜欢用Web界面来查看监控数据、管理告警规则。Exporter参差不齐通常是一个监控目标一个Exporter管理起来成本比较高。容量问题Prometheus默认只提供单机时序库集群方案需要依赖其他的时序库。3.4 新国产代表NightingaleOpen-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可选PrometheusGrafana既兼顾传统设备、中间件监控场景又兼顾k8s做成公司级方案推荐Nightingale4 总结监控产品的需求来源即监控问题域从及时感知系统出现的问题到现在希望预知问题并可洞察业务经营数据监控越来越重要。指标监控因历史数据存储成本较低实时性好生态庞大。指标监控的开源方案监控系统优点缺点Zabbix设备兼容性好支持Aix架构简单易维护社区庞大关系型数据库存储时序数据容量有限面向资产的管理逻辑和指标格式设计不适云原生Open-Falcon支持水平扩展可处理海量监控数据组件拆分较散便于二次开发生态不够庞大近年来社区活跃度下降开源治理架构不好缺乏生命力Prometheus对 Kubernetes 监控做了原生支持生态庞大PromQL 灵活易用性有待提升特别是开放给全公司使用时不便协同Exporter 水平参差不齐管理成本较高Nightingale较完备UI可作为公司级统一监控产品赋能各个团队兼容并包生态开放可以和业界众多开源项目协同过渡设计默认的部署架构略复杂告警聚合降噪、收敛、闭环管理等功能暂时缺失