本次更新，APO 带来了一些新功能，并对若干问题进行了修复。

支持通过钉钉和微信发送告警通知​

APO 现已支持通过钉钉和微信发送告警通知。当系统检测到异常情况时，可以立即通过这两种广泛使用的通讯平台向相关人员或团队发送告警信息，确保问题能够得到及时响应和处理。

集成主机监控指标大盘​

在旧版本中，APO 展示了主机的基础监控指标，如 CPU 使用率、内存占用、网络流量等。但APO 采集到的主机指标远不止于此，为了协助用户迅速发现并定位潜在的问题，优化资源分配，提升效率，在新版本中，APO 集成了详细的主机监控指标大盘，为用户提供了一个直观的界面来查看主机的性能指标。

预告 1.0 版本​

APO 正在向发布 1.0 版本冲刺，1.0 版本将带来账号登录和管理功能，修复已知的若干问题，进一步提高稳定性。从 1.0 版本开始，APO 将尽可能保证向前兼容，减少破坏性改动，以便于用户能够更加顺畅地升级至最新版本。

在 APO 的迭代发展过程中，衷心感谢每一位社区用户的反馈和支持，正是你们的帮助让 APO 不断进步和完善。让我们一起期待 1.0 版本，一起见证 APO 的成长与进步！

更多变化请查看下述更新列表。​

新增功能​

• 支持发送告警到钉钉和企业微信
• 新增宿主机监控大盘

功能优化​

• 配置告警规则时新增更多预置指标

缺陷修复​

• 修复服务概览中日志错误数曲线可能不准确的问题
• 修复影响面分析中可能出现非服务入口的问题
• 修复多实例情况下日志错误数指标错误的问题
• 修复部分场景下服务关联到错误的实例的问题
• 修复网络延时指标中持续出现值为1的数据问题
• 修复虚拟机场景下网络延时指标重复的问题

其他​

• 优化 OneAgent CPU和内存开销
• 升级 OneAgent 集成的 opentelemetry-java-instrumentation 版本到 2.8.0
• 安装时支持配置服务端持久卷大小

APO介绍：

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO v0.9.0 更新发布！本次更新主要包含以下内容：

告警分析功能免费公测​

告警分析功能是 APO 的企业版功能，现向所有用户免费公测。

该功能通过自动分类告警和关联分析数据，将告警与应用和业务入口精准关联。通过深入分析业务入口的告警，用户可以检查告警事件与服务之间的关系。“告警回溯”利用拓扑结构对告警事件进行逻辑回放，帮助用户定位故障节点。最终通过检查故障节点的延时报告和错误报告了解节点当前存在的问题和原因。这些功能为用户提供了全面的告警和故障分析能力，减少了故障排查的时间和成本。

欢迎大家体验，后续我们还将针对该功能带来更为详细的解读，敬请期待。

全量日志页面性能优化​

本次更新优化了全量日志页面的用户体验。针对结构化JSON日志，页面会自动展开第一层信息；针对超长日志会自动收起过长部分；通过优化性能大大提升了页面响应的流畅度。

本次更新还修复了多个问题，具体变化请查看下述更新列表。

新增功能​

• 告警分析功能免费公测（企业版功能）

功能优化​

• 优化全量日志在加载长日志时卡顿的问题

缺陷修复​

• 修复全量日志无法筛选Bool类型值的问题
• 修复 backend 使用 MySQL 数据库作为存储时报错的问题
• 修复添加告警通知后可能无法收到告警事件的问题
• 修复无法修改数据保留周期配置的问题

APO介绍：

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

经过近四个月的打磨，APO 终于迎来了 1.0.0 正式版的发布！自开源以来，APO 团队通过不断迭代和优化，确保了产品的稳定性和功能完整性。从最初的开源版本到今天的正式版，APO 已经经历了一系列重大更新和改进。现在，我们很高兴地向大家介绍 APO 的最新状态以及它所能提供的强大功能。

愿景​

APO 致力于打造一个一键安装、开箱即用且简单易用的可观测性平台，我们希望每个用户都能够轻松部署并使用我们的工具，无需复杂的配置过程或深厚的技术背景。通过集成 eBPF 技术与 OpenTelemetry 生态，APO 实现了对分布式系统的高效监控，同时保持了较低的数据存储成本。此外，我们提供的向导式排障界面可以帮助用户快速定位问题根源，减少故障排查时间，提高运维效率。

功能​

为了实现这个愿景，APO 不断迭代和优化，在最新的1.0.0版本中，提供以下亮点功能：

• 一站式可观测：APO 集成了链路、指标、日志和事件等数据，提供数据查询、告警、分析功能，能够一站式解决可观测性和故障定位的需求

• 自动化部署Tracing探针：通过 OneAgent 技术，可以自动在传统服务器和容器环境中安装多语言的 Tracing 探针，极大简化用户的配置工作

• 开箱即用、高效低成本的日志采集方案：充分利用ClickHouse实现高效低成本的日志方案

• （企业版功能）告警分析：针对告警/异常进行分析，帮助用户定位根源告警，自动关联相关数据，快速定位问题根源

• （企业版功能）集成大语言模型AI：解释、分析告警事件等关联数据，重塑排障新交互，帮助用户充分利用数据价值

更多功能详见文章末尾“附录”部分。

未来​

展望未来，APO 将继续秉承开放创新的精神，不断迭代优化产品，实现最终的愿景。计划中的改进方向包括但不限于：

• 持续提升用户体验：增加搜索筛选菜单、日志分词搜索、日志搜索高亮、更多配置可视化……
• 支持更全面的用户权限体系
• 支持日志告警功能
• 支持统计分析业务指标，从业务视角识别故障
• 支持采集请求级别和进程级别的 OnCPU 和 OffCPU 火焰图数据，定位代码级原因
• 北极星指标支持数据库类型应用，协助分析SQL执行耗时/性能分析
• 深度集成大语言模型，降低产品使用门槛，使产品更易用
• 进一步优化OneAgent资源开销

欢迎大家通过各种渠道积极对 APO 提出建议，一起打造最简单易用的可观测性平台。

总结​

随着 APO v1.0.0 的发布，我们迈出了重要的一步，但这仅仅是开始。感谢所有用户的信任与陪伴，让我们携手共进，一起见证 APO 的成长与发展。

相比于 0.9.0 版本，1.0.0 的变化请查看下述更新列表。

新增功能​

• 新增用户登录认证功能
• 上下游依赖关系中新增应用对外调用节点
• 新增统计应用对外调用中间件的RED指标
• 新增 Java JVM 性能指标，并展示在应用基础设施大盘中
• 企业版功能：告警分析中新增通过大语言模型分析数据的功能

功能优化​

• 配置日志库时，支持设置日志字段的数据类型
• 配置日志库时，支持自动解析 JSON 格式日志

缺陷修复​

• 修复全量日志中长日志滚动时文字闪烁的问题
• 修复无法采集容器指标时会持续产生错误告警的问题
• 修复Pod中存在Go语言容器时无法注入探针的问题
• 修复为Python语言容器注入探针失败的问题

附录：更多功能列表​

基于业务接口级别的拓扑​

APO 将相同应用的不同接口调用区分开，清楚地给出应用执行某类业务时的调用关系，相同的应用节点可能会按照调用顺序出现多次。完整拓扑结构太复杂，没有实现拓扑本身应该具有的“地图导航”引导用户找到疑似故障节点的功能，因此 APO 利用延时曲线相似度来收缩相似度较低的节点，更多节点采用表格形式展示，避免拓扑过于复杂无法分析。当用户需要查看下游依赖节点时，可以点击节点名快速切换到不同节点的详情页面。

基于相似度算法排序高效识别级联的故障节点​

在请求延时发生故障时，很多节点都会被级联的影响到，从传统告警中看是很多节点都有告警，在APO中，每个节点都会将其下游依赖的延时进行相似度曲线匹配，从而找到延时最相似的节点，最相似的节点是根因的可疑性更高，这里的下游依赖包括直接下游和下游依赖的依赖。

北极星因果指标主因判定算法​

单纯的分析链路数据会留下很多盲区，难以快速判断延时升高时是自身导致还是依赖导致。北极星因果指标主因算法能够直接给出延时波动是由何种原因导致的，给出了故障原因的方向。例如下图给出的主因是对外网络调用延时变化导致了应用延时变化，结合网络延时指标可以判断出原因到底是网络延时变化还是下游节点延时变化。

快速找到故障链路和日志​

根据延时、错误率和日志错误数量曲线可以快速定位故障可能发生时间点，从而查看时间点附近的日志或链路数据。

内置丰富的指标和展示大盘，快速查看各类监控指标​

自定义告警规则，并通过钉钉、微信、邮件等方式发送通知​

APO介绍：

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO 新版本 v1.1.0 更新发布！本次更新主要包含以下内容：

大模型根因分析支持对节点深入分析（企业版）​

本次更新允许用户在大模型推理结束后，针对疑似故障根因节点作进一步深入分析，例如检查应用的RED指标、北极星指标、错误链路或错误日志等，在同一个页面闭环完成故障根因分析。

优化数据筛选功能​

在此前版本中，查看“服务概览”或“故障现场”数据时，用户只能手动输入“服务名”或“服务端点”进行筛选，且不支持多选。这在监控服务较多的情况下，极大降低了数据查看的效率。

本次更新优化了筛选体验：

• 提供了直观的可筛选数据列表
• 支持通过点击筛选多个数据项
• 降低了翻页频率，提高了数据查询速度和查看效率

内置 NGINX 日志分析看板​

APO 充分利用 Vector + ClickHouse 实现的日志方案，做到了开箱即用、高效、低成本。利用 APO 的日志功能，不仅可以检索日志内容本身，还可以实现很多有意思的功能。一种使用场景是采集 NGINX 的请求日志，然后通过 Grafana 看板将日志统计为指标进行展示。

本次更新将该看板内置在产品中，现在只需要配置三步即可使用。配置文档见“APO文档”-“配置指南”-“配置NGINX请求分析看板”。

更多变化请查看下文的更新日志。

更新日志​

新增功能​

• （企业版）大模型根因分析支持针对疑似故障节点深入分析
• 内置集成 ClickHouse 数据源和 NGINX 日志请求看板。配置方式请参考“APO官网-APO文档”-“配置指南”-“配置NGINX请求分析看板”
• OneAgent 支持采集 RabbitMQ 的监控指标，并提供指标展示看板

功能优化​

• 优化筛选功能，展示可筛选列表，支持通过选择筛选项展示数据
• 故障现场日志自动合并多行日志，降低存储成本
• 全量日志支持隐藏部分展示字段
• 全量日志中支持通过选择直方图范围切换查询时间

缺陷修复​

• 修复可能无法采集到故障现场日志的问题
• 修复全量日志无法展示部分日志字段的问题
• 修复全量日志中配置结构化日志后可能出现无法保存日志的问题
• 修复配置日志库后，日志库描述可能错误的问题

我们一直在持续推进APO项目的开发，同时希望与社区保持紧密联系，因此会定期分享 APO 开源项目的开发进展及未来规划。近期，我们的工作重点集中在以下三个关键方向：

1. 增强可观测性数据：我们正在积极扩展平台的数据集成能力，以提供更深入的系统洞察。例如，我们正在研发持续剖析火焰图功能，这一工具将帮助用户精准识别 CPU 密集型代码段，从而优化应用性能。
2. 提升稳定性和降低运维成本：通过不断改进产品稳定性，我们力求减少用户的部署和运维负担，并提高整体性能。一个具体的例子是，我们近期正在优化Traces回溯采样算法，能有效地降低资源开销，并减少 Tracing 数据量及其存储成本。
3. 加强权限管理：为了确保企业内部使用的安全性和组织性，我们正着力于完善数据和功能的权限控制系统。

在此次 v1.2.0 更新中，APO 已经建立了权限控制的基础架构，并推出了菜单编辑功能，允许用户在“系统管理”下的“菜单管理”界面中自定义功能菜单的显示。基于这一框架，后续版本还将实现基于角色的权限分配、数据可见性管理以及支持任意自定义面板的集成等功能，进一步满足企业的多样化需求。

更多变化请查看下面的更新日志。

更新日志​

新增功能​

• 新增菜单编辑和权限控制功能

功能优化​

• 优化全量日志隐藏字段逻辑
• 调整菜单分组布局，使页面逻辑更清晰

缺陷修复​

• 修复传统服务器场景下会产生容器告警的问题
• 修复全量日志页码过多时，后几页无法展示数据的问题
• 修复全量日志中查看上下文时字段没有被隐藏的问题
• 修复筛选列表中无法对包含特殊字符的服务名进行筛选的问题
• 修复OneAgent中日志采集器可能会崩溃的问题

在 APO v1.3.0 版本中，我们引入了对第三方告警事件的全面支持，旨在为用户提供一个更为集成和高效的告警分析平台。此次更新允许用户将来自不同来源的告警信息统一接入APO平台，从而实现告警事件的集中管理和关联分析。

目前支持接入Prometheus（AlertManager）、Zabbix 和任意支持以 Webhook 发送的告警事件。告警接入后在服务详情中会自动将相关告警事件关联到服务上。同时在企业版的告警分析功能中，能够一键分析出告警相关的服务和影响的业务入口，通过大模型分析或人工深入分析快速对问题进行诊断。

在接入告警后，您可以在“服务详情”中的相关告警事件或“告警分析”功能中查看到告警内容。

更多变化请查看下面的更新日志。

更新日志

⚠️Breaking Change​

对接外部单节点 VictoriaMetrics 的 Helm Charts 配置出现变化，如果您之前在安装APO时对接了外部VictoriaMetrics，请在使用helm upgrade升级前参考文档 “生产环境部署建议” 对已有helm values文件进行更新，否则会导致指标数据无法使用。

新增功能​

• 支持将外部告警接入APO平台，自动关联相关应用，并通过告警分析功能做告警诊断

功能优化​

• 支持将数据库/中间件告警关联到相关服务上
• （企业版）优化单应用场景下大模型推理展示效果
• （企业版）优化network_time类型延时报告分析逻辑,自动选择epoll或network中合适的分析方向

缺陷修复​

• （企业版）修复在离线环境中originx-copilot-ai组件持续重启的问题
• （企业版）修复大模型根因推理在API限流时无法继续执行的问题
• （企业版）修复确认根因无数据时页面无响应的问题

其他​

• 实验性功能：安装时支持使用外部 VictoriaMetrics 集群。

本次更新，APO 为大家带来了“团队”和“数据组”两个概念，让数据管理和团队协作变得更加简单和高效。现在，您可以轻松地将用户组织成不同的团队，并且为每个团队或用户设置个性化的数据访问权限。数据组功能可以将命名空间或服务分组，让不同团队和用户专注于分析他们关心的信息。

要使用数据组功能，点击“系统管理”-“数据组管理”，在该页面中您可以新增数据组，通过选择“命名空间”或“服务名”向数据组中添加包含的数据内容。

创建数据组后，点击“授权”向用户或团队授予该数据组的访问权限。授权后，该用户或团队仅能查看拥有访问权限的数据组内容。

此外，您也可以先创建团队，然后针对团队授予数据组访问权限：

注意，数据组权限目前仅适用于“服务概览”功能，后续我们将把数据组概念整合到更多场景中，同时将开放功能权限，您可以结合“功能权限”和“数据组权限”为不同用户设置不同的访问权限。

更多变化请查看下面的更新日志。

更新日志​

新增功能​

• 新增“团队”功能，现在可以将用户分组到团队中
• 新增“数据组”功能，现在可以授予不同团队或用户不同的数据组查看权限

功能优化​

• 优化上下游依赖拓扑中节点的展示样式

缺陷修复​

• 修复传统服务器环境下实例名称格式错误的问题
• （企业版）修复network_time类型根因分析报告未正确判断net/epoll突变比例导致分析偏差的问题
• （企业版）修复延时报告列表中耗时偏离度不准确的问题
• （企业版）修复大模型分析模块缺少依赖导致报错的问题

Agentic workflow（工作流）：你的经验，Agents的灵魂​

本次更新带来了专为可观测性系统设计的Agentic工作流编排功能，通过使用工作流，能将你的专家经验转变为可复用的执行流程，赋予智能体专业决策能力，提高故障排查效率。核心亮点：

• 经验驱动的智能体：通过直观的工作流编排平台，用户可将运维智慧转化为自动化工作流，赋予智能体专业决策能力。

• 预定义场景工作流：APO内置告警智能分析、自动化运维巡检和复杂故障快速诊断等场景，开箱即用，提升运维效率。

• 灵活编排与定制：基于Dify打造的平台提供数据查询和异常检测工具，用户可轻松创建和修改工作流，适应多样化系统环境。

数据接入：支持通过页面接入新的监控集群或已有数据源​

新增了“接入中心”-“数据接入”页面，现在可以在该页面配置探针安装命令，并根据指引监控新的集群。

您可以根据实际环境情况选择数据接入的方式，目前支持安装新的APO探针（基于OpenTelemetry）采集链路追踪数据，也支持对接已有的OpenTelemetry+Jaeger和SkyWalking数据源。

您还可以在接入中心中查看和管理已经接入的集群信息。注意通过其他方式手动安装APO OneAgent时，无法在该页面中管理。

告警事件列表​

新增的告警事件列表中展示了最近产生的告警事件。在该列表中，APO结合“告警有效性”工作流和“告警根因分析”工作流自动分析告警。

• “有效性”意味着该告警是否对系统中的服务造成影响，如果该告警不是偶发的波动且对服务造成了影响，则会被判定为“有效”
• 针对单个告警，您可以点击“查看根因分析”，自动执行工作流来分析告警的深层原因

这些工作流均可在“工作流”页面中进行编排和优化，您可以根据实际环境情况和排查经验对工作流做出修改。

Traces数据采样​

如果您使用APO OneAgent采集Traces数据，现在您可以通过修改配置开启数据采样功能。开启数据采样后将大量减少Traces数据的保存数据量，降低存储成本。根据环境和采样设置的不同，存储成本将降低到原来的30%或更低。

与传统的头采样和尾采样均不同，APO基于分布式采样策略实现了Traces数据采样。分布式采样在边缘侧（服务所在主机）决定当前数据是否保存，有效降低了整体系统的资源开销。

详细配置方式请参考“文档”-“配置Traces数据采样”。注意如果您安装APO时，采用对接已有的OpenTelemetry和SkyWalking安装方式，则不支持采样功能。

更多变化请查看下面的更新日志。

更新日志​

新增功能​

• 工作流：专为可观测性领域设计的工作流编排平台，预设了多种常用工作流帮助用户解决日常问题
• 告警事件列表：显示近期的告警事件，并通过工作流自动分析告警的根因
• 数据接入：现在APO支持通过可视化页面接入多种外部数据源，当前版本支持对接 OpenTelemetry 和SkyWalking 链路追踪数据
• 链路追踪采样：APO OneAgent安装的链路追踪探针现在默认开启了数据采样，有效降低数据量

功能优化​

• 支持在对接SkyWalking探针时，获取网关类型应用的请求延时指标
• 增强了eBPF北极星指标在 Linux 内核版本5.8以上的适配性

缺陷修复​

• 修复odiglet在传统服务器上将不同的JAVA应用的服务名全部设置为'java'的情况
• 修复告警分析中按故障贡献度排序时，有时因为指标中缺少服务信息label导致的异常

基于 eBPF 获取网络指标存在局限​

eBPF 可以获取到网络 rtt 以及 srtt 等指标，这些指标确实能够反应网络质量，但是其实现是有局限性的，在当前绝大多数客户使用场景是不能反映网络质量的。

eBPF 在网络质量监控中的局限性主要体现在以下几个方面：

1. TCP 建连时获取 srtt 指标： eBPF 在 BCC 中的实现是通过在 TCP 建连时获取内核维护的 srtt（smoothed round-trip time）指标。但是，TCP 连接建立完成后，内核并不会持续追踪每个网络包的传输时间。这就意味着在长连接场景中，srtt 指标并不能反映当前的网络质量变化。不仅仅是 BCC，我们自己开源的 Kindling 也有同样的局限，同时我们也对比了 datadog 等 eBPF 探针实现，发现都有这个问题。
2. 长连接场景中的不足： 现代微服务架构中普遍使用长连接来减少连接建立和拆除的开销。然而，在这种场景下，内核并不会持续更新 srtt 指标，从而无法反映长连接期间的网络质量变化。
3. 实验验证： 通过在 Tomcat 配置数据库连接池连接 MySQL，然后在两者之间注入网络延时故障的实验。在连接建立后，如果在任意一端注入延迟，BCC 的 srtt 指标将不会变化，因为内核不会追踪这些后续包的传输时间。

有没有其他方式判断网络质量​

文章《孙英男-B 站大规模计算负载云原生化实践》是 B 站建立容器云过程的分享，他们在判断网络质量抖动的时候使用的 ping 来判断网络是否抖动。

使用 ping 来判断网络质量是大家常用的一个习惯，而对于 ping 的延时大家在实践中已经形成了一些认知，比如如果 ping 的延时超过 100ms，那么在线网络游戏估计玩不成了。

使用 Ping 来判断网络质量的优点​

1. 简单易用： ping 命令几乎可以在所有操作系统中使用，无需复杂的配置。
2. 实时监控： 可以实时地检测网络延迟和丢包率。
3. 网络连通性： 可以快速判断两个节点之间的连通性。
4. 低开销： 相比其他方法，ping 对系统和网络资源的消耗较低。

使用 Ping 来判断网络质量局限性​

1. 误导性结果： 有时网络中的 ICMP 数据包优先级较低，可能导致延迟或丢包率看起来比实际情况更严重。
2. ICMP 流量限制： 某些网络设备（如防火墙）可能会限制 ICMP 流量，导致 ping 测试结果不准确，甚至 ping 不通
3. 大规模集群的限制： 高频 ping 造成的网络负载：在大规模集群环境中，对大量节点进行频繁 ping 操作，会产生大量 ICMP 流量，从而增加网络负载，影响正常业务流量。虽然一次 ping 的资源开销很小，但是集群规模大了之后，每个容器两两之间都进行 ping，这种消耗将是非常大的，大量的 ping 操作会消耗系统的 CPU 和内存资源，尤其是在需要同时监控许多节点的情况下。

如何才能低开销的完成网络质量的快速判断​

虽然 eBPF 和 ping 包的方式都有一定局限性，但是 eBPF 的局限性受限于内核的实现，该局限没有办法突破的，而 ping 包的局限是可以突破的。

• 误导性结果的突破：用户认知的突破，如果发现 ping 延时很严重了，那真实的网络流量更加严重，这点突破很容易。
• ICMP 流量限制：防火墙的配置即可允许 ping 包的发生。
• 大规模集群的限制：大规模集群中，如果两两相互都需要 ping 这是非常耗资源的做法，但是我们注意到实际场景中容器通过网络与其他容器交互的范围是有限制的，并不会和所有的容器都进行交互，这点是有优化空间的。

大规模集群适用低开销基于 ping 包的网络质量评估方案​

开源项目 coroot 有一个非常好的思路，他们使用了一个叫做 pinger 的组件，该组件工作原理如下：

• 基于 eBPF 获取容器之间的关系图，并不是获取 SRTT 等指标
• 根据节点关系图来发送 ping 包，上游节点对下游节点进行 ping，这样能够极大的降低任意两两 pod 互相 ping 的开销

但是 coroot 的 eBPF 实现要求内核版本高于 4.14，国内还有很多操作系统停留在 centos7 系列的用户，他们是没有办法用 coroot 的实现。

我们在 coroot 的基础之上，针对国内的环境做了优化，主要优化如下：

• 通过读取 proc 目录下来获取关系图，而不是通过 eBPF 获取关系图，这样就降低了对内核版本的依赖
• 沿用了 coroot 原有 pinger 组件的思路，上游节点对下游节点进行 ping，极大降低任意两两 pod 互相 ping 的开销
• 数据最后通过 exporter 暴露到 prometheus 或者 victoria metrics 中

最终效果图，展示 srcip 到 dstip 的 ping 值

题外话：我们不去修改 coroot ebpf 代码使其适配低版本内核主要是基于投入产出比，适配低版本内核需要调整代码量较大，我们通过 eBPF 采集的北极星因果指标是适配了低版本内核的。

自APO开源以来，社区成员询问APO是否支持Skywalking Agent，以避免已使用Skywalking的应用在测试发版过程中需要重新部署探针。APO利用OpenTelemetry生态，通过skywalkingreceiver实现Skywalking Trace到OTEL Trace的转换，为已经使用Skywalking的用户提供无缝体验。

有公司通过将Skywalking转换为OpenTelemetry+ClickHouse，成功降低了资源开销三分之一。APO如何实现这一功能？

使用ClickHouse存储Trace​

APO迁移了Jaeger-remotestorage至Jaeger 1.58，使用Jaeger-clickhouse项目表结构存储Trace，并集成JaegerUI展示Trace。APO在设计上简化了Trace的细节，使得在Jaeger 2.0改版以更好支持Clickhouse时，APO的集成也变得简单。

OneAgentBuilder：构建适用已有环境的OneAgent​

为了快速接入APO，特别是对于已经使用Skywalking和OpenTelemetry的用户，APO提供了OneAgentBuilder。

使用方法​

1. 下载OneAgentBuilder
2. 将模板中的skywalking Agent探针或OpenTelemetry探针替换为已使用的版本
3. 使用docker builder生成APO-OneAgent镜像，该镜像称之为定制化OneAgent镜像
4. 按照安装文档安装APO-OneAgent，安装过程中替换OneAgent官方镜像为定制化的OneAgent

定制化OneAgent镜像使用​

生成APO-OneAgent镜像后，您可以：

• 将镜像导入至目标机器
• 或者导入到Harbor中

然后，根据APO 官方文档安装 OneAgent，注意替换 OneAgent 官方镜像为您定制化 OneAagent。

结构示例​

以下是OneAgentBuilder中模板的结构示例：

preload-builder
├── opentelemetry-java
│   ├── Dockerfile
│   ├── libapoinstrument.conf
│   └── opentelemetry
│       └── opentelemetry-javaagent.jar
└── skywalking-java
    ├── Dockerfile
    ├── libapoinstrument.conf
    └── skywalking-agent
        ├── activations
        ├── bootstrap-plugins
        ├── config
        ├── expired-plugins
        ├── LICENSE
        ├── licenses
        ├── logs
        ├── NOTICE
        ├── optional-plugins
        ├── optional-reporter-plugins
        ├── plugins
        └── skywalking-agent.jar

APO v0.2.0 更新记录

新增功能​

• APO 支持接入 SkyWalking Agent
• 支持在安装 OneAgent 时替换默认的 Opentelemetry v2.5.0Agent，例如其他版本或SkyWalking 等
• 新增查看服务的“更多下游依赖”拓扑，加快定位故障原因
• 新增配置页面，支持修改数据保留周期
• eBPF 探针适配更多内核版本，支持自动适配内核版本

功能优化​

• 优化安装体验，支持独立部署 APO 服务端，支持监控 Kubernetes 环境以及传统服务器中的应用
• 优化告警规则页面展示效果
• 优化 APO 接口查询效率，提高页面响应速度
• 优化 Java 网关类型服务的监控数据准确度

缺陷修复​

• 修复部分场景下 ebpf-agent
• 修复部分服务端点无法查询出实例信息的问
• 修复日志/链路列表中不同实例包含了相同列表的问题
• 修复日志/链路检索页选择器的问题

其他​

• APO页面汉化