Overview of high-level interfaces - Cloud Monitor - Alibaba Cloud Documentation Center

Background

In observability systems built on UModel, upper layers must understand UModel concepts such as DataSet, Storage, and Filter to access observable data. This creates several challenges:

Complex storage lookups: You must address various storage lookup problems, such as Filter routing and field mapping.
Awareness of underlying implementations: You must be aware of underlying details, such as how a MetricSet is implemented by MetricStore and LogSet.
Complex query construction: Multiple interactions are required, such as retrieving metadata before querying data.
Repetitive development: Each scenario requires the implementation of similar query logic.

Design goals

The UModel high-level interfaces provide a unified and simple data access layer. They are designed to achieve the following core goals:

1. Simplified queries

Abstract away underlying complexity: Users do not need to understand implementation details, such as storage specifics and field mapping.
Unified query syntax: A consistent Structured Process Language (SPL) query interface is provided to reduce the learning curve.
Automated processing: Underlying operations such as routing, mapping, and filtering are handled automatically.

2. Unified interfaces

Standardized access: Provides a standard way to access all data types.
Simplified integration: Simplifies the development work for integrating with MCP, AIOps Agent, and other systems.
Unified SPL: The UModel high-level interfaces use SPL syntax. You can call SPL for further analysis after a query.

3. High-level abstractions

Object-oriented semantics: Provides an entity-based, abstract way to access data.
Intelligent method calls: Supports retrieving object interfaces at runtime and calling them, similar to Java reflection.

Architecture design

Overall architecture

The UModel Platform as a Service (PaaS) interfaces use a layered architecture. They provide unified data access capabilities through a service-based deployment.

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│      Client     │    │   AIOps Agent   │    │        UI       │
│   (SPL Query)   │    │(Intelligent Analysis)│    │ (Visualization) │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌─────────────────┐
                    │ UModel PaaS API │
                    │(Transform Service)│
                    └─────────────────┘
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│ Data Layer API  │    │Object Layer API │    │Metadata Layer API│
│   (Table Mode)  │    │  (Object Mode)  │    │   (Meta Query)  │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌─────────────────┐
                    │   EntityStore   │
                    │(Underlying Storage)│
                    └─────────────────┘

Two-phase query mode

The PaaS interface design uses a two-phase query mode. This decouples specialized filtering from general computation.

Phase 1: Table mode (data layer)

Direct data access: Directly access a dataset and return an SPL query.
Specialized filtering: Define additional parameters based on the specific capabilities of a dataset, such as Step, aggregation, Labels, and Metrics for a MetricSet.
Row and column filtering: Specify the required rows and columns.
Scenarios: Use this mode when you need full control over the query logic and do not require entity relationship abstractions.

Phase 2: Object mode (object layer)

Abstract entity access: Access related data through an entity (EntitySet).
Automatic field mapping: Automatically handles field mapping and filter conditions.
Relational data queries: Supports data access based on entity relationships.
Scenarios: Use this mode when you need entity-based abstractions to automatically handle complex relational queries.

Interface overview

Data layer (Phase 1 Table mode)

This layer provides direct access to various types of datasets:

Dataset Type	SPL Syntax	Description
MetricSet	`.metric_set with(...)`	Queries metric data. Supports Prometheus Query Language (PromQL) and SPL modes.
LogSet	`.log_set with(...)`	Queries log data. Supports full-text index and filtering.
TraceSet	`.trace_set with(...)`	Queries Tracing Analysis data.
EventSet	`.event_set with(...)`	Queries event data.
ProfileSet	`.profile_set with(...)`	Queries performance profiling data.

Object layer (Phase 2 Object mode)

This layer provides object-oriented capabilities to access entities.

.entity_set with(domain='domain_name', name='entity_name', [parameters]) 
| entity-call method_name(parameters...)

Core method categories:

Method Category	Example Method	Description
Built-in Management	`__list_method__()`, `__inspect__()`	Lists methods and inspects configurations.
Data Access	`get_golden_metrics()`, `get_metric()`	Gets data related to an entity, such as metrics and logs.
Relationship Access	`get_relation_metric()`, `list_related_entity_set()`	Gets data about relationships between entities.
Entity Management	`get_entities()`, `get_neighbor_entities()`	Lists entities and queries neighboring entities.