云原生监控的十大特点和趋势

云原生监控的核心变化，不只是从物理机迁移到 Kubernetes，也不只是换一套采集组件。它改变的是监控对象、数据模型、查询方式、使用人群和系统自身的架构要求。

本文从 Open-Falcon 与 Prometheus 的设计差异切入，梳理云原生监控正在呈现的十个特点和趋势，并说明为什么企业级监控产品需要在 Prometheus 生态基础上继续补齐易用性、扩展性、协同和开箱即用能力。

核心要点摘要

• 云原生监控的数据重心正在从主机和系统指标，转向 Mesh、Pod、App、Business 等更接近应用和业务的指标。
• Label 是云原生 Metrics 数据模型的关键能力，OpenMetrics、PromQL、OpenTelemetry 等生态标准正在共同塑造监控系统的设计边界。
• 监控系统的使用者已经从专职运维人员扩展到研发、测试、运营等更广泛群体，产品易用性、开箱即用和协同能力变得更重要。
• 在微服务和云原生架构下，Ad Hoc 查询、Metrics/Logs/Traces 关联、Insight & Knowledge 沉淀，正在成为评价监控产品能力的重要标准。
• 监控系统本身也需要云原生化，支持容器化部署、服务发现、PromQL、OpenMetrics、OpenTelemetry、Helm Chart、Kubernetes Operator 等能力。

为什么云原生监控会变成一个新问题

Open-Falcon 从写下第一行代码，应该是在 2012 年的冬天，开源于 2014 年。Open-Falcon 在设计之初，沉淀的主要是互联网公司在运维大规模物理机时代的优秀方法论，在简单易用、扩展性、性能方面倾注了较多的心思。凭借于此，Open-Falcon 开源之后迅速成为国内开源监控系统的首选，服务了上千家企业用户，并影响了国内互联网运维圈子一个阶段对于监控系统设计思路的理解。

然而在过去的十年，微服务架构与 Cloud-Native 相伴相生，各自在最好的时间遇到了最好的对方，并相互促进发展。微服务和云原生给服务与系统的可维护性带来了巨大挑战：系统整体复杂度更高，系统之间的相互依赖程度更高，可观测性被提到了 IT 系统有史以来重要的位置，成为系统设计天然不可分割的有机组成部分。

在这个领域，Prometheus 无疑已成为事实标准。

从 Open-Falcon 到 Prometheus：数据模型决定监控系统边界

Open-Falcon 算起来是和 Prometheus 同岁。当初的产品定位以及后续投入，已然埋下了今天差距的伏笔。这里仅以 Open-Falcon 数据模型中两个字段的定义，管中窥豹，说明当时设计思路中的纠结和折中。

{
    "metric": "load.1min",
    "endpoint": "open-falcon-host",
    "tags": "srv=falcon,idc=aws-sgp,group=az1",
    "value": 1.5,
    "timestamp": "`date +%s`",
    "counterType": "GAUGE",
    "step": 60
}

在上面的 data model 定义中，tags 字段和 Prometheus 中的 labels 字段是同样的效果。Labels 是云原生监控系统数据模型的灵魂，从这个点上可以看出，Open-Falcon 的设计并不落后于同时代的先进理念。

问题在于，Open-Falcon 在 tags 字段之外，又定义了一个特殊标签：endpoint。Endpoint 在物理机场景下一般会被设定为 hostname 或者 ip:port；在物联网场景下，一般是设备名称；在容器场景下，一般会是容器的 IP。

为什么当初要定义 endpoint 这样的一等公民标签？这个标签又有什么特殊性？说到底是在系统设计上犯了一个核心错误：定位不明确。既想满足当时处于主流的物理机运维模式，因为在物理机场景下 hostname 是最重要的一个“维度”；又想兼顾未来物联网、容器场景。后来的事实证明，定位不明确、不聚焦是行不通的。

相反，Prometheus 从第一天起就是单机版，并没有把重心放在扩展性问题上；从第一天起，就从 data model 定义上抛弃了 hostname，完全围绕 metric 字段，结合 label 形成灵活、普适的表达形式，并进一步形成了灵活的监控数据检索标准 PromQL；从第一天起，就咬定 Kubernetes，聚焦云原生场景，抓住主要矛盾，做标准，建生态。

至于性能、扩展性、易用性等问题，Prometheus 交由强大的生态伙伴在后来解决。这也从另一个角度印证了“过早的优化是万恶之源”。

云原生监控十大趋势总览

趋势一：Infra 层面监控数据比重变小，App 层面监控数据比重快速增加

有别于物理机时代更多关注主机、系统层面的 metrics，今天 Mesh、Pod、App、Business 层面所产生的 metrics 占到了更大比重。以生产实践中的统计为例，这类数据占比达到了 80% 上下。

这意味着云原生监控不能只回答“机器是否正常”，还要回答“应用是否正常”“服务调用是否正常”“业务链路是否正常”。监控系统需要从资源视角扩展到应用视角和业务视角。

趋势二：监控产品的使用对象发生变化

云原生时代，监控系统的使用群体发生了变化。它从面向规模较小、具备专业能力的专职运维工程师群体，变成了面向更广泛的研发、测试、运营人员群体。

因此，监控产品的体验好坏、入门门槛是否足够低、是否能够开箱即用，变得极为重要。监控系统也有往指标中台方向演进的趋势：让更多角色能够统一理解、检索、分析和复用指标。

趋势三：监控数据采集原则发生变化

应用对自身运行状态的自描述正在成为主流。数据的采集、存储、计算成本在下降，数据的重要性在凸显。此消彼长，数据应收尽收、治理前置，成为应用和系统开发人员的埋点原则。

eBPF 技术的发展和普及，使得数据捕获和应用层更解耦，可以在网卡、网络协议栈、内核等环节更高效地进行埋点和数据解析，并形成系统的、普适的解决方案。

趋势四：监控数据模型的维度变得更丰富

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

在物理机时代，hostname 往往是最重要的维度之一。但在云原生环境里，单一主机维度不足以描述服务状态。应用、服务、Pod、命名空间、集群、环境、业务标签等信息，都可能成为定位问题和聚合分析的关键维度。

趋势五：Metrics 的生命周期变得更短

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

监控系统如果仍然依赖长期稳定的 endpoint 或 hostname，就很容易在动态环境中丢失上下文。云原生监控需要围绕 label、服务发现和聚合查询来理解不断变化的指标对象。

趋势六：针对监控数据的 Ad Hoc 查询需求变大

在微服务和云原生架构下，单个 Pod 的状态监控重要性下降，用户更关心以 App 维度或者其他 Label 维度进行聚合查询。

这类 Ad Hoc 查询的灵活度和性能，如何在产品设计和系统架构设计上取得折中，变得非常关键。用户需要临时提出问题、快速组合维度、实时查看结果；系统则需要在查询体验、性能和成本之间找到平衡。

趋势七：Metrics 与 Logs、Traces 的关联关系重要性凸显

由于微服务和云原生架构的复杂度和封装程度提高，系统管理员和研发人员很难再去到具体机器和案发现场，通过查询日志等方式来 debug。

如何在监控系统层面将 metrics、logs、traces 相关信息打通，为研发、运维和运营人员提供更多便利，正在变得非常重要。

OpenTelemetry 试图从数据采集层面解决该问题。它通过定义和提供一组 APIs、SDKs、工具集以及对相关生态的集成，便于实现对 metrics、logs、traces 数据的创建和管理。

OpenTelemetry 提供了一个中立的实现，可以通过配置把可观测数据发送到各种流行的开源可观测系统，例如 Jaeger、Prometheus、ElasticSearch。但是到此为止，OpenTelemetry 并不会大包大揽，去实现一个类似 Jaeger 或 Prometheus 那样的后端存储、计算、可视化系统。

趋势八：基于数据而高于数据的 Insight & Knowledge 成为评价标准

在数据应收尽收的背景下，数据越来越多。如果缺乏有效的洞察手段和数据处理手段，数据多反而会变成一种干扰和负担。

如何提供全局统一的数据视图，建立有效的信息系统，把知识沉淀下来并赋能用户，对于监控产品可以发挥更大价值。

Real-Time Intelligent Incident Center 是搭建该信息系统的一个有效手段。Gartner 在 Hyper Cycle for Emerging Technologies, 2021 中，也对此做出了预测，Real-Time Incident Center 将在未来的 2 到 5 年到达成熟期。

趋势九：OaC / API-Driven 获得开发者青睐

体验优秀的交互设计和 Web UI，对于扩大用户使用群体、降低系统使用门槛帮助很大，也能够有效减少监控产品维护人员的客服成本。但是，工程师也容易诟病 ClickOps 的方式效率太低，不利于自动化，也缺乏重复执行的一致性。

在工程师群体内，对于云计算资源和服务的申请、使用、销毁等工作，通过 git pull-request 追踪版本变化和 change review，通过 pipeline 高度自动化运行，正在成为一种更高效和流行的文化。

OaC 就是监控在这个趋势下的产物之一，其背后依赖监控产品良好的 API 抽象。

Terraform 开源项目作为目前 IaC 领域的事实标准，本质上相当于把各个云所提供的能力和服务，透过其 API，换一种形式，以 code 的方法进行表达和管理。Code 最大的优势是一次编写、可重复运行并保证一致性。这使得 infra 和相关服务的上下线、扩缩容、加减配置、修改监控等操作，都可以高度自动化。

趋势十：监控系统本身也要云原生

监控系统自身也要先完成自我革新。一个云原生监控系统至少需要回答这些问题：

• 部署架构是否支持容器化；
• 是否支持以 binary、sidecar、daemonset 等多种方式运行；
• 是否支持 OpenTelemetry / OpenMetrics 相关标准；
• 是否支持 service discovery；
• 是否兼容 PromQL 等 Query Language；
• 是否可以方便地通过 docker-compose、Helm Chart、Kubernetes Operator 等方式运行和管理。

这些不是附加能力，而是云原生监控系统自身必须面对的基础要求。

关键术语解释

Prometheus 的企业级产品化痛点

如前所述，Prometheus 虽然已成为该领域的事实标准，但 Prometheus 的重心是在定标准、打造基础能力、构建生态。这个定位和认知，无限加强了它在监控基础能力和标准层面的影响力，但也制约了它在企业级产品化方向上的发展。

Prometheus 在企业级监控的产品特性上，仍然有很大的痛点至今未被很好满足，包括：

• 入门门槛高和易用性问题；
• 扩展性问题；
• 企业较大范围用户使用时的协同问题；
• all-in-one 开箱即用问题。

经过 Open-Falcon 的经验积累和认知迭代，结合云原生监控的趋势特点分析，2020 年，我们和滴滴技术团队推出了企业级云原生监控系统 Nightingale v5 开源新版本。Nightingale v5 重点聚焦云原生场景，在 Prometheus 的生态基础上，加强企业级特性、产品化创新以及解决方案落地。

简而言之，如果在架构云原生监控的过程中，有以下一个或多个困扰，可以联系我们一起探讨：

• 如果您对 Prometheus、Alertmanager、Grafana 等多个系统的割裂和上手难有怨言；
• 如果您对通过修改配置文件来管理 Prometheus、Alertmanager 的方式有痛点；
• 如果您对因为数据量过大而无法扩展您的 Prometheus 感到有困扰；
• 如果您在生产环境运行多套 Prometheus 集群面临管理和使用上的不便；
• 如果您在企业数字化转型过程中对于如何架构适合您的云原生监控方案有困惑。

Nightingale v5 支持的新特性

Nightingale v5 支持的新特性一览：

• 好用和实用的开源告警功能和事件中心；
• 原生内置 dashboard、故障自愈、Resource 管理功能；
• 支持多 Prometheus 数据源管理；
• 支持 Prometheus、M3DB、VictoriaMetrics、Influxdb 多种时序库；
• 原生支持 PromQL；
• 原生支持 Exporter 数据采集；
• 支持 Telegraf 做监控数据采集；
• 原生支持 Grafana。

一个典型的 Nightingale 企业级部署架构如下，以 VictoriaMetrics 作为时序数据库为例：

最后，关于十大特点中提到的 Gartner 所预测的 Real-Time Intelligent Incident Center，大家可以参考快猫星云 Flashcat 解决方案（https://flashcat.cloud）。

FAQ

Q1：云原生监控和传统物理机监控最大的区别是什么？

传统物理机监控更关注主机、系统层面的 metrics，hostname 往往是重要维度。云原生监控更关注 Mesh、Pod、App、Business 等层面的指标，并依赖 label 对动态对象进行描述、聚合和查询。

Q2：为什么 Label 是云原生 Metrics 数据模型的灵魂？

云原生环境中的对象生命周期更短、状态变化更频繁，单一 endpoint 或 hostname 难以表达完整上下文。Label 可以用灵活的键值维度描述指标，使查询、聚合和关联分析更适应动态环境。

Q3：OpenTelemetry 是否会替代 Prometheus、Jaeger 这类后端系统？

按本文口径，OpenTelemetry 主要试图从数据采集层面解决 metrics、logs、traces 的创建和管理问题，并提供中立实现，把可观测数据发送到 Jaeger、Prometheus、ElasticSearch 等系统。它并不会大包大揽，去实现类似 Jaeger 或 Prometheus 那样的后端存储、计算、可视化系统。

Q4：为什么 OaC / API-Driven 会受到开发者青睐？

因为代码化管理可以通过 git pull-request、change review 和 pipeline 提升自动化程度与重复执行的一致性。相比只依赖 ClickOps，OaC / API-Driven 更适合大规模、可审计、可复用的监控配置管理。

Q5：企业使用 Prometheus 时常见痛点有哪些？

本文提到的痛点包括 Prometheus、Alertmanager、Grafana 等多个系统割裂且上手难，通过修改配置文件管理系统存在痛点，数据量过大时扩展困难，多套 Prometheus 集群在生产环境中管理和使用不便，以及企业数字化转型过程中云原生监控方案架构选择困难。

结论

云原生监控的本质变化，是监控对象从稳定主机走向动态应用，数据模型从固定 endpoint 走向灵活 label，查询方式从预设视图走向 Ad Hoc 分析，使用人群从专业运维走向研发、测试、运营等更广泛角色。

Prometheus 抓住了云原生监控的主要矛盾：聚焦 Kubernetes，围绕 metric 与 label 建立数据模型，通过 PromQL 和生态形成事实标准。企业级监控产品则需要在这个生态基础上，继续补齐易用性、扩展性、协同、事件中心、知识沉淀和开箱即用能力。

关于夜莺监控 - Nightingale

夜莺监控是一款开源云原生监控分析系统，与云原生生态紧密集成，提供开箱即用的企业级的监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

• Github：github.com/ccfos/nightingale
• Proposal & Issues: github.com/ccfos/nightingale/issues
• Docs: n9e.github.io

关于快猫星云

快猫星云，一家云原生智能运维科技公司，秉承着让监控分析变简单的初心和使命，致力于打造先进的云原生监控分析平台，结合人工智能技术，提升云原生时代数字化服务的稳定性保障能力。

快猫星云团队是开源项目夜莺监控的主要贡献者、项目管理委员会核心成员。夜莺监控是一款开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力，已有众多企业选择将 Prometheus + AlertManager + Grafana 的组合方案升级为使用夜莺监控。

夜莺监控由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。