之前的文章介绍过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

基于 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页面汉化

Metrics 作为可观测性领域的三大支柱之一，Metrics数据采集显得尤为重要。传统的prometheus工具采集指标，需要指定路径抓取，当指标越来越多配置会显得复杂。同时prometheus只能采集指定的指标，当用户需要节点系统相关、中间件等指标还需要引进额外组件。久而久之采集指标配置难以维护。

APO 为了用户更好地一键采集各类指标，选择 Grafana-Alloy 作为APO的指标采集器，兼容OpenTelemtry生态，集成到 APO OneAgent之中，APO OneAgent负责采集所有指标，发送至APO-Server，存储至Victoria-Metrics, APO-front负责展示所有指标。当需要额外采集数据，只需配置OneAgent中Alloy数据采集源，无需更改其他组件，配置灵活，简单易懂。

APO 指标采集配置步骤

安装APO-Agent之时，已经安装自带安装了grafana-Alloy。APO启动之后 APO Server并对外提供服务，OneAgent抓取指标，然后发送到 Server，可以在APO Front中的Grafana查看数据。

当用户想要修改指标采集配置，修改 apo-grafana-alloy-config ConfigMap即可(虚机环境下修改apo配置文件config/grafana-alloy/config.alloy)

采集的配置步骤如下：

1. 配置APO-server地址
2. 配置apo-grafana-alloy-config文件
3. grafana查询指标

APO server地址配置​

首先需要配置APO Server地址，OneAgent采集指标后将数据发送到APO Server

    otelcol.receiver.prometheus "default" {
      output {
       metrics = [otelcol.exporter.otlp.default.input]
      }
    }

    otelcol.exporter.otlp "default" {
      client {
        endpoint = "<host-ip>:<port>"
        tls {
            insecure = true
            insecure_skip_verify = true
        }
      }
    }

配置说明：其中 receiver 接收 prometheus 指标，转换成 otel 格式，然后exporter导出发送至APO-Server

APO缺采集配置​

以kubernetes环境为例，通常一个集群可能存在如下指标需要采集

• node metrics 节点机器系统相关指标 （磁盘，cpu等信息）
• kubelet metrics 提供 node 和 Pod 的基本运行状态和资源使用情况
• cadvisor metrics container相关的详细资源使用和性能指标数据

机器相关指标采集​

    jsprometheus.exporter.unix "local_system" {
    }

    prometheus.scrape "scrape_metrics" {
      targets = prometheus.exporter.unix.local_system.targets
      forward_to = [otelcol.receiver.prometheus.default.receiver]
      scrape_interval = "10s"
    }

该组件会采集机器上的各种资源指标

kubernetes 指标采集​

其中 discovery.kubernetes 组件负责获取kubernetes信息, APO 这里选择获取node相关的信息

之后采集 kubelet和 cadvisor相关的指标，由于是k8s集群，还需要配置 scheme, bearer_token_file等权限相关信息

discovery.kubernetes "nodes" {
  role = "node"
}

prometheus.scrape "kubelet" {
  targets  = discovery.kubernetes.nodes.targets
  scheme   = "https"
  scrape_interval = "60s"
  bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
  tls_config {
    insecure_skip_verify = true
  }
  clustering {
    enabled = true
  }
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  job_name = "integrations/kubernetes/kubelet"
}

prometheus.scrape "cadvisor" {
  targets    = discovery.kubernetes.nodes.targets
  scheme     = "https"
  scrape_interval = "60s"
  bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
  tls_config {
    insecure_skip_verify = true
  }
  clustering {
    enabled = true
  }
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  job_name = "integrations/kubernetes/cadvisor"
  metrics_path = "/metrics/cadvisor"
}

scrape指标采集​

通常用户还会部署一些自定义的探针程序，用于自定义一些监控指标

只需指定 targets 下的 addres 用于指定采集URL, __metrics__path__自定义采集路径，默认为/metircs

prometheus.scrape "agent_metrics" {
  targets = [
    {
      __address__ = "<scrape-path-1>:<port>",
    },
    {
      __address__ = "<scrape-path-2>:<port>",
      __metrics__path__ = "/metrics/agent"
    },
    {
      __address__ = "<scrape-path-3>:<port>",
    },
    ]
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  scrape_interval = "10s"
}

如采集APO node-agent 指标​

APO node-agent 用于采集上下游网络指标和进程启动时间指标，路径为 localhost:9500/metrics

prometheus.scrape "agent_metrics" {
  targets = [
    {
      __address__ = "localhost:9408",
    }
    ]
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  scrape_interval = "10s"
}

一键采集中间件指标​

除了采集基本指标外，用户使用APO还可以根据自己的需求额外配置其他指标采集。

如采集各类 中间件指标 （kafka, redis, mysql, elasticsearch等）

监控 MySQL​

1.OneAgent 的 alloy 配置文件添加如下内容，然后重启 OneAgent

# 采集 mysql指标
prometheus.exporter.mysql "example" {
  data_source_name  = "username:password@(<mysql-url>:3306)/"
  enable_collectors = ["heartbeat", "mysql.user"]
}

prometheus.scrape "mysql" {
  targets    = prometheus.exporter.mysql.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 中导入 MySQL 模版

3.验证是否有MySQL指标数据

监控 ElasticSearch​

1.OneAgent 的 alloy 配置文件添加如下内容，然后重启 OneAgent

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
  address = "http://<elasticsearch-url>:9200"
  basic_auth {
    username = USERNAME
    password = PASSWORD
  }
}

prometheus.scrape "elasticsearch" {
  targets    = prometheus.exporter.elasticsearch.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 中导入 ElasticSearch 模版

3.验证是否有ElasticSearch指标数据

监控 Redis​

1.OneAgent 的 alloy 配置文件添加如下内容，重启OneAgent

# 采集 redis 指标
prometheus.exporter.redis "example" {
  address = "<redis-url>:6379"
}

prometheus.scrape "redis" {
  targets    = prometheus.exporter.redis.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 导入 Redis 模版

3.验证是否有 Redis 指标数据

监控 Kafka​

1.OneAgent 的 alloy 配置文件添加如下内容，重启OneAgent

# 采集 kafka 指标
prometheus.exporter.kafka "example" {
  address = "<kafka-url>:9092"
}

prometheus.scrape "kafka" {
  targets    = prometheus.exporter.kafka.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

2.APO Front 的 Grafana 导入 Kafka 模版

3.验证是否有Kafka 指标数据

更多指标的采集可以参考Grafana-Alloy的官方文档或者咨询我们

Alloy已经支持如下中间件指标采集：

参考资料

otel-collector​

otlp-configgrpc

victora-metrics​

Sending data via OpenTelemetry

alloy​

discovery.kubernetes

otel.receiver.prometheus

prometheus

样例配置文件

logging {
  level  = "info"
  format = "logfmt"
}


otelcol.receiver.prometheus "default" {
  output {
   metrics = [otelcol.processor.transform.default.input]
  }
}

otelcol.processor.transform "default" {
  error_mode = "ignore"
  trace_statements {
    context = "resource"
    statements = [
     `replace_all_patterns(attributes, "key", "service\\.instance\\.id", "service_instance_id")`,
     `replace_all_patterns(attributes, "key", "service\\.name", "service_name")`,
     `replace_all_patterns(attributes, "key", "net\\.host\\.name", "net_host_name")`,
    ]
  }
  output {
    metrics = [otelcol.exporter.otlp.default.input]
  }
}

otelcol.exporter.otlp "default" {
  client {
    endpoint = "<host-ip>:<port>"
    tls {
        insecure = true
        insecure_skip_verify = true
    }
  }
}

prometheus.exporter.unix "local_system" {
}

prometheus.scrape "scrape_metrics" {
  targets = prometheus.exporter.unix.local_system.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  scrape_interval = "10s"
}

prometheus.scrape "agent_metrics" {
  targets = [
    {
      __address__ = "<scrape-path-1>",
    },
    {
      __address__ = "<scrape-path-2>",
    },
    {
      __address__ = "<scrape-path-3>",
    },
    ]
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  scrape_interval = "10s"
}

discovery.kubernetes "nodes" {
  role = "node"
}

prometheus.scrape "kubelet" {
  targets  = discovery.kubernetes.nodes.targets
  scheme   = "https"
  scrape_interval = "60s"
  bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
  tls_config {
    insecure_skip_verify = true
  }
  clustering {
    enabled = true
  }
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  job_name = "integrations/kubernetes/kubelet"
}

prometheus.scrape "cadvisor" {
  targets    = discovery.kubernetes.nodes.targets
  scheme     = "https"
  scrape_interval = "60s"
  bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
  tls_config {
    insecure_skip_verify = true
  }
  clustering {
    enabled = true
  }
  forward_to = [otelcol.receiver.prometheus.default.receiver]
  job_name = "integrations/kubernetes/cadvisor"
  metrics_path = "/metrics/cadvisor"
}


# 采集 mysql指标
prometheus.exporter.mysql "example" {
  data_source_name  = "username:password@(<mysql-url>:3306)/"
  enable_collectors = ["heartbeat", "mysql.user"]
}

// Configure a prometheus.scrape component to send metrics to.
prometheus.scrape "mysql_metrics" {
  targets    = prometheus.exporter.mysql.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
  address = "http://<elasticsearch-url>:9200"
  basic_auth {
    username = USERNAME
    password = PASSWORD
  }
}

prometheus.scrape "demo" {
  targets    = prometheus.exporter.elasticsearch.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

Skywalking作为国内用户量最大的APM产品，有着众多的优点。Signoz作为OpenTelemetry的发行版也有着一定的名气。我们为什么还要设计APO项目？谨代表APO团队探讨下团队之前的经验，一家之言，欢迎各位大佬一起探讨。

APO团队背景​

APO团队最先着力的产品是一款商业化的根因推理引擎产品Originx。该产品目标就是对接Skywalking和OpenTelemetry的探针数据，在SLO违约的时候，快速从原始数据之上分析得到故障根因分析报告。

实现根因分析的前提——完备的关联数据​

如果业务入口的延时升高或者错误率升高，对于下游依赖众多的服务调用而言，如何判断哪个接口是最可能的“凶犯”呢？我们认为应该要先对每个微服务接口的关联所有故障可能相关的数据。具体根因分析算法和规则就不在这篇文章讨论了。

三者在产品设计思路不同​

在APO团队看来，从设计思路来看Skywalking和Signoz是同类型的产品，都是以应用和Trace为核心呈现数据。但是APO团队认为可观测性平台不应该是以应用和Trace为核心呈现数据，而应该是以接口为维度呈现数据，因为以接口呈现数据，就可以关联上个章节提到的所有数据。

在应用中去关联上述的数据准确度会有大降低，比如一个应用提供两个接口，两个接口执行延时偏差较大，一旦以应用维度统计黄金指标数据（错误率、延时、吞吐量），就可能将故障隐藏其中。 从Trace出发呈现问题也是Skywalking和Signoz等产品的一个核心功能，在APO中这块通过集成Jaeger的方式来实现的。

最近有些朋友交流他们在自己实现可观测性平台的时候，也想以接口来关联数据，但是感觉计算量太大，资源消耗太大。APO能够实现该功能，主要基于回溯采样，分析的都是回溯采样中的数据，所以计算量是能承受的。

三者在数据采集上的不同​

在具体实现上还有以下的不同：

Skywalking

• log由Skywalking agent自采
• metrics由Skywalking agent自采
• Trace由Skywalking agent自采

Signoz

• log由Signoz openTelemetry collector采集
• merics由Signoz openTelemetry collector采集
• Trace由OpenTelemetry agent采集

APO

• log由ilogtail采集
• metrics由Alloy采集
• Trace由OpenTelemetry agent采集，同时也支持Skywalking agent采集

（建议此表格横屏阅读，内容展示更全面）

APO中需要关联eBPF数据和Trace的数据，Skywalking协议由于缺少ContainerID，导致关联出现以下的问题：

• eBPF数据来源于主机，能够获取到主机层面的PID和ContainerID信息
• 容器中Skywalking协议只有PID等信息，而容器环境的PID并不是主机层面的PID，导致两者关联起来非常不方便，需要额外做开发完成

三者在数据分析处理上的不同​

APO和Signoz的数据分析处理都有各自的OTEL collector发行版，Skywalking主要基于OAP实现数据的分析与处理。

OpenTelemetry 的Collector非常开放，预设了各种插件

• processor
• receiver
• Exporter

通过各种插件的组合能够很快组合成需要满足自己的数据分析处理流程，自动定义开发比较方便。

Skywalking的OAP相对而言比较封闭，没有这套插件体系导致自定义数据分析处理流程相对而言比较困难。所以现在很多公司的Skywalking的使用场景都需要自己构建flink完成数据的分析处理。

三者在数据存储的逻辑不同​

Skywalking的Trace是完全插入存储之后，再计算RED值。

Signoz的RED指标在中心侧Collector计算完成，Trace是尾采样存储。

APO的RED指标在探针侧Collector计算完成。Trace是全量存储，处理不过来就丢弃，但是分析的是回溯采样中的逻辑Trace，回溯采样中的逻辑Trace优先级最高，保证存储。

（建议此表格横屏阅读，内容展示更全面）

可观测性领域中的指标一直都占有非常重要的地位。Prometheus生态目前已经是事实上的标准，但是实际用户在落地Prometheus的时候可能存在以下的问题：

• 虽然生态中有各种成熟的Exporter，但是各种Exporter的安装配置相对而言比较繁琐，管理比较麻烦
• 跨集群的指标数据汇聚相对而言比较麻烦，很多时候需要二次开发，没有简单配置即可工作的工具
• Prometheus 原生数据存储在大数据量时不稳定，业界有着很好的类似VictorioMetrics方案，但是很多人还未尝试使用
• 业界也存在过万好评的大屏，能够更好体现指标价值，对于很多用户而言可能并不了解

在APO中能够很好的解决以上的问题，已经将指标生态的各种产品进行很好的整合。

Grafana Alloy介绍​

Alloy是Grafana 发布替代之前Grafana Agent的开源产品。

简单的官方介绍：

“Grafana Alloy 是一个开源的 OpenTelemetry Collector 发行版，内置 Prometheus 管道，并支持度量、日志、追踪和性能剖析。”

更为详细的官方介绍：

“Alloy 为 OTel、Prometheus、Pyroscope、Loki 以及许多其他指标、日志、追踪和分析工具提供了原生管道。此外，您可以使用 Alloy 管道执行各种任务，例如在 Loki 和 Mimir 中配置警报规则。Alloy 完全兼容 OTel Collector、Prometheus Agent 和 Promtail。您可以将 Alloy 作为这些解决方案的替代方案，或将其与多个收集器和代理结合成混合系统。您可以在 IT 基础设施的任何地方部署 Alloy，并将其与 Grafana LGTM 堆栈、Grafana Cloud 的遥测后端或任何其他供应商的兼容后端配对。Alloy 灵活多变，您可以轻松配置以满足本地部署、仅云部署或两者结合的需求。”

APO是如何使用Grafana Alloy​

从Grafana Alloy的官方介绍中可以看出Alloy很强大，但APO并未使用Alloy所有的功能，主要使用以下两个功能：

• 集成管理各种Prometheus的exporter的功能，有兴趣的朋友可以翻之前文章介绍了如何使用Alloy一键配置完成exporter的指标采集
• 管道功能：跨云，跨集群，跨网段的指标采集之后要传输到统一可观测性后台展示

集成管理Prometheus各种exporter功能​

通过简单配置即可完成exporter的配置、安装部署：比如通过以下的配置，即可实现ElasticSearch 的exporter的部署和采集

# 采集 elasticsearch指标
prometheus.exporter.elasticsearch "example" {
  address = "http://<elasticsearch-url>:9200"
  basic_auth {
    username = USERNAME
    password = PASSWORD
  }
}

prometheus.scrape "mysql" {
  targets    = prometheus.exporter.elasticsearch.example.targets
  forward_to = [otelcol.receiver.prometheus.default.receiver]
}

数据的管道功能​

管道功能，数据可以通过OpenTelemetry的collector完成数据的跨集群、跨网络、跨云的传输。

数据流向：

Alloy（采集指标）-> Otel Collector （网络边界）->(网络边界) Otel Collector -> VictoriaMetric

管道功能核心的逻辑在于通过简单配置OTEL collector

• recievier
• exporter

配置示例：

边缘侧 Collector 配置（负责接收指标并发送到中心 Collector）：

边缘侧 Collector 将通过 OTLP 接收指标数据，并通过 OTLP 发送到中心侧 Collector。

配置示例（边缘侧 Collector）：

receivers:
  otlp:
    protocols:
      grpc:  # 支持 gRPC 和 HTTP 协议
      http:

exporters:
  otlp:
    endpoint: "http://center-collector:4317"  # 中心 Collector 的接收地址
    metrics:
      resource_to_telemetry_conversion:
        enabled: true  # 将资源级信息转换为 Telemetry 数据

service:
  pipelines:
    metrics:
      receivers: [otlp]  # 从应用接收 OTLP 格式的指标数据
      exporters: [otlp]  # 导出到中心 Collector

中心侧 Collector 配置（负责从边缘侧 Collector 接收指标并写入存储系统）：​

中心侧 Collector 将通过 OTLP 接收边缘侧 Collector 发来的指标数据，并将其导出到最终的存储后端。

配置示例（中心侧 Collector）：

yaml


Copy code
receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  prometheus:
    endpoint: "http://prometheus:9090/metrics"  # Prometheus 的接收地址
    namespace: "otel_metrics"

service:
  pipelines:
    metrics:
      receivers: [otlp]  # 从边缘侧 Collector 接收 OTLP 格式的指标数据
      exporters: [prometheus]  # 导出到 Prometheus

配置说明：

1.边缘侧 Collector：

• receivers： 使用 otlp 接收应用程序发送的指标数据，支持 gRPC 和 HTTP 协议。
• exporters： 使用 otlp 导出数据，endpoint 是中心侧 Collector 的接收地址。

2.中心侧 Collector：

• receivers: 使用 otlp 从边缘侧 Collector 接收指标数据。
• xporters： 使用 prometheus 将数据导出到VictorioMetrics。

APO如何看待Alloy其它功能​

• Alloy集成Loki而来的日志能力，在实际使用日志场景中可能不够用，实际日志都要完成非结构化转化成结构化这一步骤，但是Loki在此方向并不擅长
• Pyroscope等Continues Profiling的数据目前在OpenTelemetry生态并未完全成熟，即便能够使用Alloy完成数据的采集，但是如何传输，存储，展示都成为问题，还有很多问题等着解决

Alloy的exporter集成能力是经过grafana agent项目能力沉淀而来，坑相对而言比较少。APO在实际使用Alloy也踩了些坑，通过不断调整配置，相信未来也会越来越稳定。

VictorioMetrics的使用​

VM已经成为很多公司存储指标的首选，主要是相比prometheus其它生态产品而言

架构简洁性：​

• VictoriaMetrics： VictoriaMetrics 集群版的架构较为简单，支持单一二进制文件启动，减少了复杂的集群管理工作。它既可以用作单机部署，也可以扩展为分布式集群，支持水平扩展，且维护相对简单。

• Thanos/Cortex： 这两者的架构相对复杂，通常需要多个组件（如 Querier、Store Gateway、Compactor 等）协同工作，且往往涉及到对象存储（如 S3、GCS 等）来进行长期存储。因此，它们的配置、部署和维护难度较高，适合需要长时间数据保留的大规模集群。

高效存储和压缩：​

• VictoriaMetrics： 其高效的数据压缩和存储引擎使其在处理大量数据时更加节省存储空间。它采用自定义的存储格式和时间序列压缩算法，特别擅长处理大规模高频率的时间序列数据。

• Thanos/Cortex： 这两者依赖于 Prometheus 的存储块和外部对象存储来处理长时间的数据保留，并通过外部系统进行压缩。虽然通过对象存储解决了长期存储问题，但这种方式带来的延迟和复杂性较高，尤其是在查询大量历史数据时，可能会受到网络和存储系统性能的影响。

性能和查询速度：​

• VictoriaMetrics： 由于其优化的存储引擎和索引机制，VictoriaMetrics 在长时间范围的查询场景中通常表现更好。它可以处理大规模数据的高性能写入和快速查询，即使在单节点场景下也能保持良好的表现。

• Thanos/Cortex： 这两者的查询性能取决于集群的规模和外部存储的读写性能，尤其在跨多个 Prometheus 实例进行查询时，由于依赖对象存储，查询速度相对较慢。此外，Cortex 使用分区和多租户设计，虽然增强了灵活性，但在某些场景下也会引入查询延迟。

完全兼容 Prometheus API：​

VictoriaMetrics 完全兼容 Prometheus 的查询语言（PromQL）和数据采集接口，能够无缝替代 Prometheus，且支持从 Prometheus、Thanos、InfluxDB 等系统中直接导入数据，迁移成本低。

指标的统一展示​

当各种prometheus exporter的数据存储在VictorioMetrics之中，可以利用生态已有的Grafana大屏直接展示，感谢StarsLiao的贡献，在其贡献的大屏中，有很多已经成为众多公司的选择，很多大屏有着上万的好评。APO中很多大屏都引入了大佬的作品。

总结​

APO利用Prometheus和OpenTelemetry的成熟生态成果，快速完成指标的采集、传输和统一展示。虽然这些能力并不是APO的核心价值，但也是可观测性平台的核心支柱能力，也欢迎用户先将APO当成指标的采集、传输和统一展示的工具，当系统越来越复杂，需要集成Trace、日志等能力之时，用户可以不用迁移平台。

APO介绍：

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

apo.kindlingx.com

https://github.com/CloudDetail/apo