Simple Log Service：SLS一鍵接入實現OpenClaw受控運行

可觀測三支柱在 AI Agent 下的映射

可觀測性建立在 Logs + Metrics + Traces 三支柱之上，在 OpenClaw 情境下，三者與資料來源的對應關係及各自要回答的核心問題如下：

三支柱缺一不可：僅有 Metrics 無法回答“誰、因何”導致成本飆升；僅有 Session 日誌無法從全域感知系統健康與異常拐點；僅有應用作業記錄則看不到 Agent 的業務行為與工具調用序列。三者協同才能同時支撐安全審計、成本管控與營運排障。

阿里雲 SLS 能力與優勢

SLS 作為可觀測領域的基礎底座，在 OpenClaw 情境具有以下天然優勢：

• 強大的資料接入能力，與 OpenClaw 技術棧原生對齊

  LoongCollector 具備強大的 OneAgent 採集能力，對日誌與 OTLP 協議均有原生支援。Agent Session 日誌因承載模型互動上下文而往往較長，LoongCollector 提供針對長文本日誌的高效能採集能力；與 OpenClaw 內建的 diagnostics-otel 外掛程式零改造對接，Metrics 與 Traces 經 OTLP 直接寫入 SLS。

• 查詢分析與處理運算元豐富

  Session 日誌為 JSON 嵌套格式（如 message.content、message.usage.cost、message.toolName），SLS 提供 SQL + SPL 計算引擎及豐富的解析、過濾、彙總運算元，可對嵌套欄位做索引與即時分析，無需額外 ETL 處理。

• 安全與合規能力

  RAM 許可權管控、敏感性資料脫敏與加密儲存，滿足審計留痕與合規要求；SLS 持有網路安全專用產品安全檢測/認證認證（原安全專用產品銷售許可證），便於在等保與行業合規情境下作為可觀測與審計底座使用。警示通道支援DingTalk、簡訊、郵件等，便於安全事件與成本/異常警示的及時觸達與響應。

• 全託管、隨用隨付與Auto Scaling

  日誌分析一站式：“採集 → 儲存 → 索引 → 查詢 → 儀錶盤 → 警示”，依靠LogStore / MetricStore 全託管。小規模 Agent 日誌量不大、隨用隨付成本低；流量增加也能自動彈性，無需預留容量與手動擴容，無需自建 Elasticsearch、Prometheus 等。

因此 SLS 在對接 OpenClaw 可觀測資料，支撐審計 + 成本 + 異常檢測 + 安全合規 + 營運等多情境下，適合作為 OpenClaw 受控啟動並執行可觀測與審計底座。

當前 SLS 推出 OpenClaw 一站式接入方案：

• 通過接入中心嚮導式配置採集路徑與解析方式，自動產生並下發生效，實現 Session 日誌、應用日誌與 OTLP 遙測的統一入口、統一 Project。一站式接入，顯著降低多資料來源割裂帶來的複雜度與營運成本。

• 一份 Session 資料既可做安全審計，也可做成本與行為分析，滿足多情境複用。

• 預置的審計大盤、成本大盤與運行指標大盤實現開箱即用的受控運行觀測閉環。

步驟一：日誌接入（以 Session 日誌為例）

Session 日誌是安全審計的核心資料來源，記錄了每一輪對話、每一次工具調用、每一筆 Token 消耗。

前置準備

• 已建立Project（如 openclaw-observability）且已建立LogStore。

• 確保 OpenClaw 所在 ECS / 自建伺服器已安裝LoongCollector。

接入流程

1. 登入Log Service控制台，選擇右側的快速接入數據並選擇接入卡片，選擇OpenClaw-會話日誌，選擇目標Project與LogStore。

2. 在機器組配置下的源機器組列表中選擇安裝LoongCollector時建立的機器組添加到應用機器組列表中。

   若機器組心跳異常請參考心跳異常問題匯總排查。

3. 在Logtail設定頁，Log Service已自動填滿內建的採集配置，若無需修改可直接單擊下一步。

   • 配置名稱已預設配置。可按需修改。

   • 其他全域配置下的日誌主題類型已預設配置。

     關於日誌主題類型：LoongCollector支援從檔案路徑中自動提取topic和session_id，如檔案路徑經過自訂與預填不匹配需要自行調整。

   • 檔案路徑已預設自動填滿。

     關於文字檔路徑：預填的檔案路徑是假設使用者在Linux主機使用非root使用者預設安裝的路徑，如與實際情況不符，請注意修改。

   • 處理模式中預設配置了處理外掛程式組合。

     關於時間解析：OpenClaw預設輸出日誌中的時區為0時區，如進行過自訂，請同步修改時間解析外掛程式中的時區，避免時間錯配。

4. 在查詢分析配置頁，Log Service會自動產生內建索引與報表。後續可在查詢分析與儀錶盤中查看。

   • 內建索引如下：

   • 儀錶盤如下：

     • OpenClaw 行為分析大盤

     • OpenClaw 審計大盤

     • OpenClaw 指標大盤

     • OpenClaw Token 分析大盤

步驟二：審計與觀測

SLS 為 OpenClaw 提供了預置的儀錶盤，覆蓋安全審計、成本分析、行為分析、運行指標四個維度。

1. 登入Log Service控制台，在Project列表中選擇目標Project。

2. 在日誌存儲中目標LogStore中通過查詢 / 剖析進行接入驗證與日誌格式校正。

3. 在儀錶盤中查看預置儀錶盤。

   • 安全審計大盤

     Agent 的行為透明度直接關聯絡統安全與合規風險，且異常行為往往在造成實際損害之前已有跡可循。安全審計大盤是 OpenClaw 受控啟動並執行核心看板，聚焦於回答"Agent 在做什麼、有沒有高危動作、誰在執行越界操作"這一核心問題，從行為總覽、高危命令、提示詞注入、資料外泄等維度展開，提供即時行為監控、威脅識別與事後溯源的完整能力。

     • 安全審計統計概覽頁：

       • 以指定時間視窗內的多維高危操作計數為核心，將 OpenClaw 的安全態勢壓縮為一屏可讀的風險快照。高危命令執行、網頁請求外發、命令列外發、通訊工具外發、敏感檔案訪問、提示詞注入等七項指標並列呈現，配合環比資料，協助安全團隊在無需深入明細的情況下快速判斷當前風險水位是否異常。

       • 尤為值得關注的是提示詞注入事件後的高危操作計數。普通高危操作可能源於任務本身的合理需求，而注入後觸發的高危行為則是強烈的威脅訊號，這意味著注入的惡意指令已驅動 Agent 付諸執行。即便存在誤判，此類訊號也應觸發最進階別的人工複核，而非等待進一步確認。因此，"注入後工具調用的會話數"是整個總覽中威脅信賴度最高的訊號，3 個此類會話的優先順序往往高於數百次普通高危命令。

       • 高風險會話表以 Session 為單位彙總各維度風險計數，通過綜合風險評分自動排序，將最需要人工介入的會話置頂呈現。安全團隊無需逐條篩查日誌，直接從風險最高的 Session 開始溯源，大幅壓縮從發現到響應的時間視窗。

     • Skills 流量分析

       • Skills 流量分析從攻擊面視角審視 OpenClaw 的能力邊界。Skills 是 OpenClaw 的原生能力擴充機制，也是惡意提示詞注入的主要攻擊入口，使用者往往在不經意間安裝了存在安全性漏洞或內嵌惡意指令的 Skill，為攻擊者提供了可操控的能力入口。因此，Skills 的調用分布並非單純的使用統計，更是攻擊路徑分析的重要依據。

       • 使用分布餅圖協助安全團隊快速建立 Skills 調用的基準認知：哪些 Skills 屬於高頻主流調用，哪些屬於邊緣低頻。一旦某個非常見 Skills 的佔比突然上升，或出現從未見過的新 Skills，往往意味著 Agent 正在被引導至非預期的能力路徑，需要及時介入排查。

       • 新增 Skills 表格中內容尤為關鍵。新引入的 Skills 尚未經過充分的安全評估，其許可權邊界與行為模式對安全團隊而言仍是盲區。按首次調用時間逆序排列，可第一時間捕獲環境中新出現的 Skills，在其被濫用之前完成審查。

     • 高危命令調用監控

       • OpenClaw 的創新能力之一是自主執行系統命令，這也使其成為攻擊者的理想跳板。一旦 Agent 遭受提示詞注入或被惡意 Skill 操控，攻擊者即可藉助 Agent 的系統存取權限執行刪除檔案、提升許可權、滲出資料等破壞性操作，且全程以 Agent 身份發起，極難與正常任務行為區分。

       • 高危命令調用監控的核心價值在於在運行時防護之外建立獨立的可觀測層。OpenClaw 的工具許可權體系已在運行時層面實施管控，但策略配置錯誤、許可權邊界界定模糊或未覆蓋的邊緣情境，都可能導致高危命令在運行時層面悄然通過。可觀測層獨立於防護機制運行，確保即便運行時出現疏漏，高危操作也不會徹底失察。

       • 時間軸視圖的意義不只是計數，而是協助安全團隊識別行為模式。孤立的單次高危命令與短時間內的密集調用，風險含義截然不同。後者往往是 Agent 被操控後系統性執行惡意指令的典型特徵，需要立即介入。明細表則提供完整的溯源上下文，支援安全團隊從異常訊號快速追溯到具體會話與原始命令。

     • 提示詞注入檢測

       • 提示詞注入是驅動 AI 執行有害行為的核心攻擊手段。無論攻擊路徑如何，使用者直接輸入、Skills 調用返回還是 web_fetch、read 等工具讀取的外部資料，惡意指令終究需要匯入提示詞才能對 Agent 施加影響。提示詞是所有攻擊路徑的最終匯聚點。

       • 注入來源的分布可以協助判斷實際風險的性質。使用者直接輸入的注入通常是有意為之，而通過 toolResult 攜帶的注入，使用者往往並不知情。對於 OpenClaw 這類個人助理型 Agent，間接注入才是主要威脅——使用者安裝的 Skills 或訪問的外部內容均可能成為注入載體，且難以被使用者主動識別和規避。

       • 注入分類的價值在於識別攻擊意圖，而不只是標記異常。同樣是注入事件，ROLE_HIJACK 和 JAILBREAK 意味著攻擊者在試圖突破 Agent 的行為邊界，HIDDEN_INSTRUCTION 則代表更隱形植入手法，這些類型的響應優先順序和處置方式各不相同。持續觀察分類分布的變化，也有助於發現針對特定攻擊面的集中嘗試。

       • 明細表記錄每條注入事件的觸發工具、會話上下文與原始內容，支援安全團隊從分類統計快速下鑽至具體事件，完成從模式識別到溯源響應的完整閉環。

     • 敏感性資料外泄檢測

       • 資料外泄在 Agent 情境下往往不是單一事件，而是一條由多個步驟構成的行為鏈：Agent 被引導讀取敏感檔案、內容進入模型上下文、再通過後續工具調用完成外傳。單獨觀察任意一個環節都難以判斷威脅，只有將檔案訪問與外發行為關聯起來，才能還原攻擊的完整意圖。

       • 敏感性資料外泄檢測採用漏鬥式分析思路，逐層收窄雜訊，精準定位真實威脅。第一層對敏感檔案訪問進行全量記錄，按 SSH_KEY、ENV_FILE、CREDENTIALS、CONFIG_SECRET、HISTORY 五類資產分類，建立訪問基準。第二層對外發行為按渠道（API_CALL、MESSAGE_SEND、WEB_ACCESS、EMAIL）獨立追蹤，識別潛在的資料出口。第三層將兩者在時間維度上關聯，若同一 Session 內敏感檔案訪問與外發操作在短時間視窗內相繼出現，則標記為高優先順序滲出事件。

       • 這一機制的核心價值在於因果定位而非單點警示。Agent 讀取 SSH_KEY 不一定是威脅，發起 API_CALL 也不一定是威脅，但兩者在同一 Session 內以分鐘級間隔先後發生，且外發參數中攜帶敏感檔案內容，威脅信賴度則大幅提升。行為鏈分析表直接呈現 access_time 與 outbound_time 的時間差及完整的調用參數，讓安全團隊無需手動關聯日誌即可完成溯源判斷。

   • Token 分析大盤

     Token 消耗直接關聯營運成本，且其波動往往是系統異常（如 Prompt 注入導致上下文膨脹等）的早期訊號。Token 分析大盤圍繞“錢花在哪了、花得是否合理、有沒有異常”這一核心問題，從整體概覽、模型維度趨勢、會話等維度展開，提供用量監控、成本分析與異常發現能力。

     關於費用資料：大盤中的費用（cost）欄位來自 OpenClaw 的 usage.cost，OpenClaw 原生不支援階梯計費，且cacheRead + cacheWrite計算邏輯與供應商無法保持一致，僅按 inputTokens × input + outputTokens × output + ... 估算單次調用費用。因此大盤費用應視為成本估算的參考基準，而非精確賬單。未配置 cost 的模型，費用列將顯示為 0。

     千問3.5-Plus 配置樣本

     以千問3.5-Plus模型為例，百鍊API調用的費用見模型列表。

     .openclaw中模型成本的配置為：

     {
       "id": "qwen3.5-plus",
       "name": "Qwen3.5 Plus",
       "cost": {
         "input": 0.4, // 取自最低階梯輸入價格
         "output": 2.4, // 取自最低階梯輸出價格
         "cacheRead": 0.2, // 取input一半進行估算
         "cacheWrite": 0
       },
     }

     • 整體概覽與模型分布

       • 大盤頂部提供整體 Tokens與整體費用的 1 天對比：今日 vs 昨日用量（單位：萬 tokens）、今日 vs 昨日費用（單位：元），以及環比比例，便於快速判斷當日是否出現用量或費用突增。環比是成本異常的第一道訊號——若日環比突破預設閾值（如 ±30%），通常意味著出現了 Prompt 膨脹、迴圈調用或異常會話，應立即下鑽排查。

     • 按 Provider / Model 的消耗趨勢（時序）

       • 模型 Tokens 趨勢與模型費用趨勢兩條時序圖（1 周相對）共用時間軸與圖例，按模型分色展示各模型在時間維度上的 Token 消耗與費用變化。需要重點關注的是 Token 激增——這往往不只是成本問題，更可能是安全與穩定性的風險訊號：Prompt 注入導致上下文被惡意填充、工具調用陷入死迴圈、或會話因未觸發迴圈檢測而持續膨脹，都會在趨勢圖上表現為某條曲線的陡峭上升。兩張圖按模型分色呈現，模型切換會直接反映為顏色構成的變化，無需額外推斷即可確認切換時間點與涉及模型，便於判斷是否為預期變更。

     • 按會話與按主機/Pod 的 Top 消耗（柱狀圖）

       • 柱狀圖構成 2×2 布局，從會話與主機（或 Pod，容器情境）維度回答"誰在花錢、哪台機器或容器在花錢"，與具體的責任主體相關聯：

         • Top Tokens By Session / Top Cost By Session：過去 1 周各會話的 Token 合計與費用按降序排列。實踐中 Agent 的成本分布往往呈長尾特徵——少數會話佔據絕大部分消耗，識別這些"頭部會話"是成本最佳化的第一步。

         • Top Tokens By Host / Top Cost By Host：按主機（執行個體）或 Pod 彙總的 Token 與費用，用於多執行個體部署下的成本分析與風險定位。在企業環境中，主機或 Pod 通常與特定團隊、業務線或使用者綁定，結合資產歸屬即可將消耗資料對應到具體責任方——既能支撐成本分攤，也能在某台執行個體消耗異常時快速鎖定潛在的風險使用者或失控會話。

     • 模型 Tokens 詳情表（成本明細）

       • 詳情表（1 周相對）按模型列出：totalTokens、inputTokens、outputTokens、cacheReadTokens、cacheWriteTokens，以及對應的 totalCost、inputCost、outputCost、cacheReadCost、cacheWriteCost。支援排序與篩選，可直接回答"哪個模型花了最多錢、輸入/輸出各佔多少"。其中 inputTokens 與 outputTokens 的比值反映 Agent 的互動模式：輸入佔比過高說明 Prompt 或上下文冗餘，輸出佔比過高則可能是模型產生了大量無效內容；cacheReadTokens 佔比則直觀體現緩衝策略的收益——佔比越高、實際計費越低，為 Prompt 工程與緩衝調優提供量化依據。

   • 行為分析大盤

     行為分析大盤以會話為基本單位，對 OpenClaw 的運行行為進行全量記錄與分類統計，回答"Agent 在目前時間視窗內做了什麼"這一基礎但關鍵的問題。

     • 會話統計

       • 頂部計數卡片將工具調用按行為類型拆解為命令執行、後台進程、網頁請求、通訊工具、檔案讀寫等維度，提供整體行為構成的快速快照。其中調用異常單獨列出，便於第一時間判斷系統穩定性。

       • 會話統計表以 Session 為粒度展開，記錄每個會話在各行為維度上的調用量。截圖中首行 Session 的工具調用總數達 1925 次，其中命令執行 1364 次、檔案讀寫 561 次，與其他 Session 相比量級懸殊，此類異常活躍的 Session 往往值得優先審查。表格按最後活躍時間排序，結合各維度調用分布，可快速識別行為模式異常的會話。

     • 工具調用量統計和錯誤分析

       • 工具調用是 Agent 與外部世界互動的唯一通道，其調用量與錯誤率的變化直接反映 Agent 的運行健康狀態。工具調用時間軸按工具類型分色展示各時間段的調用頻次構成，異常尖峰是排查問題的第一入口，結合工具類型的構成變化，可快速判斷是哪類操作驅動了調用激增。錯誤率趨勢圖與調用量時間軸共用時間軸。錯誤率高峰不一定與調用量高峰重合，兩者的時間差往往能揭示問題的真實來源：是某類工具在特定時段持續失敗，還是某次任務引入了異常的調用模式。

       • 全量工具調用日誌則提供每次調用的協議錯誤、執行狀態與返回內容，支援從趨勢異常快速下鑽至具體失敗調用，定位根因。

     • 外部互動

       • 外部互動記錄 Agent 在運行過程中發起的所有對外行為，包括 API 呼叫、網頁訪問、訊息發送、郵件外發等，按會話、工具名與互動類型分類呈現。

       • 對於 Agent 而言，外部互動既是完成任務的必要手段，也是潛在的風險出口。全量記錄外部互動行為，一方面協助團隊掌握 Agent 的實際能力邊界與使用習慣，另一方面在出現異常時提供完整的行為上下文，支援跨工具、跨會話的關聯分析與溯源。

步驟三：自訂可觀測資料探索

內建大盤提供的是通用維度審計與觀測視圖。在實際安全營運中，大盤往往是“發現問題”的起點而非終點——當審計大盤標記出一個高風險會話、Token 趨勢圖出現異常尖峰、或運行指標警示觸發時，往往需要進一步從統計概覽下鑽到具體事件，還原完整的行為鏈並確認根因。SLS 的查詢分析引擎為這一過程提供了靈活的自訂探索能力。

日誌資料模型：自訂分析的基礎

自訂探索的前提是理解資料結構。SLS 接入方案已根據審計分析需求預建索引，使用者無需額外配置即可直接查詢。以下兩類日誌構成了自訂分析的核心資料來源：

• Session 日誌 — 記錄 Agent 的完整業務行為，是安全審計與成本分析的主要依據。即在步驟一：日誌接入（以 Session 日誌為例）中接入的日誌。

  欄位路徑	類型	審計分析用途
  __tag__:__session_id__	text	會話唯一標識，按會話隔離與彙總的關鍵字段
  type	text	項目類型：session（會話中繼資料）/ message（對話訊息）/ compaction（上下文壓縮摘要），過濾出可審計的對話記錄
  message.role	text	訊息角色：user（使用者輸入）/ assistant（模型響應）/ toolResult（工具返回），定位行為主體
  message.content	text	訊息本文，涵蓋使用者輸入、模型輸出與工具參數/傳回值，支撐注入檢測、敏感性資料匹配與全文檢索索引
  message.provider message.model	text	模型提供方與模型名稱，用於成本分析與按模型維度行為統計
  message.usage.totalTokens message.usage.cost.total	long / double	Token 用量與估算成本，用於異常消耗檢測與會話級成本排序
  message.stopReason	text	響應終止原因：stop（正常結束）、toolUse（觸發工具調用，下一條通常為 toolResult）、error / aborted / timeout（異常終止），篩選異常會話的關鍵字段
  message.toolName message.isError	text / bool	工具調用名稱與執行狀態，配合 toolResult 角色做工具級審計
  id、parentId	text	條目 ID 與父 ID，用於構建對話樹、還原訊息順序；session 類型條目的 id 即為 sessionId
  timestamp	text	事件時間戳記，用於時間視窗過濾、排序與警示範圍界定

• Runtime 日誌 — 記錄網關與各子系統的運行狀態，是排障與系統健康分析的資料基礎。

  說明

  選擇OpenClaw-運行時日誌卡片並參考步驟一：日誌接入（以 Session 日誌為例）進行接入。

  欄位路徑	類型	審計分析用途
  _meta.logLevelName	text	記錄層級（TRACE / DEBUG / INFO / WARN / ERROR / FATAL），聚焦 ERROR 與 FATAL 做異常排查
  _meta.path	text	源碼檔案路徑與行號，精確關聯代碼位置，便於堆棧分析
  數字鍵 "0"	object（JSON）	結構化上下文，通常包含 subsystem 欄位（如 gateway / channels / telegram / plugins）
  數字鍵 "1" 及後續	text	日誌訊息本文與堆棧內容，支援全文檢索索引與關鍵字匹配

會話級下鑽：從高風險會話到完整行為鏈

典型情境： 審計大盤的“高風險會話”列表標記了一個高危 Session，安全團隊需要還原該會話的完整互動過程，確認威脅是否屬實。

多執行個體部署環境下，各 OpenClaw 執行個體的日誌集中寫入同一 SLS Logstore。自訂探索的第一步是按 Session ID 隔離，將視野收斂到單個會話，明確“誰在何時觸發了哪些請求、調用了哪些工具、模型如何響應”，為合規舉證提供清晰邊界。

1. 登入Log Service控制台，在Project列表中選擇目標Project。

2. 在日誌存儲中目標LogStore中通過查詢 / 剖析進行資料探索，使用* and __tag__:__session_id__:<Session_Id>進行過濾，替換<Session_Id>為真實Session ID。

3. 完成會話過濾後，在原始日誌的原始頁簽下，找到目標日誌，單擊表徵圖，可進行上下文預覽，按原始順序還原該會話內的完整行為鏈——使用者輸入、模型推理、工具調用請求、工具執行結果，先後關係一目瞭然。這一能力在審計情境中尤為關鍵：它不僅能協助識別異常調用順序（如敏感檔案讀取緊接外發操作），還為安全事件的複現與證據留存提供了完整的上下文視圖。

運行時排障：關鍵詞檢索與彙總分析

典型情境： 運行指標大盤警示提示錯誤率突增，需要從海量 Runtime 日誌中快速定位故障模組與根因。

SLS 支援全文檢索索引與結構化欄位檢索的組合，配合時間範圍可逐層收斂排查範圍。典型的排障路徑分為兩步——先縮小範圍，再量化分布：

第一步：逐層過濾，鎖定問題

1. 按記錄層級過濾：使用 _meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL 過濾所有錯誤與警告日誌，將注意力集中到例外狀況事件。

2. 按子系統下鑽：在錯誤記錄檔中疊加欄位條件，例如 0.subsystem: plugins，則分析語句為(_meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL) and 0.subsystem: plugins，將範圍收斂到具體子系統，兩步過濾即可快速定位到錯誤記錄檔。

第二步：SQL 彙總，量化全域分布

關鍵詞篩選定位的是單條事件，而 SQL 彙總分析則將單條日誌上升為全域統計視圖。例如，對 subsystem 欄位做分組彙總，則分析語句為_meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL | select "0.subsystem" as subsystem, count(1) as c group by subsystem，可直觀呈現各子系統的錯誤分布，快速識別集中性異常，為進一步排查指明方向。