Cloud observability is becoming harder because cloud systems are no longer static. Microservices, dynamic topology, cross-team dependencies, and rapidly growing telemetry volume all make traditional operations less predictable. Intelligent technologies, including large models, can help process large-scale observability data and accelerate incident discovery and resolution.
At the Cloud AI Compute Ignite Forum of the Global Digital Economy Conference, the Cloud Computing Intelligent Observability Capability Maturity Model standard was officially released. The standard is led by the China Academy of Information and Communications Technology, initiated by China Mobile Cloud, and approved by the CCSA TC1 WG5 cloud computing working group.
This launch defines the overall development direction for cloud operations. Intelligent observability is positioned as a complete capability model, rather than merely a set of tools.
What the standard tries to define
The standard defines key concepts, assessment dimensions, capability levels, and implementation paths for intelligent observability in cloud environments. Its goal is to guide organizations that want to apply intelligent methods to improve cloud-system observability.
The standard covers two major areas:
| Area | Scope |
|---|---|
| Observability capability | Platform planning, resource design, correlation analysis, data standardization, alert-effectiveness design, data security, observed-object design, metric and threshold design, process design, daily operations, visualization, data validation, and data management. |
| Intelligent capability | Intelligent data analysis, log analysis, intelligent alert baseline, alert convergence, anomaly detection, trend prediction, root-cause analysis, intelligent optimization suggestions, natural-language interaction, tool calling, memory management, and self-reflection. |
The standard contains 6 capability domains, 24 capability items, and more than 200 capability indicators.
The model separates capabilities into two layers. The upper layer is intelligent capability. One side focuses on scenario applications: intelligent data analysis, log analysis, alert baselines, alert convergence, anomaly detection, trend prediction, root-cause analysis, and optimization recommendations. The other side is an "observability intelligence body": natural-language interaction, tool calling, memory management, and self-reflection.
The lower layer is observability capability. It begins with planning and design, then moves into daily operations and data management. The data-management section explicitly includes collection, storage, and processing. On the right side, the model ties everything to continuous operations optimization, including platform operations, alert operations, and standardized IT-process operations.
Why this matters to platform teams
The model suggests a practical maturity path:
- first make telemetry reliable and standardized;
- then make data searchable, visual, and alertable;
- then apply intelligent analysis to logs, anomalies, baselines, trends, and root causes;
- finally connect the platform to continuous operational improvement.
That order matters. Large-model-based troubleshooting is much less useful when the underlying log, metric, tracing, alerting, and data-governance layers are inconsistent.
Where CLS fits in the maturity model
Tencent Cloud CLS is one of the core participating products in the standard work. CLS representatives joined multiple discussions with experts from China Mobile Cloud, ZTE, and other cloud vendors and companies.
The CLS capability map connects the maturity model to a concrete platform architecture. On the left, data comes from endpoints, online and offline systems, open-source ecosystems, applications, and cloud-product ecosystems. The diagram includes sources such as iOS, Android, webpages, Windows, servers, IDC, Tencent Cloud, AWS, Beats, Log4j, Kubernetes, VictoriaMetrics, Logstash, Fluentd, Logback, OpenTelemetry, syslog, MySQL, Windows events, CVM, TKE, SCF, EKS, CDN, CLB, COS, Oceanus, TDMQ, and cloud development services.
In the center, CLS provides collection and ingestion through LogListener, Kafka protocol, Prometheus protocol, API, and SDK. It then supports dashboards, charts, alert customization, alert suppression, alert grouping, data processing with 90+ functions, CQL/KQL-compatible search, SQL analysis with 300+ functions, correlation analysis, PromQL, low-frequency log storage, standard log storage, timed SQL, and metric storage.
Outputs include visualization through DataSight and Grafana, alert channels such as Enterprise WeChat, DingTalk, Feishu, WeChat, email, SMS, custom callbacks, and phone calls, consumption through SCF, Oceanus, Kafka, Spark, Hive, Flink, ClickHouse, and Elasticsearch, plus delivery to COS and CKafka.
User examples
Three customer examples show how this capability set is used:
- NIO used CLS security monitoring capabilities for millisecond-level security monitoring, tagging, desensitization, and an overall log-data security observability platform.
- Beike used CLS search and analysis capabilities to build a new unified observability platform and improve overall business efficiency.
- Lebo used the CLS collection ecosystem for multi-terminal one-stop data collection and reporting, improving full-link observability and user-experience optimization.
Practical takeaway
For cloud teams, the maturity model is useful because it converts "make observability intelligent" into a capability checklist. A mature platform should not only collect logs and metrics. It should standardize data, support analysis and visualization, provide alert governance, preserve data securely, connect to downstream processing systems, and gradually add intelligent analysis such as anomaly detection, root-cause analysis, tool calling, and natural-language operations.
Top comments (0)