APO与SkyWalking、Signoz等产品的不同设计

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

APO团队背景：

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

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

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

接口关联数据	故障场景
接口自身的告警信息，应用层、资源层告警	告警分析
接口的影响业务入口黄金指标	影响面分析
接口的下游依赖告警关联	级联告警影响分析
接口的实例和节点的资源指标	饱和度分析
接口的网络指标	网络质量分析
接口的代码Exception，以及含有Exception的日志	错误闭环
接口执行的北极星指标	延时闭环
接口执行的日志	故障佐证
接口执行的trace	故障佐证
接口所依赖的容器环境关键事件	环境影响

三者在产品设计思路不同

在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采集
• metrics由Signoz openTelemetry collector采集
• Trace由OpenTelemetry agent采集

APO

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

	APO	Skywalking	Signoz	说明
log	ilogtail	Skywalking agent	Signoz openTelemetry collector	Skywalking agent采集日志性能开销可能不如单独的探针 OpenTelemetry Collecotor采集日志是一个不错的选择 ilogtail采集日志不仅仅适合容器环境，同时还可以支持虚拟机等其他环境
metrics	Alloy	Skywalking agent	Signoz openTelemetry collector	Skywalking agent采集的指标很多应用层指标，需要额外的指标采集工具覆盖主机、容器的指标 Signoz OpenTelemetry Collector能够采集主机指标，但是目前支持采集的种类的指标有限 Alloy是一款内置多种Prometheus exeporter的产品。基于Alloy采集指标，非常容易扩展采集各种中间件等指标，满足更多用户的需求
Trace	OpenTelemetry agent 或者 Skywalking agent	Skywalking agent	OpenTelemetry agent	由于Skywalking的协议缺少一些关键ID，比如ContainerID等信息，在容器环境，要关联各种指标和日志带来一些问题。 OpenTelemetry的OLTP协议中含有ContainerID，关联起来各种数据更加方便

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

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优先级最高，保证存储。

	APO	Skywalking	Signoz	说明
Trace处理时机	探针侧Collector	存储侧	中心侧collector	Skywalking 对存储中间件的计算资源和存储资源要求高，计算都在存储侧计算 Signoz在中心侧collector计算RED指标并执行尾采样，当TPS流量很大之时，尾采样的限制导致其很难支持大流量的Trace计算 APO在探针边缘侧计算RED，计算量分散，能更好支持大流量的场景。采用回溯采样，优先保障回溯采样中的逻辑Trace存储，全量Trace如果超出缓存扔掉
存储中间件	ClickHouse VictorioMetrics	ElasticSearch	ClickHouse	Skywalking 采用ElasticSearch 需要比较多的机器成本 Signoz 的指标是存储在ClickHouse中，一些现成的PQL查询指标语句用不了 APO的指标存储在VM中，兼容PQL语句，很多已经基于Prometheus的大屏可以直接使用，指标压缩比也更高

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