快猫星云来炜：现代化监控系统这样演进、发展才稳妥！

ITPUB 2023-03-24

753

今天的分享主要围绕着我所主导和重度参与的两个开源项目，Open-Falcon 和夜莺监控展开，管中窥豹，和大家一起探讨交流监控系统的发展和演进。

大家可以看到，在CNCF landscape中，在监控分析这个大的领域中，涌现出了特别多的优秀项目，为什么会发生这样的变化？

这和过去10年，技术架构的演进变革有关。在过去的十年，微服务架构与云原生技术，相互促进发展，成为巨大的技术变革浪潮，而监控分析是云原生技术架构的关键因素之一。

微服务和云原生，带来的好处，在我看来，最核心的有两点：

1.低耦合：使得我们具备了构建更大规模的系统的能力，并且通过极致的低耦合，从技术根本上，提升了协作的效率，从而带来了软件迭代效率的提升。

2.弹性：如果说云原生架构，只允许保留一个特性，你怎么选？我会选择保留“弹性”。过去很长一段时间，系统的可扩展性，是摆在架构师、运维等技术人员面前的头等问题，今天借助于云原生架构和微服务模型，我们可以快速地获取和释放资源，自动化地对我们系统规模进行扩缩容。同时我们把资源的供应单位，切割的粒度变得更小，进行自动化的编排调度。进而，带来了资源使用效率的革命性提升。

用经验总结编织、及时调“方向”，以反思复盘催熟Open-Falcon“新计划”

微服务和云原生，带来好处的同时却也有代价？

但代价是什么？微服务和云原生，给系统的可维护性，带来了巨大的挑战，系统的整体复杂度和系统之间的相互依赖程度更高，因此，监控分析，成为一个关键支撑因素。Open-Falcon 和夜莺监控，也是在这样的大背景下，发展和成长起来的。

要回答Open-Falcon为什么会流行，那就得先回到2013年，从需求说起。当时我在小米工作，公司的互联网业务飞速发展，业务规模越来越大，监控系统的容量有限和业务的体量快速膨胀，成为核心矛盾。

Open-Falcon架构设计上的思考要点

所以，Open-Falcon在架构设计上，一个最关键的考量点就是“如何做到水平扩展”。

架构设计上的一些思考要点如下：

1.定义了可扩展的数据模型（label），引入了标签的概念，可以大大增强监控指标的表达能力；

2.从一开始就设计了专属的数据采集器falcon-agent，数据采什么、怎么采、采了怎么用，都考虑到了，做到了开箱即用，知识沉淀。

3.数据采用“推”的方式；falcon-agent采集到的数据，直接推送到transfer组件，当然用户也可以通过transfer的api来推送自定义数据；（保障了时效性、方便研发团队接入数据）。

4.transfer 组件，是数据传输网关，可以水平扩展，同时transfer会根据一定的数据分片规则，将数据推送给存储模块graph、以及告警判定模块judge。

5.在整个Open-Falcon的架构中，核心思想是采用数据分片架构解决扩展性问题。比如 transfer 模块本身是无状态的，可以水平扩展；graph组件是按照一致性hash算法对数据进行分片存储，judge模块也是按照一致性hash算法来处理特定分片的数据和任务。

6.最后，Open-Falcon 不仅仅是一个工具，更多的是一个产品，将互联网公司的运维经验沉淀到产品中，同时具有较高的产品完成度，在数据采集、管理portal、可视化、告警判定、告警通知等方面，都有不错的表现。

缺点：

1.在数据模型上，虽然很早（2013年）就引入标签的维度，但是未能和Prometheus的数据模型看齐，导致后续在生态的融合上出现额外的障碍。

2.采用推的数据模型，在“控制”方面会比较弱（要做好流控、脏数据控制等能力），对于数据中断的监控无法感知（增加了“nodata”的额外逻辑，Prometheus是在scrape数据的时候，提供了target_up指标）。

3.流式的judge模型，天然无法很好的解决多条件组合报警等复杂判定（aggregator解决了一部分问题）。

4.proxy架构，没有很好的解决数据再平衡的问题（虽然提供了扩缩容时migrate数据的方案，但是运维操作比较复杂）。

5.基于RRD的数据格式，环状数据库，虽然磁盘的使用效率很高，但是磁盘 IO 负载很高（虽然做了优化，将小文件的随机写入，加了写的缓存，修改为批量写入等，但距离理想效果还有差距）。此外对于ad-hoc查询，支持比较弱。

Open-Falcon掉队，发展卡在“瓶颈”关口

Open-Falcon的发展为什么遇到了瓶颈，除去上面提到的设计上的一些缺陷，更重要的是，Open-Falcon一直未能建立起开放、自治的社区。可以看到，有很多的公司都在基于Open-Falcon做二次开发，很多的公司在自己的JD中注明，需要熟悉Open-Falcon二次开发。但是Open-Falcon 的贡献者数量停留在了100位之后就基本停滞了，未能持续的形成合力。

瓶颈二，原因在于，Open-Falcon关注的更多是物理机架构的监控方案，未能很好的跟上云原生架构转型的步伐。

云原生监控的发展特点和趋势再分析

那云原生时代的监控，有怎样的特点和变化趋势呢？

1、首先，数据量的大幅提升，尤其是app 层面监控数据比重快速增加

有别于物理机时代，更多在关注主机、系统层面的 metrics，在今天，Mesh、Pod、App、Business 层面，所产生的 metrics 占到了更大比重，以生产实践中的统计为例，占比达到了 80% 上下。这对数据采集和存储，都带来了新的挑战。

2、监控数据的采集原则发生了变化

数据的采集、存储、计算的成本在下降，数据的重要性在凸显，此消彼长，数据应收尽收，治理前置，成为了应用和系统开发人员的埋点原则。此外，eBPF 技术的发展和普及，使得数据捕获和应用层更解耦，在网卡、网络协议栈、内核等环节更高效的进行埋点和数据解析，并有望形成系统的、普适的解决方案。

3、监控数据模型的维度变得更丰富

以指标类型的监控数据为例，Label 作为云原生 Metrics 数据模型的灵魂，Open Metrics 成为事实上的云原生 metrics 标准。数据维度更多，对监控系统的架构设计、扩展性、产品交互体验，提出了挑战。

4、监控数据的生命周期变得更短、更不确定

比如，在微服务和云原生架构下，Pod 的生命周期不再是长期的，其状态变化的频率也更高，这使得对于监控数据的连续性追踪和关联分析变得更困难。

5、针对监控数据的 Ad Hoc 查询需求变大

在微服务和云原生架构下，单个 Pod 的状态监控重要性下降，用户更关心以 App 维度，或者其他 Label 维度的聚合查询，此类 Ad Hoc 查询的灵活度和性能，如何在产品设计和系统架构设计上取得折中，如何在保证灵活度的同时，控制好长尾请求的表现，变得非常关键。

6、Metrics 与 Logs、Traces 需要融会贯通。相互打通以及建立关联关系重要性凸显

由于微服务和云原生架构的复杂度和封装，使得系统管理员和研发人员，很难再去到具体的机器和案发现场，通过查询日志等方式来 debug。如何在监控系统层面，将 metrics、logs、traces 相关信息打通，对于研发、运维和运营人员，能提供更多的便利。

7、监控产品的使用对象发生了变化

云原生时代，监控系统的使用群体发生了变化，从面向规模较小的，具备专业能力的专职运维工程师群体，变成了更广大的研发、测试、运营人员群体，监控产品的体验好坏、入门门槛足够低、是否能够开箱即用，变得极为重要。

此外，在数据应收尽收的背景下，数据多，如果缺乏有效的洞察手段和数据处理手段，那么数据多反而会变成一种干扰和负担。如何提供全局统一的数据视图，建立有效的信息系统，把知识沉淀、赋能，对于监控产品的用户可以发挥更大价值。

8、监控系统本身也要云原生

监控系统自身的部署架构是否支持容器化，以 binary、sidecar、daemonset 等多种方式运行，是否支持 opentelemetry open metrics 相关标准，是否支持 service discovery，是否兼容 PromQL 等 Query Language，是否可以方便的通过 docker-compose、helm chart、k8s operator 等方式运行管理。这些都是作为一个云原生监控系统本身要先自我革新的方面。

最后，我们也逐步从关注如何生产数据，到进入管好数据，以及如何用好数据的新阶段。

基于之前我们做Open-Falcon的经验总结反思，结合云原生监控的发展特点和趋势，我们重新思考，一个现代化的监控系统，应该是什么样的？

把好看、简单、功能全面，摆在第一位

夜莺监控就是基于这样的大背景下诞生和发展起来的。使用夜莺既可以监控传统的物理机架构、可以监控微服务架构和K8s，也可以监控公有云的资源和服务。提供统一的监控数据视图，提供集中化的可视化和管理界面。换句话说，你可以使用夜莺监控，来完成zabbix + Prometheus + grafana + 云监控的工作。

关于夜莺监控的设计目标，好看，简单，功能全面，摆在了第一位。

1、同时适合传统架构 & 云原生架构 & 混合云架构；

2、多数据源架构设计，适应灵活多变的部署环境和生态；

3、可扩展架构设计，水平灵活扩展；

4、兼顾中心化部署和边缘设备集群管理；

5、Go语言开发，安全，易维护，架构简洁；

夜莺监控由数据采集器、告警引擎、可视化引擎、告警自愈引擎构成。夜莺的设计非常简单，核心是 server 、webapi、frontend 三个模块。

webapi 无状态，中心端部署，承接前端frontend的请求，将用户配置写入数据库，同时对外提供API 供frontend 使用；

server 是告警引擎，也承担数据处理、转发功能，一般伴随着时序数据库部署，一个时序库就对应一套 server，每套 server 可以只启动一个实例，也可以启动多个实例组成集群。

server 可以接收 Categraf、Telegraf、Grafana-Agent、Datadog-Agent、Falcon-Plugins 等多种数据采集器上报的数据，写入后端时序数据库，并周期性从数据库同步用户配置的告警规则，查询时序数据库进行告警判断。

快猫星云自研的数据采集器Categraf，是夜莺默认的数据采集器，有以下特点：

1、All-in-one：所有的采集工作使用一个 agent 来解决，包括 metrics、logs、 traces ，并从数据采集的源头建立起数据间的关联关系，保障好数据的质量。

2、开箱即用：覆盖支持上百种采集对象，包括K8s、中间件、服务器、交换机等，针对常用的采集对象，在提供采集能力的同时，配套有默认的监控仪表盘模板和告警规则模板，用户可以直接导入并使用。

3、部署方式灵活：支持在 K8s 集群中以 Daemonset 或者 Sidecar 运行，支持公有云产品的数据采集，也支持独立运行在宿主机上。

4、Go语言开发：安全、易分发、易安装维护，插件化。

告警功能：

1、支持多数据源告警，Prometheus、Victoriametrics、M3DB、Thanos，ElasticSearch、SLS；

2、多种告警判定策略，多条件策略，生效周期，产品化配置和管理；

3、多通知渠道和自定义通知模版；

4、支持故障自愈和告警 Webhook；

5、支持告警聚合、收敛、排班、协同（需要对接Flashcat SaaS应用）；

自研可视化引擎，对标Grafana:

俗话讲，一图胜千言，可视化是透传数据价值最直接的手段。夜莺监控的 Dashboard 不仅从功能、设计上可以对标 Grafana，同时也兼容 Grafana，要是你觉得 Grafana 某个 Dashboard 非常有用，甚至可以直接导入到夜莺监控中使用。

此外，夜莺监控的 Dashboard 支持多种数据源，比如时序数据库 Prometheus、Victoriametrics、M3DB、Thanos，又比如日志·数据源 ElasticSearch、SLS 等。

曾挨“几拳”再爬起，破局“出圈”弄潮博浪

夜莺监控，从 2020 年 3 月份开源，累计迭代发布了80 多个版本，获得了众多用户和企业的关注，获得超过 5500 颗 Star。吸引了 80 多位外部代码贡献者，每 5 个Star，产生 1 次 Fork；每 10 次 Fork，产生1 位 Contributor。

更进一步，2022年5月11日，夜莺监控正式捐赠给了中国计算机学会开源发展委员会，成为中国计算机学会开源发展委员会接受捐赠的一个开源项目。

夜莺开源社区，拥有了一个很好的起点。

开源项目要更有生命力，离不开开放的治理架构和源源不断的开发者共同参与，如果能从制度上，确立好中立、开放的机制，那么开源社区就有了坚实的地基。

夜莺监控项目加入 CCF 开源大家庭后，在CCF开源发展委员会的支持和带动下，进一步结合云原生、可观测、国产化等多个技术发展的需求，建立开放、中立的开源治理架构，致力于打造更专业、有活力的开发者社区。发布了夜莺监控开源社区治理架构草案，建立了用户、贡献者、committer、项目管委会的用户体系和管理制度，并公示了相关的任命和社区荣誉。

尊重、认可和记录每一位贡献者的工作，是夜莺开源社区的最高指导原则，在这里，我们强调每一位参与者的贡献，都应该被看见。结合我过去运营开源软件和社区的体会来看，“参与感”是超过物质激励，且更持久的一种激励方式。