You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
C++ 在语言上比 Go 拥有更加精细的内存管理能力。C++ 是无 GC 语言,完全没有垃圾回收带来的负担。阿里云 Prometheus 4.x 在线上就曾遇到过因为内存泄漏导致 Go 垃圾回收占用了近一半 CPU 时间,导致采集缓慢的问题。依托于 C++ 精细的资源管理能力,有望使用更低的资源开销承载现有的 Prometheus 能力,进而实现成本的降低。在同等条件下,Prom in LoongCollector 的资源开销已经比阿里云 Prometheus 4.x 低 40%,我们期望未来资源开销能够比 VMAgent 低 30%。
C++ 重写 Prometheus 面临的挑战
Prometheus 的多目标定时采集可以使用 Go 语言的协程能力,以极轻的代码就能实现,而 C++17 并没有协程的概念,也没有原生的定时触发器,如何基于 C++17 实现高并发的多目标定时采集是面临的挑战。为此我们基于有锁队列和 libCurl 的 Multi 接口实现了高效的异步采集。
Background
开源社区已经存在的支持 Prometheus 采集能力的 Agent 有 Prometheus、VMAgent、Vector 等。Prometheus 与 VMAgent 都是通过 Go 语言实现,VMAgent 虽然有着优秀的性能,但缺少 Pipeline 机制,无法方便的扩展处理能力。Vector 通过 Rust 语言实现,虽然有不错的扩展性,但是服务发现能力弱,运维负担较重。
在阿里云的 Prometheus 服务上使用的是自研采集探针,同样是通过 Go 语言实现的。随着公有云服务的发展,该探针也面临着性能挑战,我们希望以更低的成本和更高的可扩展性实现高性能的 Prometheus 采集器。所以本提案将通过 C++ 重新构造 Prometheus 能力,与 LoongCollector 项目彻底融合,以期达到比 VMAgent 更低资源开销的目标。
C++ 能够为 Prometheus 带来什么优势
C++ 在语言上比 Go 拥有更加精细的内存管理能力。C++ 是无 GC 语言,完全没有垃圾回收带来的负担。阿里云 Prometheus 4.x 在线上就曾遇到过因为内存泄漏导致 Go 垃圾回收占用了近一半 CPU 时间,导致采集缓慢的问题。依托于 C++ 精细的资源管理能力,有望使用更低的资源开销承载现有的 Prometheus 能力,进而实现成本的降低。在同等条件下,Prom in LoongCollector 的资源开销已经比阿里云 Prometheus 4.x 低 40%,我们期望未来资源开销能够比 VMAgent 低 30%。
C++ 重写 Prometheus 面临的挑战
Prometheus 的多目标定时采集可以使用 Go 语言的协程能力,以极轻的代码就能实现,而 C++17 并没有协程的概念,也没有原生的定时触发器,如何基于 C++17 实现高并发的多目标定时采集是面临的挑战。为此我们基于有锁队列和 libCurl 的 Multi 接口实现了高效的异步采集。
Goals
LoongCollector 社区版本提供的 Prometheus 采集能力有三个关注目标:
兼容性:在采集功能项上,我们需要做到高频使用的功能 100% 覆盖,如:scrape_interval、scrape_timeout、params、relabel_configs、metric_relabel_configs 等。对于 body_size_limit、sample_limit、label_limit 等参数,由于使用频率不是特别高,不作为一期实现的目标;
性能:通过 C++ 实现的 LoongCollector Prometheus 采集能力,以目前业界领先的 VMAgent 为标杆,在相同采集目标数与指标量的规模场景下,需要达到降低 30% CPU / 内存资源占用率的目标;
可观测:在开源 Prometheus 提供的 up、scrape_samples_scraped 等自监控指标基础上,需要再扩充一批体现 Pipeline 级别的自监控指标,以便实现数据问题定界,反映采集与上报的完整度;
Non-Goals
以下关注点不在 LoongCollector 社区版本提供的 Prometheus 采集能力目标上:
Architecture
为了达成上述目标,LoongCollector 的架构被精心设计以确保高效、稳定且可扩展。该架构主要由 OneOperator 和 OneAgent 两部分组成。
OneOperator:负责 OneAgent 管理和横向扩容、服务发现、采集任务调度、配置管理。服务发现支持多种主流的服务发现协议,包括但不限于Kubernetes、Service Monitor、Pod Monitor、静态配置及HTTP SD等。采集任务任务调度策略涵盖了预抓取技术以优化数据获取效率、无损升级,还实现了智能负载均衡算法,从而保证了整个系统的高效运转与资源利用最大化。
OneAgent:作为数据采集的核心组件,OneAgent 承担了从目标服务中高效抓取指标的任务。它利用 C++17 的高级特性,结合阿里云在系统性能优化方面的深厚积累,实现了低延迟、高吞吐量的数据采集过程。通过集成 libCurl Multi 接口与自定义的有锁队列机制,OneAgent 能够有效地管理并发请求,并确保即使面对大规模监控场景时也能保持稳定运行。通过数据流水线对指标进行 TextParser、Relabel 处理工作之后,通过 SLSFlusher 发送到阿里云指标存储,也可以通过 Go RemoteWrite 写入指定地址。
Prom in LoongCollector 兼容性
在指标采集上,OneAgent 已经支持 job_name、scrape_interval、scrape_timeout、scrape_protocols、metrics_path、honor_labels、honor_timestamps、scheme、params、basicauth、authorization、follow_redirects、tls_config、relabel_configs、metric_relabel_configs等采集配置如下示例所示。
在指标处理上,OneAgent 已经支持 PrometheusText 和部分 OpenMetricsText 标准。支持 Metric Relabel 操作。支持除了 scrape_series_added 外的开源自监控指标。
在指标发送时,OneAgent 具备通过阿里云 SLSFlusher 写入阿里云指标存储和 Go RemoteWrite 插件写入指定存储的能力。
Prom in LoongCollector 核心组件
核心组件有采集调度器、指标解析、指标处理。
采集调度器(ScrapeSchedular)实现了指标的周期采集调度、采集时间规整化,在未来还会实现流式采集、采集熔断、内存控制等功能。
指标解析器(TextParser)实现了兼容 Prometheus 规范的指标解析功能,还支持对 OpenMetrics 定义的时间戳进行自动判断和解析。
指标处理(MetricRelabel)基于 PipelineEventGroup 实现了对 Map 结构的 Labels 的处理,这区别于 Prometheus 与 VMAgent 基于 List 的实现。
Challenges
Prom in LoongCollector 在实现过程中主要难点有:异步采集、流式采集与处理、内存控制。
异步采集:
Prom in LoongCollector 单个副本要能够支持千级别的 Targets 和百万级别的指标时间线采集。所以需要并发的进行网络请求,并且能够无阻塞的对周期定时事件进行触发执行。为此我们实现了并发网络请求、定时触发器和采集调度器三个组件。
异步并发网络请求:采用了 libCurl 的 Multi 接口,采用 epoll 等高效的 I/O 多路复用技术,配合事件循环机制,在处理大量并发连接时依然能够维持较低的资源消耗。
定时触发器:定时触发器在有锁队列中存储待处理的抓取任务。每个任务包含抓取触发时间点、抓取目标、参数配置以及其他必要的元数据。
采集调度器:采集调度器通过集成上述组件,实现了对 Prometheus 定时指标数据的高效采集。该过程首先利用 Hash 算法,将大量的待执行采集任务均匀分布在整个采集周期内,从而优化了任务调度的均衡性和效率。
流式处理
在 Exporter 暴露的指标数据过大时,会出现内存和 CPU 资源的冲高,带来不稳定因素,可能会导致采集探针 OOM。因为Prometheus 各目标的采集窗口在时间上是分散的,每个目标的处理窗口只要小于“采集间隔 - 采集耗时”即可,可以通过控制数据处理切片刻意“放慢”脚步,充分利用这个窗口中的 CPU、内存、带宽资源,避免集中处理一整批数据、资源使用率冲高。
流式处理包含了指标流式采集和指标处理两部分。借助于 LoongCollector Pipeline 的优势可以实现指标的分片采集和异步化的指标处理。流式处理会将指标数据切片,每收到一批数据就会处理一批数据,既能保持内存占用的平稳,还能够提升内存复用。流式处理会在下一个阶段实现。
内存控制
内存控制会基于 OneAgent 的实时运行情况,根据内存水位、Pipeline 运行状态主动调整指标采集,发出自监控指标,触发扩容机制等,会在下一个阶段实现。
RoadMap
1130
在采集配置上支持:
job_name
、scrape_interval
、scrape_timeout
、scrape_protocols
、metrics_path
、honor_labels
、honor_timestamps
、scheme
、params
、basicauth
、authorization
、follow_redirects
、tls_config
、relabel_configs
、metric_relabel_configs
在自监控指标上支持:
scrape_duration_seconds
、scrape_response_size_bytes
、scrape_samples_limit
、scrape_samples_post_metric_relabeling
、scrape_samples_scraped
、scrape_timeout_seconds
、up
1230
在采集配置上支持:
tls
、follow_redirects
、external_labels
、proxy_xxx
在自监控指标上支持:
scrape_state
0130
支持流式采集和流式处理
0230
支持内存控制
The text was updated successfully, but these errors were encountered: