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

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

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

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

---

更新日志​

新增功能​

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

功能优化​

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

缺陷修复​

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

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

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

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

优化数据筛选功能​

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

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

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

内置 NGINX 日志分析看板​

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

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

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

---

更新日志​

新增功能​

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

功能优化​

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

缺陷修复​

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

运维的挑战与责任​

在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。AIOps（人工智能运维）应运而生，旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。

AIOps当前技术与输出​

AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题，预测潜在故障，并自动化常见问题的解决过程。通过AIOps，许多组织已经显著提高了故障响应时间，减少了误报，优化了运维流程，提升了IT系统的整体可靠性和性能。

AIOps仍然存在挑战：故障根因与可观测性数据割裂​

尽管AIOps技术取得了显著进步，但在故障根因分析方面仍面临一个重大挑战：故障根因与可观测性数据（如日志、指标、追踪）之间的割裂。AIOps系统虽然能够推荐可能的故障根因，但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识，在海量的数据中寻找证据来验证这些推荐，这一过程既耗时又容易出错。

Gartner 魔力象限中领先象限做到的效果​

Dynatrace 效果​

Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。

从 Dynatrace 的视频中，如果发生了故障之后，AI推荐出AI根因之后，用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。

Dynatrace 做到全球最牛的地方，就是能够将各种可观测性数据融为一体，并以时间线为维度还原故障现场，这个本质上还是人为分析，所谓的AI推荐，给出的是关键节点。

如果没有这个故障根因推荐，用户使用 Dynatrace 怎么做呢？仍然是围绕着故障时间点，利用 Dynatrace 的 Visual resolution path 人为分析故障根因。

结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。

Datadog 效果​

Datadog 的 Watchdog RCA给出仍然是可能性，具体从可观测性中找证据来证明这点，仍然需要用户自己来做。

结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。

可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂​

举例说明：Dynatrace 的根因例子为节点CPU利用率达到100%，其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%，这个时候人是很难判断程序是否会受到CPU供给瓶颈，需要额外提供更多的数据去判断CPU利用50%的时候，程序的执行是否会受到调度器的影响，这取决于很多因素，比如机器上需要调度的程序多少，CPU调度器排队的长度等，总而言之，可观测性数据存在盲区。

可观性数据由于存在盲区，导致人都很难根据可观测性数据推理出故障，只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的（资深运维人员在判断这两点的时候CPU利用率为50%，是故障根因也是需要非常深厚的经验）。

可观测性数据盲区更详细的介绍，请参考之前的文章。

• 可观测性工具的盲区与故障排查困局
• Log、Metrics、Trace的联动方式探讨

内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题​

在之前的文章介绍了可以使用内核视角下持续剖析，能够形成基于北极星指标的排障体系。可参见：内核视角下持续剖析 VS 代码视角下的持续剖析

基于这个标准化排障体系进行故障根因推导的时候，就能够同时自动化关联相关指标。比如如果发现网络时间很长，这个时候就可以关联网络相关性指标，必要时还可以同步 DeepFlow 等关键网络事件及数据，提供证据证明网络确实有问题。

之前的文章介绍过APO是如何使用Grafana Alloy采集prometheus生态的指标体系。这篇文章介绍APO是如何采集Trace和log的，这两项数据的采集存在以下问题：

• 日志需要配置采集的日志目录，并不是每个应用的日志目录都非常规范，这就导致配置工作量的增加
• Trace需要配置针对语言的Agent完成数据采集
• 在容器环境不管是修改镜像或者使用init Container方式，都有挺多配置的工作

OneAgent的设计目标​

OneAgent的设计目标是尽量减少用户的配置工作，尽快的完成数据的采集。在设计过程中，参考了很多的业界先进的技术实现，比如datadog的onestep agent的实现机制，另外重要的就是Odigos这家公司的实现。Datadog不用做更多的介绍，这里简单介绍下Odigos这家公司：Odigos的口号是“Instant Distributed Tracing”，有兴趣可以访问其官网：https://odigos.io/ ，OpenTelmetry 的 GO auto instrument 项目：https://github.com/open-telemetry/opentelemetry-go-instrumentation 就是由该公司捐献的。

Odigos开源的https://github.com/odigos-io/odigos 实现中能够实现以下功能：

• 基于应用当前已经启动的POD进行语言识别
• 基于K8s manifest挂载对应语言的探针文件和配置到对应的应用
• 通过更新K8s manifest触发应用重启以应用探针

为了实现OneAgent的设计目标，我们调整了Odigos的执行流程，使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

1. 更新内容以patch形式存储到应用的Annotations中
2. 用户手动重启pod时，通过webhook拦截pod创建请求，应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时，集群所有应用同时重启，造成资源紧张；而是预先设置好探针配置，在应用下次更新时，自动完成探针的添加。

Odigos中没有包含非K8s应用的实现，我们采用了Linux的Preload机制来完成下面的工作:

• 通过LD_PRELOAD加载Preload库，在应用启动前拦截启动命令，完成语言识别和后续工作
• 基于识别到的语言设置探针配置，通常以特定的环境变量加入到启动命令
• 将改造后的启动命令交给Linux继续执行，完成应用的启动和探针的应用

为了实现OneAgent的设计目标，我们调整了Odigos的执行流程，使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

1. 更新内容以patch形式存储到应用的Annotations中
2. 用户手动重启pod时，通过webhook拦截pod创建请求，应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时，集群所有应用同时重启，造成资源紧张；而是预先设置好探针配置，在应用下次更新时，自动完成探针的添加。

Odigos中没有包含非K8s应用的实现，我们采用了Linux的Preload机制来完成下面的工作:

1. 通过LD_PRELOAD加载Preload库，在应用启动前拦截启动命令，完成语言识别和后续工作
2. 基于识别到的语言设置探针配置，通常以特定的环境变量加入到启动命令
3. 将改造后的启动命令交给Linux继续执行，完成应用的启动和探针的应用

针对日志数据的采集，我们采用了阿里开源的 https://github.com/alibaba/ilogtail 工具，它有下面一些优点:

1. 基于Linux的inotify机制，相较于轮询读取文件，消耗更低
2. 内置一套设计良好的插件系统，性能开销较大的采集阶段使用C语言实现，确保高效；后续处理采用Go实现，可以快速的进行数据完善和处理
3. 内置的采集插件支持了对父级目录下日志文件检索，避免用户手动配置每个应用日志地址

在ilogtail基础上，我们实现了功能增强插件，用于统计需要的日志指标，填充日志进程信息和日志数据采样。

---

程序语言的自动识别​

目前的程序语言识别均基于启动命令特征和启动文件信息:

1. JAVA: 检查启动命令是否满足 java [-options] class [args。。。] 或 java [-options] -jar jarfile [args。。。] 格式
2. PYTHON: 检查启动命令中是否包含python
3. Golang: 读取启动文件的内容，检查是否有可识别的buildInfo信息
4. NodeJS: 检查启动命令中和启动文件路径中是否包含node
5. Dotnet: 检查启动环境变量中的环境变量名中是否包含DOTNET和ASPNET

探针配置的注入​

在完成应用语言类型的识别后，开始准备探针的配置信息。

1.OTEL体系下的APM探针均原生支持基于环境变量来设置探针，我们目前主要预设了下面的配置：

• OTEL_EXPORTER_OTLP_ENDPOINT 设置探针数据的发送地址
• OTEL_SERVICE_NAME 设置应用名称
• OTEL_METRICS_EXPORTER/OTEL_LOGS_EXPORTER 设置为 none，关闭指标/日志采集

2.Skywalking当前以内置的配置文件作为中转，也支持使用环境变量进行配置，主要设置：

• SW_AGENT_COLLECTOR_BACKEND_SERVICES 设置探针数据发送地址
• SW_AGENT_NAME 设置应用名称

对于K8s应用，大部分的环境变量会由Odigos通过k8s提供的Device Plugins加入到容器内；

用户已经在K8s Manifest定义了的环境变量，会在K8sManifest显式的合并到用户定义的Envs部分。

对于非K8s应用，环境变量会直接被添加到启动命令中，如果和用户定义变量发生冲突，始终使用用户定义变量。

---

探针的拷贝​

在K8s环境中，由于容器的文件隔离特性，应用无法直接获取到需要的探针文件。Odigos通过将宿主机路径挂载到应用容器内部来向应用提供探针文件，默认将探针文件放到应用的/var/odigos 目录下。

在非K8s环境中，由于应用可以直接获取到宿主机上的探针文件，所以当前没有进行探针文件的拷贝。

日志和进程信息关联​

在K8s环境下，采集器通过日志的文件路径可以直接关联到容器，再由容器可以直接关联到所属的应用。这使得在查询日志时，可以通过应用来过滤日志，对于查找关键信息有很大帮助。

非K8s环境中，采集器获得的日志的文件路径就不再像K8s环境中那么规范。不论是ilogtail所使用的inotify机制，或者其他基于文件轮询的日志采集工具，都无法获取到日志是由哪个进程产生的。常规的处理方式是整个项目推行日志文件路径规范，从而可以解析日志文件路径来获取应用信息，这是一种成本较高的解决方案。

APO使用了Linux的Fanotify接口来关联文件和应用信息，它是一个在linux内核2.6.37引入的系统接口，利用Fanotify可以自动关联进程所产生日志文件。

为了降低监听Fanotify事件的资源开销，APO遵循下面这套方案进行文件到应用关联关系的维护:

1. 通过inotify获取到日志文件更新信息
2. 将日志文件路径添加fanotify监控标记，监控该文件的修改和关闭事件
3. 日志文件下次被修改时，获取到修改该文件的进程信息。缓存该日志文件路径对应的进程信息，并关闭对该文件修改事件的监控
4. 直到接收到该日志文件的关闭事件，这意味着之前获取的进程停止了对该文件的写入；此时重新开始监控该文件的修改事件，以更新该日志文件路径对应的进程信息

通常仅应用进程会对日志文件进行修改，因此上面这套方案可以以极低的消耗完成较为可靠的日志文件路径到进程信息的关联。

---

总结​

APO通过OneAgent中的集成修改的Odigos机制，实现了不同语言的应用程序自动完成OTEL trace探针的安装和环境变量配置，同时通过集成ilogtail采集了日志，并能够实现日志和应用的关联。

OneAgent能够在容器环境和传统虚拟机上同样工作。

APO介绍：

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

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO 软件的新版本 v0.3.0 已经正式发布了！这次的更新不仅带来了功能上的改进，还有用户体验上的重大升级。以下是此次更新的主要亮点：

关联告警事件，快速发现故障​

在 v0.3.0 版本中，我们引入了全新的告警事件关联功能。这一特性可以帮助您更高效地识别和定位服务相关的潜在问题。通过将相关的告警事件聚合在一起，您可以更容易地追踪到问题的根本原因，从而加快故障排除的速度。

此外，我们还将告警状态灯关联到了具体的告警原因，只需要将鼠标悬浮到状态灯上即可查看，再也不需要问“为啥这里红”了！

提升数据筛选效率​

为了帮助用户更好地从海量数据中获取有价值的信息，我们在新版本中加强了“服务概览”页面数据筛选的功能。现在，您可以基于“服务名”、“服务端点”或“命名空间”来精确定位期望查看的数据，这将极大地提高数据分析的效率。

更顺滑的安装流程，优化安装体验​

我们一直致力于简化软件的安装步骤，以减少用户的前期投入时间和精力。在本次更新中，我们重新设计了安装流程，尤其减少了探针无法启动的情况，使得整个过程更加流畅。

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持，APO 才能不断进步。我们期待着您的宝贵意见，也欢迎您继续参与到 APO 的成长旅程中来！

---

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

新增功能​

• “服务概览”页面新增筛选条件，可模糊查询服务名、服务端点和命名空间
• “服务详情”页面新增告警事件列表
• 告警状态灯支持鼠标悬浮显示告警原因
• 指标曲线图支持鼠标悬浮放大，便于查看具体时间的指标
• “服务详情”页面指标曲线图支持通过选择时间范围修改查询时间
• 新增中间件指标监控大盘

功能优化​

• 在 Kubernetes 环境安装 OneAgent 时，支持对所有命名空间进行监控
• 服务概览页面展示服务所属的命名空间，在传统服务器环境中显示N/A
• 优化“应用基础设施大盘”指标显示效果，兼容各类监控环境
• 接入 SkyWalking 后，“链路追踪”页面支持按照 SkyWalking 的 TraceID 进行检索

缺陷修复​

• 修复时间选择器在切换页面时可能被重置的问题
• 修复容器环境可能无法获取到容器启动时间的问题
• 修复 node-agent 部分情况下会内存溢出的问题

其他​

• 首次进入服务详情页时，展示功能引导
• 增加功能与术语的解释说明

APO 新版本 v0.4.0 正式发布！本次更新主要包含以下内容：

新增影响面分析，识别服务端点对服务入口的影响​

服务入口是指业务被访问时调用的第一个服务端点，在调用拓扑图中处于最上游。服务入口直接反映了系统对外提供服务的状态，因此了解服务入口的状态对于保证系统服务的稳定性至关重要。

APO 实现了服务端点粒度的拓扑图，还原了每一个服务端点的调用路径，能够准确定位其调用路径上的服务入口。我们在服务详情页中关联了服务入口，便于用户及时了解当前服务对服务入口的影响情况，对影响面进行分析。

新增服务调用的数据库指标​

应用的RED指标（请求次数、错误率、响应延时）反映了应用提供的服务质量，而服务质量受到多种因素影响，其中应用对外部服务的依赖是重要的一部分。本次更新 APO 优先引入了数据库调用指标，当服务质量发生问题时，能在第一时间了解是否是外部数据库导致的。

优化告警事件关联展示​

本次更新中，如果服务端点关联到告警事件，将优先展示告警详情，同时优化了告警列表的展示效果。

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持，APO 才能不断进步。我们期待着您的宝贵意见，也欢迎您继续参与到 APO 的成长旅程中来！

---

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

新增功能​

• 服务详情页新增针对服务入口的影响面分析
• 服务详情页新增数据库调用指标（服务粒度）
• 调整架构提高适配性，基础功能支持全部内核版本

功能优化​

• 查询故障现场链路增加更多筛选条件
• Kubernetes 事件统计将警告事件标记为红色
• 优化 OneAgent 中 Alloy 的内存占用

缺陷修复​

• 修复重启 OneAgent 导致 JS、Python 语言 Instrument 探针丢失的问题
• 修复服务概览页无法通过指标曲线图切换时间范围的问题

APO 新版本 v0.5.0 正式发布！本次更新主要包含以下内容：

新增页面配置告警规则和通知​

在之前的版本中，APO 平台仅支持展示配置文件中的告警规则，若用户需要添加或调整这些规则，必须手动编辑配置文件。而在新版本中，我们新增了一套可视化的告警规则配置界面，使用户能够直接通过 APO 控制台来进行告警设置。此外，配置界面内置了常用的指标查询模板，用户只需根据实际需求选取相应的指标并设定阈值，即可轻松完成规则配置。

同时新版本还支持配置告警通知，目前支持邮件通知和 Webhook 通知。

0.5.0 作为告警配置的第一个版本，仅包含了基础功能，未来我们还将继续优化用户体验，并带来更丰富的配置选项以满足更复杂的场景需求。欢迎大家积极向我们提出建议。

更好用的时间筛选器​

在之前的版本中，APO 的时间筛选器仅支持查询绝对时间，并且需要用户手动触发更新操作。而在新版本中，我们重新设计了时间筛选器，增加了相对时间的支持，并实现了页面的自动刷新功能。以后再也不会出现“新监控了一个应用，但怎么刷新页面也没数据”的问题啦！

支持使用自建的 ClickHouse 和 VictoriaMetrics​

从 0.5.0 版本开始，APO 支持将数据存储到用户自建的 ClickHouse 和 VictoriaMetrics 中，无论您是使用单节点还是分布式集群方案，APO 都能够无缝接入。在生产环境中，我们建议使用托管的 ClickHouse 和 VictoriaMetrics 集群来保证可用性。

近期，APO 社区正在积极设计开发“全量日志”的功能，我们调研分析了业内优秀的日志方案，结合在可观测性领域积累多年的经验，完整设计了从日志的采集、处理、存储到展示的方案，将 APO 对日志的思考融入其中。我们的目标始终是为社区提供一款开箱即用、高效率、低成本、强扩展性且拥有良好用户体验的可观测性产品，全量日志方案自然也不例外。全量日志功能预计将于10月开源，敬请期待！

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持，APO 才能不断进步。我们期待着您的宝贵意见，也欢迎您继续参与到 APO 的成长旅程中来！

---

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

新增功能​

• 新增页面配置告警规则和通知功能
• 服务实例中关联实例所在节点信息，辅助排查节点

功能优化​

• 优化时间选择器，支持查看相对时间，支持自动更新
• 优化故障现场链路页面描述，使信息显示更清晰

缺陷修复​

• 修复单进程镜像覆盖JAVA_OPTIONS环环境变量失败导致无法加载探针的问题
• 修复部分情况下无法获取 Go 语言程序的链路追踪数据的问题

其他​

• 支持对接自建的低版本 VictoriaMetrics，建议版本 v1.78 以上
• 支持对接自建的 ClickHouse 集群（安装时配置）
• 服务概览无数据时提示安装和排查手册
• 提供一键安装脚本部署测试应用，验证 APO 安装结果和产品功能
• 提供仅使用链路追踪或采集指标的安装方案

在 v0.6.0 版本中，APO 发布了基于 ClickHouse 开箱即用的高效日志方案，为用户提供了采集、处理和检索全量日志的基础功能。新版本在此基础上进一步强化了日志处理和检索的能力，提升了用户体验。

支持为不同日志设置不同的解析规则，提取出关键信息并加速检索​

日志中往往存在许多关键信息，将这些关键信息提取出来能够针对性的检索数据，通过分析此类关键信息能够发现平时难以注意到的洞察。通常不同的应用在输出日志时，会采用不同的日志格式，要从日志中提取关键信息，需要能够针对应用和日志格式设置解析规则。

新版本中用户可以根据不同的日志格式设定自定义解析规则，从日志内容中提取出关键字段，例如从 Nginx 日志中解析出用户IP地址、访问路径、响应状态码等信息。通过设置解析规则，APO 能够将这些关键信息独立展示，这不仅加速了检索过程，还提高了数据的准确性和相关性。

支持对接外部日志表，在同一个平台中查看不同数据源​

用户通常需要处理来自多个系统和平台的日志数据。APO 新版本支持对接外部日志表，使用户能够在同一平台上查看和分析不同来源的数据。这一功能简化了数据整合流程，消除了多平台切换的繁琐，提高了管理效率和协作能力。

支持全文检索和查看日志上下文​

全文检索功能使用户能够迅速定位具体信息，而查看日志上下文的能力则为用户提供了更全面的事件背景。这对于问题排查和事件分析尤为重要，用户可以更清晰地理解问题的复杂性，快速制定解决方案，从而提高系统的稳定性和可靠性。

增强对 Go 语言程序的兼容性​

此外，该版本使用 Grafana Beyla 探针替换了 opentelemetry-go-instrumentation 探针，增强对 Go 语言程序的兼容性。Grafana Beyla 能够无侵入性地采集 Go 语言程序的链路追踪数据，APO 集成并增强了该探针，使各类数据能够无缝集成，保证不同语言程序间体验的一致性。 注意 Grafana Beyla 仅支持运行在满足以下条件的内核中：

• Linux 内核 5.8 及以上版本并且开启了 BTF 内核编译选项；通常 5.14 及以上版本已经默认开启
• RedHat Enterprise Linux 4.18 kernels build 348 及以上，包括 CentOS, AlmaLinux 和 Oracle Linux

---

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

新增功能​

• 日志功能支持为不同的应用配置不同的日志解析规则
• 支持对接外部 ClickHouse 日志表，在同一个平台中查看不同日志数据源

功能优化​

• 采用 Beyla 替换 openTelemetry-go-instrument 探针，优化对 Go 语言程序的兼容性
• 优化 OneAgent 的内存开销

缺陷修复​

• 修复 apo-backend 非持久化配置下 SQLite 创建数据库文件失败的问题
• 修复 ClickHouse 中全量日志数据无法配置副本的问题
• 修复响应时间90分位数查询失败的问题
• 修复多实例情况下日志错误数查询失败的问题

APO介绍：

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

apo.kindlingx.com

https://github.com/CloudDetail/apo

本次更新，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