在可观测性领域，我们始终在追问一个问题：当系统出故障时，为什么定位和恢复还要这么复杂、这么慢？

我们从一开始就在做一件事——降低产品使用门槛，让你在最紧急的时刻，能用最快的方式找到根因、恢复业务。

我们不断琢磨，不断实验：到底怎样才能真正做到？

渐渐地我们发现，如果继续沿用传统的可观测性思路，终究会撞到瓶颈。因为人力去关联、比对、排查的方式，已经跟不上复杂系统的节奏。

而这正是 AI Agent 能够改变的地方。

AI 的价值，不只是“帮你分析链路数据”，而是彻底改写人与可观测性工具的关系。它可以主动思考、串联不同来源的线索，把人从一堆碎片化的数据里解放出来，直接对话式地给出分析和方向。

这就是为什么我们坚信：未来的可观测性，一定会被 AI Agent 重塑。

基于这个想法，我们开发了故障分析智能体：Syncause。

---

故障发生时，AI Agent 能做什么？​

让我们先理清楚故障处理的本质。当故障发生时，我们的处理过程通常是：

发现 → 响应 → 诊断 → 恢复 → 复盘。

但在实际的故障诊断和解决过程中，我们发现可以分为三个关键阶段：

第一阶段：快速定向。 故障发生了，但到底是什么类型的问题？是应用层的bug？数据库压力过大？网络连接异常？还是外部依赖服务挂了？这个阶段的目标是缩小排查范围，找到大致方向。

第二阶段：紧急止血。 知道了问题方向后，如何最快恢复业务？回滚代码？切换流量？扩容资源？还是重启服务？这个阶段的核心是快速止损，让用户能够正常使用。

第三阶段：深度追因。 业务恢复后，找到导致故障的根本原因。是哪一行代码？哪个配置项？哪次变更？这个阶段是为了彻底解决问题，避免再次发生。

当然，现实往往没有这么理想化。简单的问题可能在第一阶段就找到了根本原因，复杂的问题可能需要多个轮次的循环。但这个框架帮助我们更清晰地思考 AI Agent 应该解决什么问题。

Syncause 目前主要聚焦解决前两个阶段的问题：

• 它会先帮你快速缩小范围，告诉你问题出现在应用或主机上；
• 它会自动把指标、日志、链路，甚至 eBPF 收集到的内核层面信号，串在一起；
• 它会判断出问题是 CPU、磁盘、网络，还是更高层的调用；
• 然后，它还会给出切实可行的恢复建议，让你在压力最大的时刻，能快一步止损。

另外，Syncause 被设计成一个开放的平台，能够集成各类可观测产品的数据。无论你用的是Prometheus、Jaeger、Grafana、ELK，还是商业化的APM工具，Syncause 都能帮你把这些分散的数据整合起来，统一分析。

---

我们准备了问答环境，你可以亲手试试​

Syncause 还在内测阶段，但我们搭建了一个 Sandbox 环境可以直接测试效果。

Sandbox 里面跑着一组测试应用，这些应用会“故意”出现各种问题。你只需要直接跟 Syncause 对话，让它来帮你分析原因、提出方案。

甚至，你也可以自己重新部署一个应用，然后注入不同的故障，看看 Syncause 如何一步步陪你走过排查的过程。

我们想把 Syncause 打造成一个真正对你有用的产品。所以特别欢迎你来试用，甭管是建议还是批评，都尽管告诉我们。

如果你感兴趣可以加入 Waitlist，成为早期用户与我们共创，和我们一起把这个 Agent 打磨到极致，我们会提供永久免费使用。

点击链接：https://sandbox.syn-cause.com 即可进入Sandbox环境。

---

本次 APO v1.12 版本更新带来了以下功能优化和问题修复：

更新日志​

⚠️ 兼容性提示​

本次 apo-one-agent 的版本更新中对 ilogtail进行了升级，升级后支持在 containerd v2 环境下采集容器日志。如您手动修改过日志采集配置，需要在更新后重新配置；如您使用默认配置，则无需修改，升级探针后会自动适配。

需手动调整的变更内容：

1. 日志采集配置文件中，所有流水线均需要添加配置: global.UsingOldContentTag = true
2. 日志采集配置文件中，原文件采集器 file_log 已弃用，改为使用 input_file，具体配置参考loongcollector的官方配置文档： https://observability.cn/project/loongcollector/input-file

功能优化​

• 告警分析工作流中优化分析下游依赖问题，识别下游服务于应用
• 通过全量日志查询故障现场日志；开启全量日志时，无需重复采集故障现场日志
• 日志采集兼容 containerd v2 容器运行时
• 链路追踪探针自动注入兼容 alpine-linux 基础镜像 (兼容musl库)

缺陷修复​

• 修复时间选择器可能无法刷新的问题
• 修复新增用户时数据组权限未分配问题
• 修复服务概览告警状态未基于 namespace 过滤器过滤的问题
• 修复故障报告中数据展示异常的问题
• 修复 profile-agent 在低版本Linux 上存在 Slice Out of Bound 错误

---

本次 APO v1.10.0 版本更新带来了以下新功能和问题修复：

更新日志​

⚠️ 兼容性提示​

本版本新增了集群标识，用于支持按集群隔离采集数据。升级后：

• 旧数据将归属到“空集群”
• 新数据将归属到您设置的集群

大部分功能已做好兼容，数据展示不受影响。但部分依赖历史数据的功能，可能因数据分属不同集群，出现数据不连续的问题。可能受影响的功能：

• 依赖历史数据的告警规则
• AI 智能根因分析

新增功能​

• AI告警故障方向识别：基于大模型能力自动分析告警潜在原因，智能生成故障方向，提升故障定位效率。

• 根因分析报告生成：在完成告警根因定位后，系统将自动生成结构化分析报告，帮助用户更直观地理解告警产生的背景与原因。

• 告警分析工作流扩展：新增支持识别内存泄漏场景，并进一步增强对主机高 CPU、内存占用及网络延迟问题的分析能力。
• 多集群支持：支持集群级别的数据隔离与筛选。安装时可配置数据所属集群，便于在多集群环境中进行精准查询与管理。

功能优化​

• 日志查询性能提升：显著优化全量日志检索性能，加快数据访问速度。
• 数据组增强：支持嵌套子数据组，提升企业多层级管理能力；同时支持按集群、命名空间、服务名等多维度配置与筛选。
• 告警分析效果优化：优化 AI 工作流分析策略，进一步提高诊断准确率与覆盖面。

缺陷修复​

• 修复在传统服务器无命名空间场景下，数据无法正确筛选的问题。
• 修复运行一段时间后可能导致北极星指标丢失的问题。
• 修复服务端点名称中含特殊字符时，查询接口报错的问题。
• 修复时区不一致导致历史基线异常的问题，确保故障报告数据一致性。

---

“很多用户觉得我们在吹牛，根因分析做不出来，其实我们一直在做对的事——现在论文也证明了这点。”

背景​

在当前AIOps领域，主流做法多集中在围绕 Trace、Log、Metrics 的机器学习建模与关联挖掘，寄希望于在复杂数据中“找出”故障根因。但我们在与大量企业沟通后发现，这种方式在实际生产环境中往往难以落地 —— 算法容易泛化失败，结果无法解释，根因归因流于表面，甚至被质疑“是否真的能做到”。

我们的观点是：如果一个经验丰富的人都很难给出确定且可解释的根因判断，而需要依赖现象推测与试错过程来还原问题，那算法更不可能自动做到这一点。因为这些故障往往需要通过上下文、调用链、线程与资源的交互等复杂的程序行为路径来还原，不是简单依赖几个KPI指标变化，靠模型“拟合波动模式”就能判断出来的。这类问题的本质并不是数据挖掘，而是“对程序运行机制的理解”与“对故障传播路径的观察”。只有把这些底层行为真正观测到，才能找出根因。

我们致力于通过eBPF技术直接采集线程级的内核资源交互信息，从线程与锁、磁盘、CPU调度、futex、epoll、socket 等系统资源的精细互动中还原问题现场。然后基于这些数据，结合我们的经验构建出专家规则小模型，并使用业界相对比较成熟的算法来实现故障根因分析 —— 用最基础但最扎实的方式解决根因定位的“最后一公里”。

我们这套理论比较新，和很多用户交流的时候，很多用户觉得我们在吹牛。我们理解这种质疑，但我们一直坚信：我们不是在“吹牛”，我们是在做对的事。

最近我们看到一篇 arXiv 上的最新论文《eBPF-Based Instrumentation for Generalisable Diagnosis of Performance Degradation》（2025年5月），首次从学术角度全面验证了我们坚持的方向是可行且高效的。

该研究提出了一套跨应用、跨语言的 eBPF 监控体系，通过16类内核子系统指标构建“线程行为画像”，在Kafka、MySQL、Cassandra等典型系统中完成了无需trace、无需日志的自动根因归因，准确识别出锁竞争、磁盘瓶颈、CPU争用、外部依赖等多种常见性能劣化问题，诊断路径完全可解释。

我们采集的数据基本一致，只是分析角度和论文略有区别，下面是论文的核心思路。

---

论文思路​

这篇论文的核心目标，是探索一套无需依赖应用层trace和日志，仅通过eBPF从系统内核采集“线程与关键资源交互数据”，就能完成跨应用场景的性能劣化诊断的方法论。

1. 核心问题定义​

论文指出，当前性能诊断面临两个核心难点：

• 第一是数据粒度不够：系统级指标（如CPU利用率）过于粗糙，无法解释“到底哪个线程在等待什么资源”；

• 第二是通用性差：很多诊断方法依赖特定中间件、语言、日志或trace结构，难以跨系统使用。 因此，作者尝试构建一个通用、跨平台、跨语言的“线程行为画像”体系，通过eBPF捕获线程与资源的交互路径，反推出性能问题的根因。

2. 指标体系设计​

作者基于六大内核子系统构建了16类eBPF指标，具体包括：

子系统	指标例子	描述
调度	runtime，rq time，iowait time	线程在CPU、runqueue、iowait上的耗时
futex	futex wait time，wake count	锁竞争情况，包括等待和唤醒频次
pipe/socket	pipe wait time，socket wait count	跨线程通信延迟，识别阻塞关系
epoll	epoll wait time，epoll file wait	识别异步IO等待瓶颈
block IO	sector count	识别磁盘压力或争用情况
VFS/网络	多个等待与访问频次指标	提供线程级资源使用视角

指标采集遵循“只监控与目标应用有关的线程”，避免全系统追踪带来的性能开销。

3. 分析方法：选择性线程追踪 + 行为分布变化检测​

诊断的关键流程如下：

1. 识别入口线程：通过 socket wait、epoll wait等指标找到对外提供服务的入口线程；
2. 追踪依赖线程：只追踪与入口线程有pipe/socket/futex等资源交互的“对等线程”，逐步构建线程依赖链；
3. 检测异常分布变化：将每个线程的指标时间序列与业务KPI（如95延迟）对齐，对齐后若出现类似分布漂移，即可标记该线程及其资源为瓶颈点；
4. 推断资源约束路径：如果瓶颈线程依赖于某共享资源（如同一个pipe、锁、磁盘），则反推出具体瓶颈资源；
5. 生成可解释路径：最终输出“哪个线程被谁阻塞、阻塞了多久、原因是哪个资源”，而非一个黑盒评分。

这种方法类似于“因果链回溯”，但基于资源交互而非trace span依赖，因此更真实可靠。

4. 实验设计与验证​

论文通过多个真实系统场景验证该方法，包括：

• MySQL 磁盘与锁竞争混合瓶颈；
• Redis CPU瓶颈；
• Kafka 外部服务阻塞；
• Teastore 微服务依赖延迟放大。

实验结果表明，仅靠这16个eBPF指标，就能精准还原各类瓶颈根因，诊断准确率和解释性俱佳。且 instrumentation 开销极低，Redis 平均增加仅 0.3ms。

5. 总结与价值​

该论文的几个关键贡献与我们坚持的方向高度一致：

• 以线程为单位，而非进程或服务；
• 以资源交互为基础，而非指标波动为假设；
• 只追踪相关线程，避免trace噪声污染；
• 可解释性极强，每一个瓶颈都有清晰的因果链路；
• 通用性极高，适用于多语言、跨系统架构。

这使得论文不仅是我们方法论的理论背书，更是整个“新一代根因分析体系”的奠基石。

---

论文原文 https://www.arxiv.org/pdf/2505.13160

更新日志​

新增功能​

• 新增告警事件筛选功能，帮助用户更高效地定位关键信息，同时优化告警详情的描述内容，使信息表达更清晰

• 支持在告警分析中关联数据库和中间件告警，进一步提高在大量告警场景下根因分析准确性

功能优化​

• 优化左侧菜单栏样式，使鼠标移动位置匹配菜单项，提升用户体验

• 改进全量日志页面在小窗口中的显示效果，提升可读性与操作体验

• 优化日志错误分析工作流中日志的展示格式，使排查更直观
• 将主题切换和语言切换入口统一移动至右上角的“偏好设置”，界面更整洁

缺陷修复​

• 修复因有效性判断失败导致告警无法发送通知的问题
• 修复使用“数据接入”方式安装时，无法获取故障链路数据的问题
• 修复从传统服务器采集日志时，日志中缺失进程信息的问题
• 修复应用在没有被监控的情况下，会出现数据无访问权限的问题

其他​

• 新增对阿里云 ARMS 4.x 版本探针的支持

---

本次 APO v1.8.0 版本更新带来了以下新功能和问题修复：

更新日志​

新增功能​

• 主题切换功能：新增暗黑模式与明亮模式切换，用户可根据个人偏好调整界面风格，提升使用体验。

• 告警事件详情页：新增告警详情页面，展示告警从触发到恢复的状态变化过程。用户可通过告警通知一键跳转查看详情，快速理解告警上下文。

• 告警根因分析能力增强：新增对以下类型告警的自动诊断功能：应用慢延时告警、应用错误告警和资源可用性告警，系统将分析告警原因并提供可执行的优化建议，帮助用户更高效地排查问题。

功能优化​

• apo-otel-collector 稳定性优化：优化队列配置，减少内存占用，防止因内存溢出导致 Collector 异常崩溃。
• 容器运行时标签支持增强：apo-otel-collector 现已支持采集并补充基于 cri-o 容器运行时的 Pod 标签信息，提升数据维度的完整性与可观测性。

缺陷修复​

• 修复在接入中心添加数据接入时可能出现的报错问题，提升配置稳定性。
• 修复用户登录认证过期后系统可能频繁报错的问题，改善用户登录体验。

其他​

SkyWalking Java 探针支持升级：进一步完善对 SkyWalking 探针的兼容性，trace-sidecar模式支持 SkyWalking 6.1 及以上版本，trace-collector模式支持8.4及以上版本。

---

运维的挑战与责任​

在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。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 探针丢失的问题
• 修复服务概览页无法通过指标曲线图切换时间范围的问题