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 |
|
| metrics | Alloy | Skywalking agent | Signoz openTelemetry collector |
|
| Trace | OpenTelemetry agent 或者 Skywalking agent | Skywalking agent | OpenTelemetry 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优先级最高，保证存储。
| APO | Skywalking | Signoz | 说明 | |
| Trace处理时机 | 探针侧Collector | 存储侧 | 中心侧collector |
|
| 存储中间件 | ClickHouse VictorioMetrics | ElasticSearch | ClickHouse |
|
（建议此表格横屏阅读，内容展示更全面）