Taodaji Boosts Troubleshooting Efficiency 50% with ARMS+SLS Cloud-Native Observability

Background: High-Stakes Migration for a Fresh Produce Supply Chain Platform

Hubei Taodaji Supply Chain operates the "You Daji" B2B agricultural trading platform, handling high-concurrency orders across warehousing, logistics, and multi-level distribution. System stability directly impacts fulfillment capability — any latency or data inconsistency translates into delayed shipments and inventory mismatches. As the business scaled, the architecture evolved into a complex microservices landscape with deep call chains and high concurrency expectations. The team initially planned a self-built observability stack using SkyWalking + Elasticsearch (ES), a familiar approach that worked at smaller scale.

Three Structural Challenges with Self-Built Observability

1. Cluster Maintenance Overhead and Stability Risks

As trace data grew exponentially with deeper call chains, the team faced continuous ES index optimization, shard/replica tuning, JVM parameter adjustments, and version upgrades. These tasks were both tedious and highly specialized, with no end in sight — each data surge required re-tuning. Worse, during peak traffic (e.g., promotions), massive trace and log writes could overwhelm the ES cluster, causing storage/query bottlenecks, cluster instability, or data loss — precisely when observability was most needed. This diverted core R&D resources from business innovation to "maintaining the observability system."

2. Data Silos and Slow End-to-End Diagnosis

Traces, metrics, and logs lived in three disconnected systems without a unified correlation key. During pre-launch stress testing, a core trading interface slowed down. Engineers had to: (1) check metric dashboards to identify the problematic time window and service, (2) switch to the log platform to search by timestamp and keywords, (3) return to the tracing system to pinpoint the exact slow hop. Three systems, three UIs, three query syntaxes — full context reconstruction relied on manual timestamp correlation and TraceID stitching. Average root-cause localization exceeded 30 minutes, unacceptable for a time-sensitive supply chain business.

3. Alert Noise and Lack of Sustainable Operational Capability

Static threshold alerts generated storms during peak loads or transient network blips — a single downstream anomaly propagated upstream, triggering cascading alerts across dependent services. Operators drowned in redundant, low-signal alerts, obscuring the true root cause. Without topology-aware or AI-assisted analysis, the team relied on tribal knowledge to guess the source. Moreover, the ad-hoc troubleshooting practices built for launch would dissolve post-project, reverting operations to reactive firefighting. The goal was to codify launch-proven observability and diagnosis into a permanent, reusable operational asset.

Solution: Four-Layer Cloud-Native Observability Stack

After comparing self-built SkyWalking against Alibaba Cloud's managed services, Taodaji chose ARMS + SLS + Cloud Monitor 2.0 + STAROps as a unified observability foundation. The decision hinged on two factors: (1) managed services eliminate operational burden and enable smooth migration; (2) traces, metrics, and logs are natively integrated on a cloud-native base, augmented by UModel topology modeling and STAROps AI diagnostics, forming a closed loop from "visibility" to "accurate diagnosis."

(1) Managed Tracing with Seamless Migration: ARMS Replaces Self-Built SkyWalking+ES

ARMS Application Monitoring ingests telemetry via OpenTelemetry standard protocol and Java Agent bytecode instrumentation — zero business code changes required. This preserved the team's existing SkyWalking instrumentation habits and trace views. OpenTelemetry compatibility made migration near-zero-intrusion, avoiding the high cost of rewriting instrumentation. ARMS's distributed tracing supports asynchronous context propagation across thread pools, message queues, and cross-service calls, ensuring TraceId continuity in complex async scenarios. Crucially, ARMS provides a managed high-performance storage and query engine, eliminating ES index tuning, shard management, JVM tuning, and stability guarantees. The cloud platform handles massive trace write/query at second-level latency under high concurrency, freeing the team to focus on business architecture and feature iteration.

(2) Unified View Breaking Data Silos: Cloud Monitor 2.0 Connects Metrics, Logs, and Traces

Business logs were centralized into SLS Log Service with TraceId embedded as the correlation key. Cloud Monitor 2.0 unifies storage and analysis of metrics, logs, and traces in a single platform, creating an observable data closed loop. With the end-to-end TraceId, ARMS traces and SLS logs are natively linked: from an anomalous span in the trace topology, engineers can one-click jump to the corresponding business log context at that exact timestamp, and vice versa. The previous 30+ minute manual cross-system correlation — "human puzzle assembly" — becomes automated "system linkage" along a single TraceId, merging "trace view + metric curve + log details" in one workflow.

(3) Dynamic Topology Visualization: UModel Makes Complex Dependencies Transparent

UModel automatically builds a full-stack topology: frontend → backend → middleware → database → containers — no manual diagramming needed. Critically, it updates in real time: deployments, dependency changes, container scaling all refresh the topology automatically, keeping it aligned with actual runtime structure. For Taodaji's rapidly growing, deeply nested microservices, static architecture diagrams were always outdated. UModel turns topology into a live map with real-time health status. Clicking any node reveals its associated metrics, traces, and logs, providing a unified visual entry point for pre-launch capacity planning, bottleneck anticipation, and post-launch routine inspection and blast-radius analysis.

(4) AI-Powered Diagnosis: STAROps Delivers Minute-Level Root Cause Analysis

STAROps, the intelligent operations assistant, layers AI on top of Cloud Monitor 2.0's unified data (Metric, Log, Trace, Event). It automatically correlates across dimensions, replacing manual cross-verification. On anomalies, STAROps leverages UModel topology for root-cause inference — traversing dependencies backward to identify the originating node and propagation path, cutting through alert storms to pinpoint the source. It also performs proactive patrols to detect latent risks before they become incidents, shifting posture from reactive response to proactive prevention. For the static-threshold alert noise problem, STAROps' alert deduplication and topology-awareness help teams quickly isolate true root causes. The team moved from "manual trace digging, layer-by-layer investigation" to "AI proposes root-cause clues, human validates," turning the observability base into a thinking system and cementing launch-period gains into sustainable daily operational capability.

Measurable Outcomes: From Reactive Firefighting to AI-Driven Operations

(1) Pre-Launch Optimization: Core API Performance Significantly Improved

Previously, engineers relied on surface-level metric fluctuations and guesswork to hunt bottlenecks across layered microservices and fragmented data — slow and prone to misses. Now, ARMS end-to-end tracing drills down via TraceId to specific code lines and slow SQL statements, exposing bottlenecks directly. Taodaji eliminated performance bottlenecks on core trading paths before launch — core API average response time dropped ~40% , ensuring the new system handled high concurrency stably from day one, rather than discovering issues in production.

(2) Fault Localization Acceleration: From >30 Minutes to Minute-Level

Previously, two disjointed systems meant full fault context required manual TraceID stitching and timestamp correlation — average root-cause time >30 minutes, trapping operations in passive firefighting. Now, Cloud Monitor 2.0's unified view puts all three data types in one place; ARMS traces and SLS logs are natively linked via TraceId with one-click navigation; STAROps adds topology-aware AI root-cause analysis. Average fault localization time compressed from hour-level to minute-level, overall troubleshooting efficiency improved ~50% , drastically reducing MTTR. For a fresh produce supply chain, faster diagnosis directly means fewer shipment delays and inventory mismatches, safeguarding upstream-downstream collaboration.

(3) Cost Reduction and Assetization: Observability Becomes a Long-Term Operational Asset

Previously, self-built SkyWalking+ES clusters consumed continuous hardware investment, endless index tuning, and stability firefighting, tying up core R&D headcount. Launch-period ad-hoc troubleshooting practices evaporated post-project, yielding no reusable asset. Now, the managed base eliminates cluster maintenance entirely — no dedicated staff for observability scaling or firefighting. Metrics, traces, and logs continuously interoperate on Cloud Monitor 2.0; pre-launch performance baselines, alert rules, and capacity models solidify into daily operational capabilities, amplified by STAROps AI root-cause analysis and proactive patrols. The team achieved a shift from passive monitoring to AI-driven proactive operations. IT infrastructure and operational labor costs fell ~30% . Most importantly, observability capability became a sustainable, growing long-term asset, not a one-off expenditure.

Future Outlook: Extending the Observability Flywheel

(1) From Single-System Launch to Full Business-Line Coverage

The current observability base covers the new core system. Next, the same managed observability and intelligent diagnosis will extend to more business lines — fresh procurement, warehousing/logistics, processing, multi-level distribution — establishing a unified operational standard and data dialect across the entire supply chain, ending the fragmented per-system observability model. The whole supply chain's technical health becomes visible, manageable, and controllable on a single pane.

(2) From Post-Mortem to Pre-Emptive Intervention

Building on UModel dynamic topology, performance baselines, and STAROps proactive patrols, the team will integrate capacity assessment and trend prediction to shift operations from "minute-level post-failure localization" to "pre-risk intervention." Example: before promotional peaks, forecast which services may saturate based on historical baselines and pre-scale or optimize; during routine operations, proactive patrols catch anomaly precursors before they escalate into failures, turning stability assurance from reactive response into proactive management.

(3) From Technical Observability to Business Metrics

With traces, metrics, logs, and AI root-cause analysis connected, observability data should serve beyond technical troubleshooting — upward to business continuity metrics like order fulfillment timeliness, transaction success rate, inventory sync accuracy. When ops teams can directly see a system jitter's impact on downstream shipments, technical decisions gain a business-value yardstick, enabling both sides to turn "You Daji" platform stability into a quantifiable, externally commitable competitive advantage.