NIIMBOT integrated Alibaba Cloud's STAROps and UModel via OpenAPI into its SRE platform for automated, cross-domain AIOps diagnostics.
Background
When a technically mature team has moved its entire stack to the cloud and already built a complete observability stack, the key question is no longer "can we build it?" but "what should we build ourselves, and what should we hand to the cloud?" That was the decision facing NIIMBOT. With an established in-house SRE platform, should the company keep building its own observability data foundation and operations digital twin, or adopt a more complete set of ready-made capabilities?
NIIMBOT is dedicated to making things easier to manage through innovation. Since its founding in 2012, the company has continued to advance smart label printing hardware, cloud printing service platforms, and enterprise performance management systems, making label printing smarter and easier. NIIMBOT products are now used across retail, telecommunications, office settings, industry, healthcare and laboratories, and homes, reaching more than 22 million users worldwide.
Business Challenges
As the business expanded rapidly around the world, its systems grew exponentially in scale and complexity, pushing operational complexity to a new level. NIIMBOT runs its business systems on Alibaba Cloud and had already assembled a comprehensive observability stack: Real User Monitoring (RUM) for frontend experience data, Managed Service for Prometheus for container and cloud resource metrics, Application Real-Time Monitoring Service (ARMS) for application performance tracing, and Simple Log Service (SLS) for logs. A self-managed Grafana instance connected to these cloud data sources to provide unified dashboards. Even with this extensive toolset, three structural problems remained.
(1) No Clear Global Topology: Internal Calls and External Dependencies Sat in Separate Graphs
The business systems ran in the cloud, but one question remained hard to answer: which APIs does an application call, and which cloud resources does it depend on? ARMS showed some internal API call relationships, while RDS instances, Redis instances, message queues, and other external dependencies remained scattered across their own monitoring views. The two could not be combined into a single dynamic graph. As the business grew, mapping topology by hand became increasingly inefficient — dependencies documented today could be out of date after next week's release.
(2) Multi-Dimensional Observability Data Was Complete, but Disconnected
Metrics, logs, traces, and events were all being collected. The problem was that collecting everything is not the same as connecting everything. Troubleshooting an incident meant context-switching repeatedly among metric charts, traces, logs, and change events, matching timestamps by hand, with no single thread automatically linking the different data dimensions. The data was there; people still had to piece the clues together.
(3) Alert Noise Made Cross-Domain Root Cause Analysis Take Tens of Minutes
When an incident occurred, every component across the stack — frontend, backend, middleware, database, and containers — raised alerts at once, burying the true source of the problem. Root cause analysis depended heavily on experience: engineers had to decide by instinct where to begin, and locating and analyzing a cross-domain fault routinely took tens of minutes.
These challenges raised a question specific to NIIMBOT. The team was capable of building its own SRE platform, but it also understood the cost of automatically correlating multi-dimensional observability data and maintaining a dynamic, real-time view of topology. Both required substantial investment and continuous upkeep. Was this particular wheel really worth building in-house?
Solution: A Multi-Dimensional Data Foundation, a UModel Digital Twin, and OpenAPI Integration with the In-House SRE Platform
After technical discussions with Alibaba Cloud, NIIMBOT found that the Alibaba Cloud observability system already provided the two capabilities it needed most: automatic correlation across observability data dimensions and dynamic awareness of end-to-end topology. The correlation coverage was broad, and the topology updated automatically — exactly what the team had planned to build. NIIMBOT therefore decided to stop reinventing this wheel. Alibaba Cloud would provide the observability data foundation and operations digital twin; the in-house SRE platform would call STAROps diagnostics through OpenAPI and focus on orchestration and closed-loop workflows tailored to NIIMBOT's business. The solution was implemented in four layers.
(1) A Unified Multi-Dimensional Observability Data Foundation: Bringing Four Existing Collection Capabilities onto One Data Plane
Rather than replace the RUM, Prometheus, ARMS, and SLS deployments already in use, NIIMBOT used Cloud Monitor 2.0 (CMS 2.0) to collect, store, view, and analyze metrics, logs, traces, events, and changes in one place. Frontend experience data from RUM, container and cloud resource metrics from Prometheus, application performance and traces from ARMS, and business logs from SLS now converge on the same data plane. This provides a consistent foundation for topology modeling and intelligent diagnostics. In short, the data no longer sits in separate silos; it enters a shared correlation layer with consistent definitions.
(2) The UModel Operations Digital Twin: Automatic End-to-End Topology Modeling with Real-Time Updates
This capability is the main reason NIIMBOT shifted from building to adopting. UModel models business systems automatically and constructs an end-to-end topology spanning internal API calls and external cloud resource dependencies — frontend → backend → middleware → database → containers — in a single graph. The graph updates in real time as applications are deployed, dependencies change, or workloads scale, with no manual upkeep. Clicking any node brings up its associated observability data. The topology is not a static architecture diagram but a living map backed by current data. UModel's mature correlation coverage and dynamic topology awareness spare the team the ongoing work of building and maintaining these models itself.
(3) STAROps Intelligent Diagnostics: Automatic Cross-Domain Root Cause Analysis on the UModel Topology
With a unified data foundation and the UModel topology in place, STAROps can perform root cause analysis (RCA) automatically when an incident occurs. It follows upstream and downstream relationships in UModel, finds relevant nodes, retrieves their observability data, and quickly returns investigation steps and analysis results. What once required engineers to guess where to begin and query multiple systems by hand becomes AI-driven, cross-domain correlation. In practice, STAROps performs reliably on single-domain analysis of infrastructure resources, such as resource utilization levels for a Pod or an anomalous cloud resource metric. In more complex cases — frequent garbage collection in a Pod, for example, which spans the container layer and application-level JVM metrics — STAROps can start from application monitoring, follow the topology to the JVM metrics, and pinpoint the root cause. This is the capability that turns "the data is there, but people assemble the clues" into "AI connects the data dimensions automatically."
(4) STAROps Integrates with the In-House SRE Platform: Embedding Diagnostics via OpenAPI
NIIMBOT engineers no longer need to leave their familiar SRE platform for another console when troubleshooting. Through OpenAPI, the in-house platform calls STAROps directly as a diagnostic engine and receives a live stream of its analysis and diagnostic results. With one click inside their own SRE platform, engineers can follow the STAROps reasoning process and see its conclusions in real time, completing full-domain diagnosis without leaving the platform.
This model embeds capabilities instead of replacing platforms. NIIMBOT gains the full diagnostic power of the Alibaba Cloud observability system while preserving the autonomy of an in-house SRE platform built around its own business logic. The cloud provides the foundation; the customer's platform remains the interface.
Business Value: Let the Cloud Handle the Heavy Lifting and Refocus on the Business
(1) One-Click, Closed-Loop Full-Domain Diagnosis Inside the In-House SRE Platform
Previously, troubleshooting a cross-domain fault meant switching repeatedly among ARMS, Prometheus, SLS, and Grafana. Engineers matched timestamps and assembled clues by hand, and root cause analysis routinely took tens of minutes. Now, a single click in the NIIMBOT in-house SRE platform triggers diagnosis of a business system issue. STAROps follows the UModel topology, correlates multi-dimensional observability data across domains, and returns the root cause analysis. The operations team no longer has to sift through each data dimension or hunt for clues layer by layer.
(2) No More Reinventing the Wheel: A Mature Team Puts Its Effort Back into the Business
NIIMBOT once had to commit its own engineering resources to building and maintaining general-purpose operations capabilities such as topology modeling and multi-dimensional data correlation. That costly, maintenance-intensive work is now handled by the Alibaba Cloud observability system and UModel. Freed from reinventing the wheel, the team can focus again on cloud resource management and system architecture optimization — work that contributes more directly to its business. For mature teams, deciding what to build and what to hand to the cloud is a real strategic choice; NIIMBOT has made its own.
(3) Operations Evolves from Reactive Firefighting to Proactive Management
The operations team once spent its days waiting for alerts, chasing faults, and conducting post-incident reviews. With UModel's dynamically updated end-to-end topology and AI-driven analysis of multi-dimensional observability data, the team has moved from reactive response to proactive inspection and earlier problem detection. While keeping business systems stable, its role has evolved from incident responder to steward of system health, completing its transition to an AIOps operating model.
Looking Ahead: From Diagnostics That Work to Diagnostics That Know NIIMBOT Better
As STAROps becomes embedded in the in-house SRE platform, more core business systems will gain end-to-end topology modeling and intelligent diagnostics, extending the living map and one-click cross-domain diagnosis across the entire business. Each new system onboarded strengthens the AIOps capability of the NIIMBOT in-house SRE platform: wherever the business expands, AIOps coverage follows.
(1) From Trace-Guided Correlation to Automatic Analysis from Any Entry Point
STAROps already pinpoints root causes by correlating across domains along the UModel topology. The next step is to make the result independent of where an investigation begins. Whether an engineer starts from application monitoring or from an infrastructure resource such as a Pod or container, the system should extend upstream and downstream automatically and connect every observability data dimension. The goal is more seamless, intelligent cross-domain correlation, with root cause analysis that no longer depends on choosing the right entry point.
(2) Making the Embedded OpenAPI Integration Smoother
Streaming the diagnostic process back to the in-house SRE platform through OpenAPI is central to this integration. Guided by NIIMBOT's feedback from day-to-day use, the two sides will continue improving the responsiveness and completeness of the stream, making the analysis shown inside the platform more detailed and coherent — and turning embedded capabilities into a genuinely seamless experience.
Top comments (0)