Harness 中的内置度量聚合与 Prometheus 导出

Harness 中的内置度量聚合与 Prometheus 导出从观测到统一可视化的完整指南一、引言1.1 钩子DevOps/SRE 工程师的“观测双簧痛”你是否有过这样的经历周五下午本已收拾好电脑准备奔赴周末的露营/剧本杀/火锅局突然手机收到三条级联告警生产环境的微服务部署频率骤降 70%、K8s Pod CrashLoopBackOff 告警率飙升、Grafana 里的 PromQL 查询「harness_deployment_success_rate{app“frontend”,env“prod”}」返回的居然是「No Data」你手忙脚乱地打开 Harness CDEContinuous Delivery Engine检查最近的部署——发现部署记录明明在但 Prometheus 里的指标却断了而且 Harness 内部的「Deployment Insights」面板里只有最近 1 小时的聚合数据想追溯上周四类似的部署异常原因完全找不到线索又或者你是团队的 SRE 负责人既要管理 Harness 自带的 CD/CI 观测指标部署成功率、时长、回滚次数又要同时监控应用层Spring Boot Actuator、基础设施层AWS CloudWatch/GCP Monitoring、K8s 层kube-state-metrics的指标每次排查问题都要在5-6 个不同的观测系统/面板之间跳来跳去甚至连同一个维度的指标比如不同命名空间的 Pod 重启都没法放在同一张 Grafana 仪表盘上做趋势对比这就是我——一位有 8 年 DevOps/SRE 经验、踩过至少 100 个观测集成坑的技术老兵——曾经甚至偶尔现在切换环境的时候的真实写照。而这一切的核心痛点总结起来只有两个字「割裂」——Harness 作为企业级的 DevOps 全生命周期平台自带了强大的观测能力但这些观测数据要么被「关」在平台内部的「小盒子」里Export 之前只有 1 小时的原始数据、最多 30 天的粗粒度聚合要么导出的方式要么极其复杂需要自己写 REST API 轮询脚本、处理数据格式转换、处理 Prometheus 的 Label 规范问题要么功能不全早期的 Harness Export 只支持部分 CI/CD 指标不支持 Chaos Engineering、Service Reliability ManagementSRM、Feature Flags 的指标。不过好消息是从Harness NextGen2021 年 Harness 推出的新一代平台架构开始Harness 不仅重构了整个观测系统的底层架构推出了内置的「度量聚合引擎Metric Aggregation Engine, MAE」还提供了开箱即用、高度可配置的 Prometheus Exporter 组件Harness Prometheus Exporter, HPE彻底解决了上述的「观测双簧痛」——你可以在 Harness 内部用 MAE 对多源CI、CD、SRM、Chaos、Feature Flags、甚至自定义的 REST API 指标观测数据进行实时聚合、预计算、标签增强、阈值过滤、数据标准化不仅能生成自定义的 SLOService Level Objective、错误预算追踪指标还能把聚合后的原始数据保留更长时间NextGen SaaS 默认是 90 天Self-Hosted 可以无限期保留用 HPE 把MAE 聚合后的指标、或者 Harness 内部的原始指标可选直接导出到 Prometheus或任何兼容 Prometheus Remote Write 协议的系统比如 Thanos、Cortex、VictoriaMetrics然后在 Grafana 里和应用/基础设施/K8s 的指标做统一可视化、统一告警、统一根因分析Root Cause Analysis, RCA甚至可以反过来把 Prometheus 里的指标作为Harness 的「外部数据源External Data Source」导入 MAE用来触发部署验证Deployment Verification、SLO 告警、回滚策略Rollback Strategy、甚至自动化的 Chaos 实验。是不是听起来很心动别急这篇文章我会带你从零开始系统地学习 Harness NextGen 中的内置度量聚合与 Prometheus 导出的所有核心概念、底层架构、最佳实践、以及完整的实战案例——不管你是 Harness 的新手还是已经在用 Harness 但想提升观测能力的老用户这篇文章都能帮你解决实际问题。1.2 定义问题/阐述背景为什么 Harness 要做内置 MAE 和 HPE在深入讲解核心内容之前我们得先搞清楚一个问题既然 Prometheus 已经是云原生观测领域的事实标准De Facto Standard为什么 Harness 还要自己做一个内置的度量聚合引擎为什么还要单独提供一个 Prometheus Exporter直接让所有的 DevOps 工具都导出 Prometheus 指标不就行了要回答这个问题我们得从DevOps 观测的发展历史和企业级观测的实际需求两个维度来分析1.2.1 DevOps 观测的发展历史从「单点监控」到「全链路可观测性」DevOps 观测的发展历史其实就是软件架构从「单体应用」到「微服务」再到「云原生微服务Serverless边缘计算」的演变历史的一个缩影。我简单整理了一张表格方便大家理解阶段软件架构主要 DevOps 工具观测需求主要观测技术核心痛点第一阶段2000-2010单体应用传统虚拟机JenkinsCI、Ansible配置管理、Chef/Puppet自动化运维单点监控监控应用的 CPU/内存/磁盘、监控 Jenkins 的构建状态、监控 Ansible 的执行结果Nagios、Zabbix、Ganglia工具之间的数据完全割裂没有统一的观测平台排查问题需要逐个看日志、逐个查监控面板第二阶段2010-2018微服务容器DockerJenkins XCI/CD、Kubernetes容器编排、ELK Stack日志链路追踪日志聚合指标监控开始关注微服务之间的调用链路、开始聚合所有服务的日志、开始用 Prometheus 监控容器和微服务Prometheus、Grafana、Jaeger/Zipkin、ELK Stack观测数据分为「指标Metrics、日志Logs、链路追踪Traces」三大类但这三类数据之间依然是割裂的CI/CD 工具的观测数据比如 Jenkins 的构建时长、成功率要么没有导出到 Prometheus要么导出的方式非常复杂、指标没有统一的标签规范没有专门的工具来管理 SLO、错误预算、部署验证第三阶段2018-至今云原生微服务Serverless边缘计算GitOpsHarness NextGen全生命周期 DevOps、Argo CDGitOps、Crossplane基础设施即代码、OpenTelemetry统一观测标准全链路可观测性统一可视化统一告警自动化 RCASLO 管理部署验证自动化运维要求所有的观测数据CI/CD、Chaos、Feature Flags、应用、基础设施、K8s、边缘都能在同一个平台上统一管理、统一可视化、统一告警要求观测数据能够自动触发运维操作比如回滚、扩容、Chaos 实验要求能够用 SLO 和错误预算来驱动开发和运维决策Harness NextGen Observability、Grafana Cloud、Datadog、New Relic、OpenTelemetry Collector虽然 OpenTelemetry 提供了统一的观测标准但大多数企业级 DevOps 平台比如早期的 Harness、早期的 GitLab CI/CD要么没有完全支持 OpenTelemetry要么支持的程度不够CI/CD 工具的观测数据比如部署验证的结果、SLO 的错误预算消耗和应用/基础设施的观测数据之间的关联依然不够紧密很多企业同时在用多个 DevOps 工具比如 Argo CD 做 GitOps、Harness 做 Chaos/SRM、Jenkins 做 legacy 应用的 CI需要一个统一的观测平台来聚合所有工具的数据1.2.2 企业级观测的实际需求为什么直接用 Prometheus 不够看到这里可能有些读者会说「既然 OpenTelemetry 已经是统一的观测标准了为什么 Harness 还要自己做 MAE直接让 Harness 内部的所有组件都导出 OpenTelemetry Metrics然后用 OpenTelemetry Collector 聚合、过滤、转换再导出到 Prometheus 不就行了」没错从理论上讲这种方案是可行的——事实上Harness NextGen 内部的很多组件比如 CI 构建执行器、CD 部署代理、SRM 探测代理已经在支持 OpenTelemetry Metrics/Logs/Traces 的导出了。但是对于企业级观测来说直接用 OpenTelemetry Collector Prometheus 还是存在几个无法忽视的痛点痛点一Prometheus 不适合做「复杂的多源预聚合」Prometheus 的核心设计理念是「Pull 模式Pull-based的时序数据库Time Series Database, TSDB」它的主要优势是轻量级、部署简单支持强大的 PromQL 查询语言支持静态和动态的服务发现Service Discovery社区生态非常丰富。但是Prometheus 的核心设计理念也决定了它的局限性——它不适合做「复杂的多源预聚合」Pull 模式的限制Prometheus 是通过 Pull 的方式从 Exporter 那里拉取指标的如果 Exporter 有 1000 个、每个 Exporter 有 10000 个指标那么 Prometheus 的 Pull 压力会非常大很容易出现「指标丢失」的情况预聚合能力的限制虽然 Prometheus 2.0 支持了「Recording Rules记录规则」可以做一些简单的预聚合比如计算 5 分钟的平均部署成功率但是 Recording Rules 只能处理 Prometheus 内部已经存储的指标不能处理「外部数据源比如 AWS CloudWatch、GCP Monitoring、Harness 内部的 REST API 指标」的指标也不能做「复杂的标签增强、阈值过滤、跨源数据关联」存储成本的限制Prometheus 本地存储的默认保留时间是 15 天如果你想保留更长时间的原始数据要么需要把数据导出到远程存储比如 Thanos、Cortex、VictoriaMetrics要么需要增加本地存储的容量——不管是哪种方案存储成本都会非常高因为 Prometheus 存储的是「所有的原始指标数据」而企业级观测其实只需要「部分原始数据大部分预聚合数据」。而 Harness 的内置 MAE恰恰就是为了解决这些痛点而设计的——它是一个「Push 模式Push-based为主、Pull 模式为辅的分布式多源度量聚合引擎」Push 模式为主、Pull 模式为辅Harness 内部的所有组件CI、CD、SRM、Chaos、Feature Flags都是通过 Push 的方式把原始指标发送到 MAE 的MAE 也可以通过 Pull 的方式从外部数据源比如 AWS CloudWatch、GCP Monitoring、自定义的 REST API拉取指标——这样就大大降低了观测系统的压力强大的预聚合能力MAE 支持「实时预聚合、批量预聚合、自定义预聚合规则」可以处理「跨源数据关联、复杂的标签增强、阈值过滤、数据标准化、SLO 计算、错误预算追踪」灵活的存储策略MAE 可以把「原始指标数据」和「预聚合指标数据」分开存储——NextGen SaaS 平台默认把「原始指标数据」保留 90 天、把「预聚合指标数据」保留 365 天Self-Hosted 平台可以根据自己的需求无限期保留完全兼容 OpenTelemetryMAE 支持接收和导出 OpenTelemetry Metrics/Logs/Traces你可以把 MAE 作为 OpenTelemetry Collector 的「下游聚合组件」也可以把 OpenTelemetry Collector 作为 MAE 的「上游数据采集组件」。痛点二CI/CD 工具的观测指标需要「统一的标签规范」和「与应用/基础设施指标的紧密关联」如果你曾经用过 Prometheus 监控过多个 CI/CD 工具比如 Jenkins、GitLab CI/CD、Harness NextGen CD你肯定会遇到一个非常头疼的问题不同 CI/CD 工具导出的指标的标签规范完全不一样——比如Jenkins 导出的构建指标的标签是jenkins_job_name、jenkins_build_number、jenkins_build_resultGitLab CI/CD 导出的构建指标的标签是gitlab_ci_job_name、gitlab_ci_job_id、gitlab_ci_pipeline_id、gitlab_ci_job_status早期的 Harness NextGen CD 导出的部署指标的标签是harness_application_name、harness_environment_name、harness_deployment_id、harness_deployment_status。标签规范不统一会导致什么问题无法在同一张 Grafana 仪表盘上做统一可视化比如你想做一张「团队所有应用的部署成功率趋势图」你需要写 3 个不同的 PromQL 查询每个查询对应一个 CI/CD 工具然后还要把这 3 个查询的结果合并起来——这不仅非常麻烦而且还很容易出错无法做统一告警比如你想设置一个「如果团队所有应用的 1 小时平均部署成功率低于 95%就触发 P2 告警」的规则你需要为每个 CI/CD 工具单独设置一个告警规则然后还要把这些告警规则的结果合并起来——这不仅增加了告警管理的复杂度而且还很容易出现「告警风暴」或「告警遗漏」的情况无法与应用/基础设施指标做紧密关联比如你想知道「为什么生产环境的 frontend 微服务的部署成功率骤降 70%」你需要先在 Harness CD 里找到对应的部署记录然后再去 Grafana 里找同一时间段的 frontend 微服务的 CPU/内存/磁盘指标、找同一时间段的 K8s Pod 的指标——这不仅非常耗时而且还很容易漏掉关键的线索。而 Harness 的内置 MAE 和 HPE恰恰就是为了解决这些痛点而设计的统一的标签规范Harness Observability Label Standard, HOLSHarness 为所有的观测指标CI、CD、SRM、Chaos、Feature Flags、外部数据源都制定了统一的标签规范HOLS——比如所有的应用相关的指标都有harness_org_id、harness_project_id、harness_service_id、harness_environment_id、harness_environment_type这些核心标签所有的部署相关的指标都有harness_pipeline_id、harness_pipeline_execution_id、harness_stage_id、harness_step_id、harness_deployment_type这些核心标签——这样你就可以在同一张 Grafana 仪表盘上做统一可视化、做统一告警与应用/基础设施指标的紧密关联Harness 支持把Prometheus 里的应用/基础设施/K8s 指标作为外部数据源导入 MAE然后在 MAE 里把这些外部指标和 Harness 内部的 CI/CD/SRM/Chaos/Feature Flags 指标做跨源数据关联——比如你可以在 MAE 里创建一个预聚合规则把「生产环境的 frontend 微服务的部署成功率」和「同一时间段的 frontend 微服务的 95th 延迟」关联起来然后用 HPE 把这个关联后的指标导出到 Prometheus最后在 Grafana 里做一张「部署成功率 vs 95th 延迟」的趋势图——这样你就可以在几秒钟内找到「为什么部署成功率骤降」的原因自动化的 RCA 线索生成Harness 的 SRM 组件可以利用 MAE 里的跨源数据关联自动生成 RCA 线索——比如当生产环境的 frontend 微服务的 SLO 错误预算消耗超过 20% 时SRM 会自动检查同一时间段的部署记录、Chaos 实验记录、Feature Flags 变更记录、应用/基础设施/K8s 指标然后生成一份「RCA 线索报告」告诉你最有可能导致 SLO 违规的原因是什么。痛点三企业需要「开箱即用的观测集成」和「统一的观测管理界面」如果你曾经自己搭建过一套「Prometheus Grafana OpenTelemetry Collector 多个 CI/CD 工具的 Exporter」的观测系统你肯定会遇到一个非常耗时的问题观测集成的配置非常复杂——比如你需要为每个 CI/CD 工具单独安装和配置 Exporter你需要为每个 Exporter 单独配置 Prometheus 的 Service Discovery你需要为每个 Exporter 单独配置 Prometheus 的 Scraping Interval、Scraping Timeout、Relabeling Rules你需要为每个 CI/CD 工具单独配置 Grafana 的仪表盘和告警规则你需要为每个 CI/CD 工具单独管理观测数据的保留时间、存储成本、访问权限。而 Harness 的内置 MAE 和 HPE恰恰就是为了解决这些痛点而设计的开箱即用的观测集成Harness NextGen 内部的所有组件CI、CD、SRM、Chaos、Feature Flags都是开箱即用支持观测的——你不需要单独安装和配置任何 Exporter只需要在 Harness 平台上启用「Observability」功能所有的原始指标就会自动发送到 MAE开箱即用的 HPE 配置HPE 是 Harness NextGen 平台的一个内置组件Self-Hosted 平台需要单独部署但配置非常简单——你只需要在 Harness 平台上创建一个「Prometheus Exporter Integration」配置好 Prometheus 的 Remote Write 端点如果需要的话、配置好要导出的指标可以选择导出所有的指标、也可以选择导出部分指标、还可以选择导出 MAE 聚合后的指标HPE 就会自动把指标导出到 Prometheus开箱即用的 Grafana 仪表盘和告警规则Harness 官方提供了一套完整的 Grafana 仪表盘和告警规则模板——你只需要把这些模板导入到你的 Grafana 平台就可以立即看到 Harness 内部的 CI/CD/SRM/Chaos/Feature Flags 指标的统一可视化统一的观测管理界面Harness NextGen 平台提供了一个统一的观测管理界面Observability Module——你可以在这个界面上管理所有的观测数据原始数据、预聚合数据、管理所有的预聚合规则、管理所有的外部数据源、管理所有的 HPE 集成、查看所有的 SLO 和错误预算、查看所有的 RCA 线索报告——你不需要再在 5-6 个不同的观测系统/面板之间跳来跳去了。1.3 亮明观点/文章目标读完这篇文章你能学到什么好了说了这么多背景和痛点现在该亮明我的观点和这篇文章的目标了1.3.1 我的核心观点Harness NextGen 中的内置度量聚合引擎MAE和 Prometheus ExporterHPE是目前企业级 DevOps 全生命周期观测领域的最佳实践之一——它不仅彻底解决了「观测数据割裂」的问题还提供了「强大的预聚合能力」、「统一的标签规范」、「与应用/基础设施指标的紧密关联」、「开箱即用的观测集成」和「统一的观测管理界面」可以帮助企业大大提升 DevOps/SRE 的工作效率、降低观测系统的运维成本、提高软件交付的质量和可靠性。1.3.2 这篇文章的目标读完这篇文章你将能够理解 Harness NextGen 中的内置度量聚合引擎MAE的所有核心概念、底层架构、工作原理——比如什么是「Metric Entity度量实体」、什么是「Dimension维度」、什么是「Metric Value度量值」、什么是「Aggregation Rule聚合规则」、什么是「Downsampling Rule降采样规则」、MAE 是如何处理多源数据的、MAE 是如何做预聚合的理解 Harness Prometheus ExporterHPE的所有核心概念、底层架构、工作原理——比如 HPE 支持哪些导出模式、HPE 是如何处理指标格式转换的、HPE 是如何处理 Prometheus 的 Label 规范的、HPE 是如何处理指标的 Push/Pull 模式的掌握 Harness NextGen 中的内置度量聚合引擎MAE的完整实战操作——比如如何在 Harness 平台上启用「Observability」功能、如何查看 MAE 里的原始指标和预聚合指标、如何创建自定义的聚合规则、如何创建自定义的降采样规则、如何把 Prometheus 里的指标作为外部数据源导入 MAE掌握 Harness Prometheus ExporterHPE的完整实战操作——比如如何在 Harness 平台上创建「Prometheus Exporter Integration」、如何配置 HPE 的导出模式、如何配置 HPE 要导出的指标、如何配置 HPE 的 Prometheus Remote Write 端点、如何把 HPE 导出的指标导入到 Prometheus、如何把 Harness 官方提供的 Grafana 仪表盘和告警规则模板导入到 Grafana掌握 Harness NextGen 中的内置度量聚合与 Prometheus 导出的最佳实践——比如如何选择要导出的指标、如何配置合理的 Scraping Interval/降采样间隔、如何避免「指标爆炸Cardinality Explosion」、如何管理观测数据的存储成本、如何做统一的告警、如何做自动化的 RCA了解 Harness NextGen 中的观测系统的未来发展趋势——比如 Harness 对 OpenTelemetry 的进一步支持、Harness 对「MetricsLogsTraces」三者统一的进一步支持、Harness 对「AIOpsArtificial Intelligence for IT Operations」的进一步支持。为了让这篇文章更有实用性我会在文章的第三部分核心内容/实战演练中用一个完整的实战案例来贯穿所有的操作步骤——这个实战案例的背景是你是一家电商公司的 DevOps/SRE 负责人你的公司正在用 Harness NextGen 作为全生命周期 DevOps 平台你的公司有一个名为「ecommerce」的 Harness 组织Organization、一个名为「online-store」的 Harness 项目Project你的公司有两个微服务frontend前端微服务用 React 开发、backend后端微服务用 Spring Boot 开发你的公司有三个环境dev开发环境、staging预发布环境、prod生产环境你的公司已经在用 Prometheus Grafana 监控应用/基础设施/K8s 的指标你的公司现在的需求是把 Harness 内部的 CI/CD/SRM/Chaos/Feature Flags 指标导出到 Prometheus然后在 Grafana 里和应用/基础设施/K8s 的指标做统一可视化、统一告警同时把 Prometheus 里的应用/基础设施/K8s 指标作为外部数据源导入 MAE用来触发部署验证、SLO 告警、回滚策略。好了废话不多说让我们开始进入正题吧二、基础知识/背景铺垫在深入讲解 Harness NextGen 中的内置度量聚合引擎MAE和 Prometheus ExporterHPE的核心内容和实战演练之前我们得先掌握一些必要的基础知识和背景铺垫——这些知识包括Harness NextGen 的平台架构概述Harness NextGen Observability Module 的概述Prometheus 的核心概念和工作原理快速回顾OpenTelemetry Metrics 的核心概念快速回顾。如果你已经是 Harness NextGen 的老用户或者已经非常熟悉 Prometheus 和 OpenTelemetry Metrics 的核心概念可以跳过这一部分的部分内容但我还是建议你至少快速浏览一下「Harness NextGen Observability Module 的概述」这一小节——因为这一小节会介绍 Harness NextGen Observability Module 的整体架构以及 MAE 和 HPE 在这个架构中的位置。2.1 Harness NextGen 的平台架构概述Harness NextGen 是 Harness 公司在 2021 年推出的新一代企业级 DevOps 全生命周期平台——它彻底重构了 Harness FirstGen2016 年推出的第一代平台的底层架构采用了「云原生、微服务、GitOps、API 优先」的设计理念提供了CIContinuous Integration、CDContinuous Delivery/Continuous Deployment、SRMService Reliability Management、CECloud Cost Management、ChaosChaos Engineering、FFFeature Flags、STOSecurity Testing Orchestration等覆盖软件交付全生命周期的模块。2.1.1 Harness NextGen 的核心组件Harness NextGen 的核心组件可以分为「控制平面Control Plane」和「数据平面Data Plane」两大部分2.1.1.1 控制平面Control Plane控制平面是 Harness NextGen 平台的「大脑」——它负责管理所有的配置比如 Pipeline 配置、Environment 配置、Service 配置、Secret 配置、负责调度所有的任务比如 CI 构建任务、CD 部署任务、SRM 探测任务、Chaos 实验任务、负责存储所有的观测数据比如原始指标、预聚合指标、日志、链路追踪、负责提供所有的 UI/API 接口。Harness NextGen 的控制平面可以分为「SaaS 控制平面」和「Self-Hosted 控制平面」两种部署模式SaaS 控制平面由 Harness 公司负责部署、运维、升级——你只需要注册一个 Harness 账号就可以立即使用所有的功能Self-Hosted 控制平面由你自己负责部署、运维、升级——你可以把控制平面部署在自己的 AWS/GCP/Azure 账户上也可以部署在自己的私有数据中心里。不管是 SaaS 控制平面还是 Self-Hosted 控制平面它们的核心架构都是一样的——主要由以下几个微服务组成NG ManagerNextGen Manager控制平面的核心微服务——负责管理所有的配置、负责调度所有的任务、负责提供 UI/API 接口NG UINextGen UI控制平面的前端微服务——负责提供 Harness NextGen 的 Web 界面Pipeline Service负责管理所有的 Pipeline 配置、负责执行 Pipeline 的调度逻辑Environment Service负责管理所有的 Environment 配置、负责管理 Environment 的访问权限Service Service负责管理所有的 Service 配置、负责管理 Service 的版本Secret Manager负责管理所有的 Secret 配置比如 API 密钥、密码、证书、负责加密/解密 SecretObservability Service控制平面的观测微服务——负责管理所有的观测数据的存储、查询、预聚合Metric Aggregation EngineMAEObservability Service 的核心子组件——负责多源数据的采集、预聚合、降采样、标签增强、数据标准化Log ServiceObservability Service 的子组件——负责日志的采集、存储、查询、聚合Trace ServiceObservability Service 的子组件——负责链路追踪的采集、存储、查询、聚合Harness Prometheus ExporterHPEObservability Service 的子组件——负责把 MAE 里的指标导出到 Prometheus或任何兼容 Prometheus Remote Write 协议的系统Database Cluster控制平面的数据库集群——主要用 PostgreSQL 存储所有的配置数据、用 Cassandra 存储所有的观测数据原始指标、预聚合指标、日志、链路追踪Message Queue Cluster控制平面的消息队列集群——主要用 Kafka 来处理任务调度、数据采集、事件通知Artifact Repository控制平面的制品仓库——负责存储所有的 CI 构建制品比如 Docker 镜像、JAR 包、WAR 包。2.1.1.2 数据平面Data Plane数据平面是 Harness NextGen 平台的「手脚」——它负责执行控制平面调度的所有任务比如 CI 构建任务、CD 部署任务、SRM 探测任务、Chaos 实验任务、负责采集所有的观测数据比如原始指标、日志、链路追踪、负责把采集到的观测数据发送到控制平面的 Observability Service。Harness NextGen 的数据平面主要由以下几个组件组成Harness DelegateHarness 代理数据平面的核心组件——负责执行控制平面调度的所有任务、负责采集所有的观测数据、负责把采集到的观测数据发送到控制平面的 Observability ServiceCI Build AgentCI 构建代理Harness Delegate 的子组件——负责执行 CI 构建任务CD Deploy AgentCD 部署代理Harness Delegate 的子组件——负责执行 CD 部署任务SRM Probe AgentSRM 探测代理Harness Delegate 的子组件——负责执行 SRM 探测任务比如 HTTP 探测、TCP 探测、Database 探测Chaos Experiment AgentChaos 实验代理Harness Delegate 的子组件——负责执行 Chaos 实验任务比如 Pod Kill 实验、CPU Stress 实验、Memory Stress 实验OpenTelemetry Collector可选Harness Delegate 的可选子组件——负责采集应用/基础设施/K8s 的 OpenTelemetry Metrics/Logs/Traces然后发送到控制平面的 Observability Service。2.1.2 Harness NextGen 的核心概念在使用 Harness NextGen 之前我们得先掌握一些核心概念——这些概念不仅是使用 Harness NextGen 的基础也是理解 MAE 和 HPE 的基础核心概念英文名称定义示例组织OrganizationHarness NextGen 平台的最高层级——一个组织可以包含多个项目、多个用户组、多个访问权限策略ecommerce电商公司的组织项目ProjectHarness NextGen 平台的第二层级——一个项目可以包含多个服务、多个环境、多个 Pipeline、多个 Secretonline-store在线商城的项目服务Service代表你要部署的应用或微服务——一个服务可以包含多个制品、多个配置文件、多个部署类型frontend前端微服务、backend后端微服务环境Environment代表你要部署服务的目标环境——一个环境可以包含多个基础设施、多个访问权限策略dev开发环境、staging预发布环境、prod生产环境基础设施Infrastructure代表你要部署服务的具体基础设施——可以是 Kubernetes 集群、AWS ECS、AWS EC2、Azure VM、私有数据中心的服务器prod-k8s-cluster生产环境的 Kubernetes 集群PipelinePipeline代表软件交付的全流程——一个 Pipeline 可以包含多个 Stage、多个 Step、多个触发器frontend-cd-pipeline前端微服务的 CD PipelineStageStagePipeline 的组成部分——代表软件交付的一个阶段比如 Build 阶段、Test 阶段、Deploy 阶段、Verify 阶段deploy-prod-stage部署到生产环境的 StageStepStepStage 的组成部分——代表软件交付的一个具体操作比如 Docker Build 操作、Docker Push 操作、K8s Apply 操作、Deployment Verify 操作k8s-apply-step应用 K8s YAML 文件的 Step触发器Trigger代表触发 Pipeline 执行的条件——可以是 Git 推送事件、定时事件、手动触发事件、其他 Pipeline 执行完成事件frontend-git-push-trigger当 frontend 微服务的 Git 仓库有推送事件时触发 Pipeline密钥Secret代表你要存储的敏感信息——可以是 API 密钥、密码、证书、SSH 私钥prod-db-password生产环境数据库的密码、docker-hub-credentialsDocker Hub 的凭证2.2 Harness NextGen Observability Module 的概述Harness NextGen Observability Module观测模块是 Harness NextGen 平台的核心模块之一——它提供了「Metrics指标、Logs日志、Traces链路追踪」三大类观测数据的采集、存储、查询、预聚合、可视化、告警、RCA 等功能是 Harness NextGen 平台实现「全链路可观测性」的基础。2.2.1 Harness NextGen Observability Module 的整体架构Harness NextGen Observability Module 的整体架构可以分为「数据采集层Data Collection Layer」、「数据处理层Data Processing Layer」、「数据存储层Data Storage Layer」、「数据应用层Data Application Layer」四大部分——MAE 和 HPE 分别位于「数据处理层」和「数据应用层」我用 Mermaid 架构图来展示一下 Harness NextGen Observability Module 的整体架构渲染错误:Mermaid 渲染失败: Parse error on line 75: ...s Data Plane,Control Plane plane; cl -----------------------^ Expecting SEMI, NEWLINE, EOF, AMP, COLON, DOWN, DEFAULT, NUM, COMMA, NODE_STRING, BRKT, MINUS, MULT, UNICODE_TEXT, got SPACE2.2.2 Harness NextGen Observability Module 的核心功能Harness NextGen Observability Module 的核心功能可以分为「Metrics 相关功能」、「Logs 相关功能」、「Traces 相关功能」、「SLO 管理功能」、「RCA 功能」、「部署验证功能」六大部分——由于这篇文章的主题是「Harness 中的内置度量聚合与 Prometheus 导出」所以我们主要关注「Metrics 相关功能」2.2.2.1 Metrics 相关功能Metrics 相关功能是 Harness NextGen Observability Module 的核心功能之一——主要由 Metric Aggregation EngineMAE提供包括多源数据采集支持从 Harness 内部的所有组件CI、CD、SRM、Chaos、Feature Flags采集原始指标支持从外部数据源比如 Prometheus、AWS CloudWatch、GCP Monitoring、Datadog、自定义的 REST API采集原始指标数据标准化把所有采集到的原始指标转换为Harness Observability Metric FormatHOMF——这是 Harness 定义的一种统一的指标格式完全兼容 OpenTelemetry Metrics标签增强为所有采集到的原始指标自动添加Harness Observability Label StandardHOLS中定义的核心标签比如harness_org_id、harness_project_id、harness_service_id、harness_environment_id实时预聚合支持对采集到的原始指标进行实时预聚合——预聚合的时间窗口可以是 1 分钟、5 分钟、15 分钟、1 小时预聚合的函数可以是 Count计数、Sum求和、Min最小值、Max最大值、Avg平均值、Percentile百分位数比如 P50、P95、P99自定义预聚合规则支持创建自定义的预聚合规则——可以选择要聚合的指标、选择聚合的时间窗口、选择聚合的函数、选择要过滤的标签、选择要增强的标签、选择要关联的外部指标降采样支持对预聚合后的指标进行降采样——降采样的时间窗口可以是 1 小时、6 小时、1 天、7 天、30 天降采样的函数可以是 Count计数、Sum求和、Min最小值、Max最大值、Avg平均值、Percentile百分位数指标查询支持用Harness Query LanguageHQL查询原始指标和预聚合指标——HQL 是 Harness 定义的一种类似 PromQL 的查询语言完全兼容 PromQL指标可视化支持在 Harness NextGen UI 里创建自定义的指标仪表盘——可以选择要可视化的指标、选择可视化的类型比如折线图、柱状图、饼图、热力图、单值图、选择可视化的时间范围、选择要过滤的标签指标告警支持在 Harness NextGen UI 里创建自定义的指标告警规则——可以选择要告警的指标、选择告警的条件比如指标值大于/小于/等于某个阈值、指标值的变化率大于/小于某个阈值、选择告警的时间窗口、选择告警的级别比如 P0、P1、P2、P3、选择告警的通知方式比如 Email、Slack、PagerDuty、Webhook。2.2.2.2 其他相关功能简要介绍由于这