作者：灵亦

01 什么是实体探索（Entity Explorer）

1.1 实体探索概述

在可观测性领域，实体（Entity）指的是任何可以被独立识别和监控的对象，例如：

• 基础设施实体：主机、容器、网络设备、存储系统
  
• 应用层实体：微服务、API 接口、数据库实例、消息队列
  
• 业务实体：用户会话、业务流程、交易订单
  
• 运维实体：部署环境、代码仓库、运维人员
  

实体查询的核心价值在于打破传统监控中按“产品”或“指标”划分的孤岛式视图，构建全景化的实体资产目录。用户可以在实体查询中实现以下目标：

• 统一盘点：清晰查看 UModel 中定义的所有实体类型（Entity Type）及具体实体实例，并按域（Domain）和类型进行分类展示。
  
• 快速检索：利用 USearch 查询语言，支持全文检索、精确匹配、条件过滤等多种方式，快速定位所需实体。
  
• 关联分析：以任一实体为起点，探索其状态、性能指标、关联日志、链路追踪和拓扑关系，实现一站式问题诊断与分析。
  

1.2 实体探索的难度

要实现高效、精准的实体探索，意味着需要在海量、异构的数据中快速定位并分析目标。在实践过程中，我们面临三大核心技术挑战：

1.2.1 海量数据的性能挑战

当实体数据达到亿级甚至更高规模时，简单的处理方式会迅速失效，带来严峻的性能与成本问题。

计算复杂度的爆炸式增长：理论上，任意两个实体记录都可能存在关联。若采用遍历匹配的方式，计算复杂度将呈指数级增长。在海量数据背景下，这种方法耗时极长，完全不具备可行性。

巨大的资源与成本压力：大规模数据处理会急剧消耗算力、存储和网络带宽。任何微小的算法低效都会被数据规模无限放大，直接转化为显著的资源与时间成本。

严苛的实时性要求：实体探索并非一次性离线分析。系统必须能够对持续涌入的新数据进行增量处理与实时更新，否则探索结果会迅速过时，失去业务价值。

1.2.2 数据异构与语义多样性

实体数据往往来源于多个系统，格式不一、质量参差不齐，这给实体识别与关联带来了巨大障碍。

实体描述不统一：同一实体在不同数据源中可能存在多种写法，如别名、缩写、谐音、拼写错误、繁简体差异、中英文夹杂等（例如，“IBM”、“I.B.M.”与“国际商业机器”指向同一对象），严重干扰了实体的准确定位。

信息缺失与质量问题：实体信息常常存在数据“脏”或缺失的情况，例如关键字段为空、地址信息不完整、联系方式过时、时间戳不准确，甚至字段内容错填（如将法人名填入公司名列），导致无法建立可信的实体画像。

1.2.3 前端呈现的定制化与高耦合

即使后端数据处理完毕，如何将其有效呈现给用户，也面临着架构层面的困境，直接影响研发效率和系统可维护性。

UI 开发成本高：由于每种实体都需要一套独立的 UI 呈现方案，导致前端开发存在大量重复工作，且难以统一设计风格与交互体验。

数据逻辑分散：数据获取逻辑与实体类型、ID 深度绑定，数据来源分散。这不仅增加了后端接口聚合的复杂度，也使前端需要对接多个数据源，数据管理变得异常困难。

配置噩梦与高耦合：实体间的关联跳转配置极为复杂，常常牵一发而动全身。这种硬编码式的关联逻辑导致系统耦合度极高，每次需求变更都伴随着巨大的开发、测试成本与潜在风险。

1.3 实体探索平台的解决思路

为解决实体探索中数据量巨大、内容混杂、UI 开发复杂这三大核心难题，我们设计了一套由四大支柱构成的综合解决方案。这套方案从查询入口、业务融合、关联分析到 UI 呈现，形成了一个完整闭环，旨在实现高效、智能、低成本的实体可观测性。

1.3.1 统一查询入口：基于 USearch 的全局检索组件

打造一个类似搜索引擎的、功能强大的统一查询入口。用户无需关心底层数据的存储位置和异构性，只需通过简单、自然的语言即可完成对海量实体的精准定位和快速检索。

• 屏蔽底层复杂性：该组件作为唯一的数据查询组件，将用户输入的查询语句（基于 USearch 语言）解析并分发到不同的后端数据源（如日志库、指标库、CMDB 等）。它将异构数据源的查询结果进行聚合、清洗和格式化，最终以统一的实体模型返回给上层应用。
  
• 高性能查询引擎：依托 USearch 底层优化的索引和分布式计算能力，即使在百亿级的数据规模下，也能实现秒级的查询响应。这直接解决了“量太大”带来的性能瓶颈和实时性压力。
  

1.3.2 场景驱动：实体与业务融合的应用（APP）

打破“数据孤岛”，将技术实体与具体的业务场景深度融合。我们提供的不是一个冰冷的实体列表，而是一个个面向业务问题、预设了分析路径的“应用”（APP），让技术监控数据直接服务于业务价值。

上下文聚合：为特定业务场景（如“数据库监控”、“应用监控”）创建一个融合视图。这个视图会自动聚合与该场景相关的所有实体与页面，提供专业视角。

信息补全与丰富：通过跨数据源关联，自动补全实体信息。例如，通过 IP 地址关联到主机实体，再通过主机实体关联到其上运行的服务，最终关联到服务的负责人。这有效解决了“信息缺失和脏”的问题，让每个实体都拥有更丰满的上下文。

1.3.3 可视化探索：实体拓扑与关联分析组件

将实体间错综复杂的关系通过网络拓扑图的形式直观地呈现出来。用户可以像探索地图一样，以任意实体为中心，交互式地发现其上下游依赖、影响范围和潜在关联，将“看不见”的关系变为“看得见”的洞察。

• 动态关系发现：该组件不依赖于硬编码的配置，而是通过后台服务实时计算和发现实体间的关联关系（例如，服务调用、主机部署、网络访问等）。
  
• 交互式探索：用户可以在拓扑图上自由缩放、拖拽、下钻。点击任一实体节点，即可查看其详细信息、性能指标、告警和日志，并可一键展开其邻近节点，实现“一站式”的关联分析。
  
• 影响域和根因分析：当某个实体出现故障时，拓扑图能清晰地展示其上游依赖（帮助定位根因）和下游影响（帮助评估故障范围），为快速决策提供关键依据。
  

1.3.4 建模驱动 UI：基于实体模型的自动化渲染引擎

颠覆传统的 UI 开发模式，实现 UI 的自动化生成。我们不为每一种实体类型定制开发 UI，而是通过定义一套丰富的实体模型（Schema），由一个统一的渲染引擎根据模型自动生成对应的展示界面。

• 定义即 UI（Schema as UI）：在 UModel 中为每种实体类型定义其元数据模型。该模型不仅包含字段名和类型，还包含丰富的 UI 指令，如“此字段应展示为图表”、“此字段是一个链接，指向另一实体”、“此字段按时间格式化”等。
  
• 统一渲染引擎：开发一个通用的前端组件，它能接收任何实体的数据和其对应的模型。该组件会解析模型中的 UI 指令，并动态地渲染出相应的 UI 元素（详情页、列表、表单等）。
  
• 低代码与可扩展：新增一种实体类型，前端开发工作量几乎为零，只需在 UModel 中定义好其模型即可。同时，渲染引擎支持插件化扩展，可以不断丰富其支持的 UI 组件类型。
  

02 实体探索核心功能：基于 USearch 的全局检索组件

2.1 实体总览

实体探索将 UModel 中定义的所有实体按照域（Domain）和类型（Entity Type），已经接入的实体都会分类在所属的分类中。

1. 支持查看所有实体的总量。
   
2. 支持查看每个实体的实例数量。
   
3. 如果是云产品实体，支持查看该云产品下所有实体是否全量接入。
   
4. 单击实体后选中该实体的域（Domain）和类型（Entity Type）。
   

2.2 实体查询与展示

查询语言介绍实体查询支持两种查询语言：USearch 和 SPL，在实体查询页面左上角可以切换语言。 请参考 USearch 实体查询语言^[1]和 SPL 数据处理语言^[2]。

在 USearch 模式下，实体查询左上角可以选择域（Domain）和类型（Entity Type），SPL 模式不支持。

USearch 查询结果会根据实体的类型（Entity Type）进行展示，包括实体的 Primary Key 和 Name 字段，以及实体的黄金指标。

SPL 查询结果不会按照实体的类型（Entity Type）进行展示，而是展示具体字段。

2.3 拓扑概览视图

概览拓扑将抽象的系统架构转化为可视化的数字模型，展示云环境下已接入的所有实体类别、接入数量以及各类实体的依赖关系，通过全局架构视图支持服务治理与依赖管理，为运维和开发团队提供了直观理解系统架构的有效手段。

2.3.1 拓扑概览主页

在‘所有实体’的右上角点击‘拓扑’，可以查看当前 Workspace 接入的各类实体的总量以及之间的关系。

2.3.2 链路聚焦交互

节点支持‘聚焦’操作，点击聚焦后，拓扑图仅保留以当前节点为中心的所有祖先和后代节点，更清晰地展示依赖关系和传播链路。

在聚焦状态下，可通过工具栏的‘取消聚焦’回到原始拓扑图。

2.3.3 实体列表展示

单击实体，右侧弹出当前实体类型下所有已接入的实体列表。

2.3.4 拓扑搜索

支持与 USearch 查询联动，展示所有匹配到字符串的实体的拓扑关联。

在 USearch 查询模式下，点击节点会展示当前查询到的所有结果的列表。

03 实体探索核心功能：实体详情

实体详情页是我们整个实体探索体系的“价值交付窗口”。它并非一个静态、由前端工程师逐行代码写死的界面，而是一个完全由后端 UModel 动态渲染、自动构建的智能视图。这种模式从根本上解决了前面提到的三大挑战。

3.1 实体概览

实体概览包含一组动态渲染的 Tabs 页面 + 关联拓扑、UModel Explorer 等若干固定的页面构成。其中动态的 Tabs 页面完全基于 UModel 渲染：自动渲染逻辑包含可视化选择（根据实体信息匹配仪表盘、页面模板）、数据源选择（根据实体信息匹配选择的页面使用什么数据源进行渲染）。

关联实体：实体概览首页点击关联实体可以快捷查看该实体和其他实体的关联关系表格，表格根据关系的名称分类，关系有：包含、等同、上游、下游等。点击关联实体，可以跳转到对应实体的实体概览。

3.2 关联拓扑

3.2.1 智能分层架构视图

采用智能分层布局，将复杂的云环境按照域（Domain）进行垂直分层：

分层架构：

• 🌐 RUM 层：用户体验监控域，关注前端性能和用户行为
  
• 🔧 APM 层：应用监控域，监控应用服务性能
  
• ☸️ K8S 层：容器编排域，管理容器化应用
  
• ☁️ ACS 层：云产品域，集成各类云服务
  
• 🖥️ INFRA 层：基础设施域，监控服务器和网络
  

3.2.2 多层级依赖逐层展开

通过"展开下一级"功能，可以逐层探索服务依赖关系，适用于复杂系统的渐进式分析；通过多层级依赖分析，全面评估系统依赖情况：

使用场景：

• 🔍 逐层分析：从核心服务开始，逐步展开相关依赖
  
• 📊 性能诊断：结合指标数据，识别性能瓶颈点
  
• 🛠️ 架构梳理：理清复杂系统的真实依赖关系
  

3.2.3 聚焦追踪模式

核心特性：

• 🎯 智能聚焦：以目标节点为中心，展示直接关联的上下游
  
• 🔄 动态追踪：每次展开操作会自动切换聚焦中心
  
• 💡 上下文保持：取消聚焦时自动保存已展开的节点状态
  

3.2.4 大规模服务依赖分析

面对包含数百个微服务的复杂系统，通过智能分组和渐进式分析，实现依赖关系的有序分析：

智能展开策略：当展开操作产生大量节点时，系统会自动进行分组管理，确保界面清晰可读。超过 20 个节点的组会被智能收纳，通过拆分面板进行精确管理。

04 USearch & SPL 实体查询语言

4.1 USearch

USearch 是专门用于实体查询的 SPL 语法，支持多种查询模式，包括全文检索、精确查找、条件过滤等。USearch 深度集成在云监控 2.0 中，提供全局快速查询、字段快捷下钻、指标下钻等功能。

4.1.1 USearch 基础语法

.entity with(
    domain='domain_pattern',     -- 域过滤
    type='type_pattern',         -- 类型过滤
    query='search_query',        -- 查询条件
    topk=10                      -- 最大返回条数
)

• 全文搜索：支持跨所有字段的关键词搜索。
  
• 字段限定查询：支持在特定字段中进行精确搜索。
  
• 逻辑条件组合：支持 AND、OR、NOT 等逻辑运算符。
  
• 智能打分排序：基于 IDF 权重和列权重的相关性打分。
  
• 特殊字符处理：自动处理查询中的特殊字符。
  

4.1.2 典型应用场景

-- 全文搜索
.entity with(query='web service')
-- 字段限定搜索
.entity with(query='status:running')
-- 逻辑组合查询
.entity with(query='environment:prod AND status:error')
-- 域和类型过滤
.entity with(domain='apm', type='apm.service', query='production')

4.2 SPL 数据处理语言

SPL（SLS Processing Language）是日志服务提供的数据处理语言，用于对读取出的原始数据进行结构化信息提取、字段操作和数据过滤等操作。SPL 支持多级管道级联功能，可以进行复杂的数据处理和分析。

4.2.1 工作原理

SPL 采用管道式处理架构：

1. 第一级管道：索引过滤条件（如 USearch 查询）
   
2. 后续管道：SPL 指令进行数据处理
   
3. 最终输出：经过 SPL 处理后的结果数据
   

核心功能：

数据过滤和筛选

-- 条件过滤
| where status = "error"
| where cpu_usage > 0.8
-- 时间范围过滤
| where __time__ > "2024-01-01 00:00:00"

字段操作

-- 字段提取
| extend new_field = field1 + field2
-- 字段重命名
| project-rename new_name = old_name
-- 字段选择
| project field1, field2, field3

4.2.2 USearch 与 SPL 结合使用

USearch 可以作为 SPL 的数据源，实现从实体查询到数据分析的完整流程：

-- 基础组合：实体查询 + 数据处理
.entity with(domain='apm', type='apm.service', query='production')
| where language = 'java'

4.3 在控制台中使用 USearch

4.3.1 全局快速查询

功能入口：登录可观测平台控制台，进入任意工作空间（WorkSpace），在左侧导航栏选择快速查询。

1. 支持在输入框中输入关查询语句（USearch SPL 语法中的 query 部分），点击查询按钮，查询结果会显示在下方结果区域。
   
2. 支持在左侧选择域（Domain）和实体类型（EntitySet），点击查询按钮，查询结果会显示在下方结果区域。
   
3. 支持在左侧列表上选择查询实体结果，右边展示该实体的详细信息以及环境指标。
   

4.3.2 实体查询

功能入口：登录可观测平台控制台，进入任意工作空间（WorkSpace），在左侧导航栏选择实体查询。

1. 支持在输入框中输入关查询语句（USearch SPL 语法中的 query 部分），点击查询按钮，查询结果会显示在下方结果区域，和快速查询的查询结果一致。
   
2. 支持切换到 SPL 查询模式，输入 SPL 查询语句（完整 USearch SPL 语法），点击查询按钮，查询结果会显示在下方结果区域。
   

4.3.3 字段快捷下钻

功能入口：登录可观测平台控制台，进入任意的实体查询页面、仪表盘等页面，鼠标悬浮在字段上，会显示 USearch 按钮。点击 USearch 按钮，会弹出 USearch 查询框，自动填充字段内容并搜索，结果和快速查询的查询结果一致。

05 总结

Entity Explorer 核心愿景：从数据混沌到业务洞察，我们用确定性的模型，驾驭不确定性的数据世界。

在构建 Entity Explorer 之初，我们直面了数据探索领域的三座大山：

• 海量数据的性能瓶颈：大量实体带来的指数级计算复杂度和巨大的资源成本。
  
• 异构数据的语义鸿沟：多源、异构、低质量的数据导致实体难以被准确识别和关联。
  
• 高耦合架构的维护噩梦：硬编码的前端呈现逻辑导致开发效率低下、系统脆弱且难以扩展。
  

为了解决上面的问题，我们提出了 UModel（统一实体模型）驱动架构，UModel 是整个系统的“中央大脑”和“设计蓝图”。它是一个声明式的模型，不仅定义了实体是什么（属性、标签、元数据），还定义了实体间的关系（关联类型、深度），甚至规定了实体应该如何被呈现（UI 布局、组件、交互逻辑）。

Entity Explorer 通过 UModel 这一核心抽象，为我们带来了：

极致的效率：将数周的前端开发时间缩短为数小时的模型配置。

高度的精准：提供了一个可信、统一、360° 的实体全景视图。

深度的洞察：赋予各类人员轻松分析复杂数据关系、发现潜在价值的能力。

相关链接：

[1] USearch 实体查询语言

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/entity-explorer-overview?spm=a2c4g.11186623.help-menu-28572.d_2_1_0_0.376c3f5b0thNfp&scm=20140722.H_2974636._.OR_help-T_cn~zh-V_1#3250fbab95y2y

[2] SPL 数据处理语言

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/entity-explorer-overview?spm=a2c4g.11186623.help-menu-28572.d_2_1_0_0.376c3f5b0thNfp&scm=20140722.H_2974636._.OR_help-T_cn~zh-V_1#6e82481ab0637