排查提效 50%：淘大集新核心系统的观测护航之路

客户证言：“淘大集作为农产品供应链平台，订单并发高、交易链路长。选型 ARMS+SLS+STAROps 作为观测底座，我们在上线前即精准消除微服务性能瓶颈；上线后作为常态化运维平台，应用链路与应用日志原生联动，全链路诊断效率提升 50%。这套体系已成为保障每日海量农产品流通的核心运维底座。” —— 张强丨湖北淘大集技术负责人

背景

Cloud Native

对一支正在把新核心系统搬上云的技术团队来说，最难的往往不是“能不能跑起来”，而是一道绕不开的选择题：过去为了可观测性自己搭的那套开源方案，是继续背着走、还是趁上云一次性换成托管的？继续自建，意味着集群维护、索引调优、稳定性兜底、版本升级全压在自己身上，随业务增长这笔负担只会越来越重；换托管，又要担心迁移是否平滑、原有埋点和排查习惯能否延续、海量链路数据的写入与查询扛不扛得住高并发。这不是一个简单的技术采购决定，而是关乎团队未来几年把精力放在“维护观测系统”还是“打磨业务系统”上的路线抉择。淘大集在新核心系统上线这个节点上，正面撞上了这道“自建还是采用”的选择题。

湖北淘大集供应链有限责任公司深耕供应链数字化服务领域，面向生鲜全产业链市场需求，为各环节参与者提供商品交易、生鲜集采、专业化仓储物流、流通加工等服务，业务涵盖仓储管理、物流配送及多级分销网络。公司构建 B2B 农产品交易平台“优大集”，为餐饮企业及农产品经营者提供线上交易、生鲜与标品配送服务，提升供应链效率并降低食材采购成本。生鲜供应链是个对时效和稳定性极其敏感的行业——一笔订单从下单、分拣、出库到配送，链路上任何一环的系统卡顿或数据不同步，都可能直接转化为发货延迟、库存错配，进而影响下游餐饮企业的正常经营。这意味着承载海量农产品流通的核心系统，其稳定性不是“锦上添花”的技术指标，而是直接关系到履约能力的业务生命线。

随着业务规模快速扩张，系统架构日益复杂、微服务数量激增，淘大集启动了新核心业务系统的改造：整套系统采用微服务架构，服务节点多、调用链路深、上线期并发预期高，“边改造、边保障上线”成为技术团队必须同时扛住的双重压力。而在新系统改造初期可观测选型时，淘大集为保障可观测性，计划采用的是“自建 SkyWalking + Elasticsearch（ES）”的传统开源方案——这套方案在系统规模较小、数据量有限时足够好用，团队也积累了成熟的埋点与排查习惯。但当新系统把 Trace、Metric、Log 三类观测数据的体量推上一个新台阶，自建方案在稳定性、维护成本与智能化分析能力上的瓶颈开始集中显现。

业务挑战

Cloud Native

伴随新核心系统上线与微服务规模扩张，Trace、Metric、Log 三类观测数据呈指数级增长，自建观测体系的维护压力与诊断效率被同时拉升到一个新量级。技术团队在上线前后集中面对三重结构性难题，每一重都不是靠“多加几台机器”就能化解的。

▍自建集群维护重、稳定性风险凸显

自建 SkyWalking + ES 方案在数据量小时尚可支撑，但随着新系统调用链路加深、单次请求穿透的服务节点越来越多，Trace 数据量呈指数级增长，团队要持续投入 ES 索引优化、分片与副本调整、JVM 参数调优、组件版本升级等大量底层维护工作。这些工作既琐碎又专业门槛高，且没有尽头——数据涨一波，就要重新调一轮。更要命的是高并发写入下的稳定性：大促或业务高峰时段，海量 Trace 与日志集中写入，ES 集群的存储与查询能力随时可能触顶，一旦集群抖动或写入积压，观测数据本身就可能丢失、查询超时。这意味着最需要观测系统稳定工作的高峰时刻，恰恰是它最容易掉链子的时候。而这些维护与救火工作大量占用了本应用于业务创新的核心研发资源，团队陷入“为观测系统打工”的窘境，难以聚焦系统本身的架构优化与功能迭代。

▍数据孤岛严重、全链路诊断耗时费力

Trace、Metric、Log 三类数据分散存储在互不相通的系统中，彼此缺乏统一的关联键，这是自建方案最致命的短板。新系统上线压测阶段，某个核心交易接口响应明显变慢，研发人员的排查路径是这样的：先在监控侧盯着指标曲线判断是哪段时间、哪个服务出的问题，再切到日志平台按时间和关键字大海捞针地翻找对应记录，还要回到链路系统去定位具体卡在哪一跳调用上。三套系统、三种界面、三套查询语法，一次完整的故障上下文全靠人脑和手动比对时间戳、拼接 TraceID 与日志片段来还原。由于无法实现“指标—日志—链路”的一键下钻，排查过程大量消耗在跨系统的机械比对上，一次根因定位平均耗时超过 30 分钟。对追求分钟级响应的供应链业务来说，这 30 分钟可能就是发货延迟与准时履约之间的差距。

▍告警噪音泛滥、上线保障难以沉淀为长期能力

自建方案依赖静态阈值告警，规则一旦设死就难以适应业务的动态波动。在大促高峰或网络瞬时抖动时，一个底层节点的异常往往会沿着调用链向上层层传导，触发一连串关联服务的阈值告警，瞬间形成连锁告警风暴。运维人员被大量重复、无效、互相掩盖的告警淹没，真正的根因反而被噪声遮蔽。由于缺乏拓扑感知与 AI 辅助分析能力，团队难以从海量告警中快速识别出“哪一条才是源头”，只能靠经验逐条排查。比这更长远的问题是：新系统平稳上线只是起点，上线期临时拉起来的那套排查手段和人力盯守，一旦项目结束就会散场，日常运维又会退回被动响应、人工救火的老路。团队真正需要的，是把上线攻坚期验证有效的观测与诊断能力固化成可持续使用的日常运维手段，而不是又一次“上线时突击、上线后就荒废”。

淘大集需要的不是继续在自建集群上加机器、调参数、堆人力，而是一套能平滑接管原有观测能力、把链路指标日志真正打通、还能叠加 AI 智能诊断的云原生托管底座——既能立刻缓解上线期的稳定性与效率压力，又能长期沉淀为团队的运维资产。

解决方案：以云原生托管观测替代自建，

构建可长期沉淀的智能运维底座

Cloud Native

淘大集技术团队在系统对比自建 SkyWalking 与阿里云 ARMS+SLS 两条路线后，最终选择 ARMS+SLS+云监控 2.0+STAROps 作为统一观测底座。这个决策背后有两层考量：一是托管服务免运维、平滑迁移的落地成本优势，能把团队从 ES 集群的维护泥潭中解放出来；二是链路、指标、日志三者在云原生底座上原生打通，并能向上叠加 UModel 拓扑建模与 STAROps 的 AI 智能诊断，形成从“看得清”到“诊得准”的完整能力闭环。整套体系围绕“平滑迁移—统一视图—拓扑可视—智能诊断”四层展开，把自建时代割裂、被动、靠人肉的观测模式，收敛为一个托管、联动、智能化的云原生底座。

▍（一）免运维托管 · 平滑迁移上云：ARMS 替代自建 SkyWalking+ES

这一层直接回应“自建集群维护重、稳定性风险高”的挑战。ARMS 应用监控通过 OpenTelemetry 标准协议与 Java Agent 探针无侵入接入新系统各微服务——探针以字节码增强方式在应用启动时自动织入，无需改造一行业务代码即可自动采集调用链、方法耗时与异常堆栈。这一点对淘大集尤为关键：团队原有基于 SkyWalking 的埋点习惯与链路视图得以平滑延续，OpenTelemetry 作为开放标准的兼容性让迁移过程几乎零业务侵入，避免了“换观测方案要重写埋点”的高昂代价。针对微服务架构中大量存在的异步调用、线程池切换与消息队列场景，ARMS 的全链路追踪具备异步上下文透传能力，保证 TraceId 在跨线程、跨服务、跨中间件的复杂调用中不断链，还原出完整的请求路径。更关键的是，ARMS 提供托管式高性能存储与查询引擎，彻底免除了自建 ES 集群的索引优化、分片调整、JVM 调优与稳定性兜底负担，由云平台保障高并发下海量 Trace 数据的秒级写入与查询稳定。团队从此不必再为观测集群的扩容和救火操心，可以把核心研发资源重新投回业务系统的架构优化与新功能迭代。

▍（二）云监控 2.0 统一视图 · 打破数据孤岛：串起指标、日志与链路

这一层解决“数据孤岛、全链路诊断耗时”的痛点，是整套方案里最能直接提升排查效率的一环。淘大集将分散的业务日志统一采集到 SLS 日志服务，并在日志中埋入与调用链一致的 TraceID 作为关联键；云监控 2.0 则把指标、日志、链路三类多维观测数据在同一个平台上统一存储与分析，形成“一处查看、全局分析”的可观测数据闭环，从根本上消除了自建时代三套系统各自为政的割裂。借助这个贯穿全链路的 TraceID，ARMS 的调用链与 SLS 的业务日志被原生打通：研发人员在链路拓扑上发现某个异常 Span 后，可直接从该节点一键跳转到对应时间点、对应请求的业务日志上下文，反之亦可从一条错误日志反查它所在的完整调用链路，无需再手动切换平台、逐条比对时间戳。过去要在三套系统间来回拼接、平均超过 30 分钟才能还原的故障上下文，现在沿一个 TraceID 就能把“链路视图 + 指标曲线 + 日志详情”在同一线索下自动拼合，排查路径从“人脑拼图”变成“系统联动”。

▍（三）UModel 动态拓扑 · 链路可视透明：让复杂依赖一目了然

这一层承接“链路复杂、瓶颈难定位”的挑战，并为长期运维沉淀打下可视化基础。基于 UModel 技术，观测底座自动为业务系统建模，构建应用内接口调用与应用外云资源依赖的全链路拓扑关系图——前端 → 后端 → 中间件 → 数据库 → 容器一张图完整呈现，无需人工绘制和维护架构图。更难得的是它的动态实时性：应用发布、依赖关系变化、容器扩缩容后，拓扑图会自动刷新，始终反映系统的真实运行结构。对淘大集这样微服务数量激增、供应链业务链路层层嵌套的系统而言，人工维护的静态架构图往往滞后于实际部署，而 UModel 让复杂的服务依赖与实时健康状态一目了然，拓扑从一张过时的静态图变成带实时数据的“活地图”。点开拓扑上的任一节点，即可查看该节点关联的指标、链路与日志观测数据，为上线前的容量评估、瓶颈预判，以及上线后的日常巡检、影响面分析提供了一个统一的可视化入口。

▍（四）STAROps 智能诊断 · 分钟级根因定位：让 AI 承接全链路排查

作为贯穿全链路的横切能力，STAROps 智能运维助手在云监控 2.0 的观测数据之上叠加 AI 能力，对 Metric、Log、Trace、Event 四类数据进行统一关联分析，把原本需要人工在多个维度间来回印证的工作交给算法完成。当业务系统出现异常时，STAROps 可自动结合 UModel 拓扑进行根因推导——沿着拓扑的依赖关系反向定位，判断异常究竟源自哪个节点、又如何沿调用链向上传导，从而在告警风暴中直接指出源头，而非让人从一堆关联告警里猜。它还能围绕目标应用自动检索多维观测数据、执行全链路 AI 根因分析，并通过主动巡检在故障发生前提前发现潜在风险，把运维姿态从“事后被动响应”推向“事前主动预防”。针对自建时代静态阈值告警噪音泛滥的问题，STAROps 的告警降噪与拓扑感知能力帮助团队从海量重复告警中快速锁定真实根因。团队由此从“人工翻链路、逐层排查”升级为“AI 先给出根因线索、人再复核确认”，让观测底座不止能看、还能自己会想，也把上线期的攻坚经验真正沉淀为可持续复用的日常运维能力。

实现价值：

从被动救火到 AI 主动运维的能力跃迁

Cloud Native

▍（一）上线前调优：核心接口性能显著提升

过去，面对层层嵌套的微服务链路与割裂在多个系统里的观测数据，团队只能靠表层指标的波动和经验猜测来排查瓶颈，一次慢接口定位往往要跨多个服务反复试探，既慢又容易漏判。

现在，借助 ARMS 全链路追踪沿 TraceID 一路下钻到具体方法的代码行与慢 SQL 语句，性能瓶颈无所遁形。淘大集在上线前即精准消除了核心交易链路上的性能瓶颈——核心接口平均响应时间降低约 40%，支撑新系统在高并发场景下平稳上线，把性能问题挡在了正式对外服务之前，而非等到线上暴露再补救。

▍（二）故障定位提速：从超 30 分钟到分钟级

过去，指标、日志、链路两套体系，一次故障的完整上下文全靠人工拼接 TraceID 与比对时间戳来还原，根因定位平均耗时超过 30 分钟，运维长期陷于被动救火。

现在，云监控 2.0 统一视图让三类数据一处可查，应用链路与应用日志经 TraceID 原生联动，异常链路一键跳转对应日志，再叠加 STAROps 结合拓扑的 AI 根因推导，故障平均定位时间从小时级缩短至分钟级，整体排查效率提升约 50%，MTTR 大幅缩短。对生鲜供应链这样时效敏感的业务而言，更快的定位直接转化为更少的发货延迟与库存不同步，保障了上下游的高效协同。

▍（三）降本增效：观测底座沉淀为长期运维资产

过去，自建 SkyWalking+ES 集群的硬件投入、无休止的索引调优与稳定性兜底持续占用核心研发资源，上线期临时搭建的排查手段又随项目结束而散场，重复投入难以沉淀为团队资产。

现在，托管底座彻底免除了自建集群的维护负担，团队不再需要为观测系统的扩容和救火投入专职人力；指标、链路与日志在云监控 2.0 上持续联动，上线前调优积累的性能基线、告警规则与容量评估机制固化为日常运维能力，叠加 STAROps 的 AI 根因分析与主动巡检，团队实现了从被动监控到 AI 主动运维的转型。研发与运维效率同步提升，IT 基础设施与人力运维综合成本降低约三成，更重要的是，观测能力第一次成为一份可持续复用、随业务成长的长期资产，而非一次性投入。

未来展望：

从上线护航走向全业务线的智能运维

Cloud Native

新核心系统的这次上线护航，以及从自建 SkyWalking 到云原生托管观测的完整迁移，验证了 ARMS+SLS+云监控 2.0+STAROps 作为观测底座的能力闭环。基于已经跑通的平滑迁移、链路日志联动与 AI 根因分析，淘大集与阿里云的合作还将沿三个方向继续深化，把这套底座的价值从“一个系统的上线保障”放大到“整个平台的运维升级”。

▍（一）从“单系统上线”走向“全业务线覆盖”

当前观测底座已覆盖新核心业务系统，接下来将同一套托管观测与智能诊断能力延伸到平台更多业务线，让生鲜集采、仓储物流、流通加工、多级分销等各环节都纳入统一观测视野，形成全业务线一致的运维标准与数据口径，彻底告别过去按系统各自建观测、数据互不相通的分散模式，让整条供应链的技术健康度在同一张图上可见、可管、可控。

▍（二）从“事后定位”走向“事前预判”

在已建立的 UModel 动态拓扑、性能基线与 STAROps 主动巡检能力之上，进一步结合容量评估与趋势预测，把运维姿态从“故障发生后分钟级定位”前移到“风险显现前提前干预”。例如在大促等流量高峰到来前，基于历史基线预判哪些服务可能触顶、提前扩容或优化；在日常运行中，通过主动巡检捕捉尚未演变为故障的异常苗头，让观测底座承担更多预防性价值，把稳定性保障从被动响应升级为主动经营。

▍（三）从“技术观测”走向“业务度量”

链路、指标、日志与 AI 根因分析打通后，观测数据不应只服务于技术排障，向上支撑订单履约时效、交易成功率、库存同步准确性等业务连续性度量，让技术侧的稳定性指标与业务侧的经营结果真正对齐。当运维团队能直接看到某次系统抖动对下游发货的影响，技术决策就有了业务价值的标尺，双方也能共同把“优大集”平台的稳定性做成一项可量化、可对外承诺的业务竞争力。