作者：靈亦

什麼是實體探索（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 組件類型。

實體探索核心功能：基於 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 查詢模式下，點擊節點會展示當前查詢到的所有結果的列表。

實體探索核心功能：實體詳情

實體詳情頁是我們整個實體探索體系的“價值交付窗口”。它並非一個靜態、由前端工程師逐行代碼寫死的界面，而是一個完全由後端 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 個節點的組會被智能收納，通過拆分面板進行精確管理。

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 查詢框，自動填充字段內容並搜索，結果和快速查詢的查詢結果一致。

總結

Entity Explorer 核心願景：從數據混沌到業務洞察，我們用確定性的模型，駕馭不確定性的數據世界。

在構建 Entity Explorer 之初，我們直面了數據探索領域的三座大山：

• 海量數據的性能瓶頸：大量實體帶來的指數級計算複雜度和巨大的資源成本。
• 異構數據的語義鴻溝：多源、異構、低質量的數據導致實體難以被準確識別和關聯。
• 高耦合架構的維護噩夢：硬編碼的前端呈現邏輯導致開發效率低下、系統脆弱且難以擴展。

為了解決上面的問題，我們提出了 UModel（統一實體模型）驅動架構，UModel 是整個系統的“中央大腦”和“設計藍圖”。它是一個聲明式的模型，不僅定義了實體是什麼（屬性、標籤、元數據），還定義了實體間的關係（關聯類型、深度），甚至規定了實體應該如何被呈現（UI 佈局、組件、交互邏輯）。

Entity Explorer 通過 UModel 這一核心抽象，為我們帶來了：

極致的效率：將數週的前端開發時間縮短為數小時的模型配置。

高度的精準：提供了一個可信、統一、360° 的實體全景視圖。

深度的洞察：賦予各類人員輕鬆分析複雜數據關係、發現潛在價值的能力。

相關鏈接：

[1] USearch 實體查詢語言

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/en...

[2] SPL 數據處理語言

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/en...