Relationship modeling - Cloud Monitor - Alibaba Cloud Documentation Center

Overview

In the UModel data modeling system, a Link is a key mechanism for connecting different datasets. Links establish relationships between EntitySets, between EntitySets and DataSets, and between DataSets and Storage, forming a comprehensive network of data relationships.

UModel provides three types of Links for different association scenarios:

Link type	Purpose	Connected objects
EntitySetLink	Defines relationships between entities.	EntitySet <-> EntitySet
DataLink	Defines associations with data sets.	EntitySet/EntitySetLink -> DataSet
StorageLink	Defines mappings to storage.	EntitySet/EntitySetLink/DataSet -> Storage

EntitySetLink - Entity relationship modeling

Terms

An EntitySetLink defines the relationship between two EntitySets and is a core component for building an Entity Relationship Diagram. Each EntitySetLink must include the following:

Source EntitySet: The starting point of the relationship.
Target EntitySet: The end point of the relationship.
Link type: Describes the nature of the relationship.

Relationship types

EntitySetLink supports multiple relationship types for various business scenarios:

Relationship type	Meaning	Application Scenario
`calls`	Calls	Service invocation relationship
`runs`	Runs	Process execution relationship
`instance_of`	Instance	Instance and type relationship
`parent_of`	Parent	Hierarchical relationship
`contains`	Contains	Container relationship
`manages`	Management	Management relationship
`monitors`	Monitors	Monitoring relationship
`serves`	Service	Service provider relationship
`hosted_by`	Hosted by	Deployment relationship
`related_to`	Related to	General association

Core configuration

Field mapping

Define the field mapping between the source and target EntitySets using fields_mapping:

spec:
  fields_mapping:
    source_field_1: target_field_1
    source_field_2: target_field_2

Dynamic relationships

Set dynamic: true to enable a dynamic EntitySetLink:

The relationship content is retrieved from Storage in real-time instead of being stored in EntityStore.
This is suitable for scenarios where relationships change frequently.
This must be used in conjunction with Storage.

Configuration example

kind: entity_set_link
schema:
  url: "umodel.aliyun.com"
  version: "v0.1.0"
metadata:
  name: "apm.service_calls_apm.service"
  display_name:
    en_us: >
      Service-Calls-Service
    zh_cn: "Application-Calls-Application"
  description:
    en_us: >
      The link between "apm.service" and "apm.service".
    zh_cn: "Application-Calls-Application"
  domain: apm
spec:
  src:
    domain: apm
    kind: entity_set
    name: apm.service
  dest:
    domain: apm
    kind: entity_set
    name: apm.service
  entity_link_type: calls

DataLink - Data association modeling

Terms

A DataLink defines the relationships between an EntitySet or Link and a DataSet, along with the associations between DataSets. A DataLink acts as the bridge between the entity model and the data model.

Link types

DataLink supports two link types:

Type	Meaning	Use case
`produce`	Produces	An EntitySet produces a related dataset.
`related_to`	Related	A weak association where a correlation exists between data.

Core configuration

Field mapping

Define the field mapping between the source and target datasets:

spec:
  fields_mapping:
    entity_id: data_entity_id
    timestamp: data_time

Data filtering

You can use data_filter to filter target data, but this is not recommended.

spec:
  data_filter: "type='db'"  # Filters metrics of the database type.

Note: The data_filter parameter uses a complex, query-type filter syntax. We recommend using other methods to filter data.

Configuration example

kind: data_link
schema:
  url: "umodel.aliyun.com"
  version: "v0.1.0"
metadata:
  name: "apm.service_related_to_apm.metric.apm.service"
  display_name:
    en_us: >
      APM Service - APM Service Request Metrics
    zh_cn: "Application-Traffic Metrics"
  description:
    en_us: >
      The link between "apm.service" and "apm.metric.apm.service".
    zh_cn: "Application-Traffic Metrics"
  domain: apm
spec:
  src:
    domain: apm
    kind: entity_set
    name: apm.service
  dest:
    domain: apm
    kind: metric_set
    name: apm.metric.apm.service
  data_link_type: related_to
  fields_mapping:
    "service_id": "acs_arms_service_id"

StorageLink - Storage mapping modeling

Terms

A StorageLink defines the mapping between an EntitySet, EntitySetLink, or DataSet and Storage. It connects a data collection to its underlying storage.

Core configuration

Field mapping

Define the mapping between the fields of a data collection and the fields in storage:

spec:
  fields_mapping:
    logical_field_name: storage_column_name
    entity_id: storage_id
    timestamp: storage_time

Configuration example

kind: storage_link
schema:
  url: "umodel.aliyun.com"
  version: "v0.1.0"
metadata:
  name: "app.log.common_storage_link"
  display_name:
    en_us: >
      App Log Set Storage Link
    zh_cn: "Application Log Dataset Storage Link"
  description:
    en_us: >
      Storage link for app log set data.
    zh_cn: "Storage link for the application log dataset"
  domain: apm
spec:
  src:
    domain: app
    kind: log_set
    name: app.log.common
  dest:
    domain: app
    kind: sls_logstore
    name: app.log.common.storage

Advanced configuration: Field mapping

Field mapping principles

Field mapping, or fields_mapping, is a core configuration in Link modeling. It establishes the correspondence between the fields of source and target objects. Proper field mapping is key to ensuring accurate data associations.

Core principles

Primary key first mapping: In an association from an entity to a DataSet, you must map the entity's primary key field to a field in the DataSet.
Ensure integrity: The mapping must cover all key identifier fields. This ensures that you can precisely locate data for a specific entity.
Type compatibility: Ensure that the data types of the source and target fields are compatible.
Semantic consistency: The mapped fields should have the same business semantics.

Entity primary key mapping example

Take an application performance management (APM) application entity as an example. The entity's primary key field must be fully mapped to the metric data. The APM service name is also unique and matches the service name in the MetricSet. Therefore, you must also map the service name.

# Associate an APM application entity with metric data
kind: data_link
metadata:
  name: "apm.service_related_to_apm.metric.apm.service"
spec:
  src:
    domain: apm
    kind: entity_set
    name: apm.service
  dest:
    domain: apm
    kind: metric_set
    name: apm.metric.apm.service
  data_link_type: related_to
  fields_mapping:
    # Entity primary key field mapping
    "service_id": "acs_arms_service_id"    # Unique application identifier, primary key field
    "service_name": "service"              # Application name

Hierarchical entity mapping example

This example uses an Alibaba Cloud NAS file system to show how to map an entity to multiple types of metrics:

# Associate a NAS entity with CPFS metrics
kind: data_link
metadata:
  name: "acs.nas.filesystem_related_to_acs.metric.prometheus_cpfs_userid_filesystemid"
spec:
  src:
    domain: acs
    kind: entity_set
    name: acs.nas.filesystem
  dest:
    domain: acs
    kind: metric_set
    name: acs.metric.prometheus_cpfs_userid_filesystemid
  data_link_type: related_to
  fields_mapping:
    # Complete entity primary key mapping
    region_id: region_id                 # Region identifier
    resource_group_id: resource_group_id # Resource group identifier
    instance_id: fileSystemId           # File system instance ID
    user_id: userId                     # User identifier

Advanced configuration: Filter conditions

UModel provides two filtering mechanisms to control the scope of data associations. These mechanisms have different use cases and filter different objects.

filter_by_entity: Entity-level filtering

filter_by_entity filters at the source entity level. A Link is established only for entities that meet the condition.

The syntax for filter_by_entity is a subset of the Structured Process Language (SPL) Boolean expression syntax. For more information, see SPL syntax.

Scenarios

An EntitySet contains multiple child classes, and you need to create associations for only specific child classes.
Filter the scope of associated entities based on their property values.
Select the corresponding storage instance based on a specific entity.

Configuration example

This example uses a NAS file system to establish different metric associations based on the file system type:

# Associate a CPFS file system with CPFS metrics
kind: data_link
metadata:
  name: "acs.nas.filesystem_related_to_acs.metric.prometheus_cpfs_userid_filesystemid"
spec:
  src:
    domain: acs
    kind: entity_set
    name: acs.nas.filesystem
  dest:
    domain: acs
    kind: metric_set
    name: acs.metric.prometheus_cpfs_userid_filesystemid
  data_link_type: related_to
  filter_by_entity: file_system_type in ('cpfs', 'bmcpfs')  # Associates only with the CPFS type
  fields_mapping:
    region_id: region_id
    instance_id: fileSystemId
    user_id: userId

# Associate a standard NAS file system with NAS metrics
kind: data_link
metadata:
  name: "acs.nas.filesystem_related_to_acs.metric.prometheus_nas_userid_filesystemid"
spec:
  src:
    domain: acs
    kind: entity_set
    name: acs.nas.filesystem
  dest:
    domain: acs
    kind: metric_set
    name: acs.metric.prometheus_nas_userid_filesystemid
  data_link_type: related_to
  filter_by_entity: file_system_type = 'standard'  # Associates only with the standard NAS type
  fields_mapping:
    region_id: region_id
    instance_id: fileSystemId
    user_id: userId

data_filter: Data-level filtering

data_filter filters at the target data level. Only data in the target DataSet that meets the condition is associated with the source entity.

The syntax for data_filter is a subset of the SPL Boolean expression syntax. For more information, see SPL syntax.

Scenarios

The target DataSet contains multiple data types, and you need to associate only a specific data type.
Filter the relevant data scope based on the data content.
Implement conditional data associations.

Configuration example

# Associate an application entity with invocation metrics of the database type
kind: data_link
metadata:
  name: "apm.service_related_to_database_metrics"
spec:
  src:
    domain: apm
    kind: entity_set
    name: apm.service
  dest:
    domain: apm
    kind: metric_set
    name: apm.metric.external_calls
  data_link_type: related_to
  data_filter: "call_type='database'"  # Associates only with metric data from database calls
  fields_mapping:
    service_id: service_id

Filter condition comparison

Filter type	Filtered object	Use case	Syntax
filter_by_entity	Source entity	Entity categorization, entity property filtering	Query syntax expression
data_filter	Target data	Data categorization, data content filtering	Query syntax expression

Best practices for filter configuration

1. Prioritize filter_by_entity

Filtering at the entity level provides better performance.
The semantics are clearer, making it easier to understand and maintain.
Avoid complex query syntax.

2. Use data_filter with caution

data_filter uses a complex query syntax.
It can affect query performance. Avoid overly complex filter conditions.
You can use multiple dedicated DataSets instead of a complex data_filter.

3. Filter condition design principles

Accuracy: The filter condition should accurately reflect business requirements.
Performance: Avoid complex conditions that affect query performance.
Maintainability: The filter condition should be easy to understand and modify.

4. Practical application suggestions

Scenario	Recommended solution	Reason
Grouping entity child classes	Use filter_by_entity	Filters at the entity level for better performance.
Filtering data content	Create a dedicated DataSet	Avoids complex query syntax.
Temporary data filtering	Use data_filter	Quickly implements special requirements.

Notes

Design the granularity and quantity of your Links carefully.
Regularly check the topology of the relationship graph.
Use dynamic Links with caution because they require additional storage query overhead.
Ensure the entities or datasets at both ends of a Link exist.
Promptly update Links that become invalid due to entity changes.