SigNoz vs SkyWalking：接入方式、采样和 APM 成本怎么选

已经跑着 SkyWalking 的 Java 系统，要不要因为 OpenTelemetry 越来越普及就换成 SigNoz？我的看法是，不急。原有探针覆盖了主要框架，服务指标和告警也一直在用，这些都是真实投入。新系统采用 OTel，与把老系统全部重新接一遍，是两件工作。

反过来，如果几个语言的服务已经统一接了 OTel，选后端时就会更倾向 SigNoz。它可以沿着现有 SDK 和 Collector 继续接收数据，团队不用仅为后端选型重新组织一套探针。

接入只是开始。对 APM 来说，还有一项更容易在降本时出现分歧：详细 Trace 少存以后，服务的请求数、错误率和延迟怎么计算？SigNoz 与 SkyWalking 的不同路径，在这里会给出不同结果。

作者：观测云编辑部。资料核对于 2026-10-21。依据官方文档分析，SkyWalking 固定为 11.0.0；未进行双方性能测试。

已有探针能不能继续用

SkyWalking 支持 OTLP，但 11.0.0 文档所列的路径是先转换成 Zipkin 格式，再启用 Zipkin receiver、query 及对应查询界面。原生 Agent 上报的数据则有自己的分析路径。SkyWalking 11.0.0 OTLP 接入。

这意味着，团队从原生探针改用 OTel 时，接收成功只是完成了数据入口，原来依赖的查询和指标还可能涉及另一套处理。只准备更换出口地址，实际改动就容易超出预期。正在开发的 next 文档也可能与 11.0.0 不同，部署哪个版本，就按哪个版本的行为规划。

因此，已有 SkyWalking 的团队有理由先保留成熟探针；已有 OTel 的团队有理由减少接入转换。这两种选择都来自存量资产，和“哪个技术更新”关系不大。

调用链为什么会断

HTTP 调用已经连起来，消息发进队列以后，消费者却另起一条 Trace。这时数据库里有数据，界面也能查询，工程师仍然得靠时间和业务 ID 手工拼前后两段。

延伸阅读AgentOps vs LangSmith：Agent 调试、评估和自托管怎么选→

问题通常落在消息上下文：生产端有没有注入，消费端有没有提取，相应框架的自动埋点是否覆盖这段代码。SigNoz 需要沿 OTel 的传播路径检查，SkyWalking 则要看对应语言和组件插件。混合接入时，还会增加传播格式和桥接问题。

服务命名也会影响排障。/orders/123 和 /orders/456 如果成为两个操作名，接口流量会被拆散；生产和测试共用同一个服务标识，又可能把两边流量混到一起。SigNoz 的服务图来自 Trace 中的调用关系，这些问题会直接出现在拓扑上。SigNoz 服务图。

所以，换后端能改善数据分析，却不能替应用补上没有传播的上下文。已有命名规范、插件和异步调用适配的团队，迁移成本会比新接一个演示服务高得多。这部分投入也解释了为什么成熟平台不必轻易替换。

采样以后，错误率怎么计算

假设一万个请求里有一百个错误。为了省存储，保留全部错误，再保留 10% 的成功请求。最后留下 1,090 条，其中一百条错误。按保存的样本计算，错误占比约为 9.17%，业务实际错误率却是 1%。

偏向错误的采样本来就是为了保留故障，这个策略没有错。问题在于，还能不能用采样后的数据代表全部业务。

SigNoz 的 RED 指标来自接入的 Trace。上游已经丢弃的数据不会参与这条路径的计算，偏向慢请求或错误的尾采样也会改变样本分布。因此，依赖全量业务错误率告警时，需要有相应的全量指标来源。SigNoz Trace 成本控制、尾采样说明。

SkyWalking 原生 Agent 路径的服务端采样，控制的是详细 Trace 保存。对于已经上报并进入分析的数据，服务、实例、接口和拓扑指标仍可按原来的数据计算。这一点对希望少存 Trace、又保留服务指标的团队很实用。它不包括 Agent 上游已经丢失的数据，独立的 Zipkin 接收路径也有自己的采样配置。SkyWalking 11.0.0 服务端采样。

如果团队当前的告警就依靠这套原生服务指标，迁移到另一种采样架构后还得补指标链路，省下的存储费就要扣掉新增工作。这是会改变选择的实际差异。

错误保留与完整链路

SkyWalking 可以强制保留错误和慢请求片段，但上下游未必一起留下。故障点能查到，整条请求可能仍然不完整。错误大面积出现时，实际保存比例也会高于平时设置，故障高峰的资源消耗不能只按日常 10% 估算。

延伸阅读HolmesGPT vs K8sGPT：集群巡检和故障排查，分别适合谁→

Collector 尾采样则会等更多 Span 到达，再决定是否保留，但无法恢复 SDK、上游 Collector 或网络中已经丢失的 Span。若需要基于全量数据生成服务指标，指标分支必须位于造成数据丢弃的采样之前。代价是等待和内存：同一 Trace 的 Span 要进入能够共同决策的实例，太晚到达的数据、采样实例容量和路由方式都会影响完整性。OTel 尾采样处理器。

按每秒新增 5,000 条 Trace、等待三十秒估算，稳定流量下大约有十五万条 Trace 等待决定。平均每条二十个 Span，就是约三百万个 Span 的待处理规模。这个数还不是内存大小，属性长度与运行时开销都没有加入，但足以解释为什么尾采样也需要单独配置容量。

偶发故障的上下文很重要，团队就值得为更完整的故障样本付出这部分资源；日常主要看指标、Trace 只是辅助抽查，复杂尾采样的收益可能没有那么高。

自建的费用

每秒一千个业务请求，每个请求二十个 Span，保存 10%，一天仍然有 1.728 亿个 Span。请求量不变，增加下游调用和重试，也会继续增加详细数据。

存储留存、属性大小和副本决定一部分费用。查询又是另一部分：单人查一条短链路，和多人同时追查跨服务的长链路，需要的查询资源不同。采集处理、写入、查询、备份和升级都要有人维护，不能只算 OAP 或 Collector 的几台机器。

不过，已有运维能力也不应该被忽略。SkyWalking 团队熟悉插件和 OAP，OTel 团队熟悉 SDK 和 Collector，复用哪一边的经验，都会降低新增投入。

OTel 已经统一，多语言服务持续增加，SigNoz 更符合现有接入方式。原生 SkyWalking 探针成熟、服务指标与告警使用深入，继续使用可以减少迁移投入，实际费用仍要结合工作负载与运维投入核算。当前能力开始妨碍排障，或者运行成本已经明显超出需求，替换才更容易值得。

没有专职 APM 维护人员时

如果目标是尽快让业务用上链路排障，而不是继续投入后端集群，采用观测云 SaaS，可以减少后端集群的建设与维护。服务拓扑、Span 分析、Trace 瀑布以及满足采集条件时的 Profiling 关联，已有相应功能。采用 SaaS 托管部署时，团队仍需处理上下文和命名，但不必同时承担查询、存储后端的部署与升级；私有部署需另行明确运维责任。观测云 APM、OTel 接入。

报价要换算到同一批请求。观测云企业版计费文档将包含 Trace 的压缩后写入流量、数据存储量及其他使用项分别计量，不能只按 Trace ID 数量估算；具体套餐、计量和留存仍需按适用价目核对，自建则主要承担 Span、字节和计算资源；相同留存与故障保留要求下，才看得出差价。已有稳定集群的团队，维护增量可能很低；需要业务运维临时抽人接手，这部分工时往往足以改变选择。