當日誌量增長到人工無法逐條排查時，需要一種機制主動發現尚未預先定義的異常變化。日誌智能巡檢通過 STAROps 數字員工周期性分析目標 Logstore，自動識別新增記錄模式、異常分布、指標變化和潛在風險，適用於應用錯誤、訪問日誌、業務狀態、效能變化和審計操作等情境。
日誌警示適合持續監控已經明確的問題；日誌智能巡檢更適合發現尚未預先定義的變化。兩者可以同時使用。
功能優勢
日誌智能巡檢通過周期性分析、自動下探和持續跟蹤，將海量日誌轉化為可複核的問題線索，主要優勢如下：
主動發現未定義的變化：無需預先配置錯誤碼、關鍵詞和固定閾值，持續識別新增記錄模式、分布位移、指標突變和長尾異常。
面向海量日誌分析：在資料側完成日誌聚類、基準比較和維度下探，以整體分布為依據，降低抽樣遺漏和局部樣本誤判的風險。
自動收斂問題範圍：Agent 根據分析結果動態選擇後續查詢，從異常訊號逐步定位到服務、版本、Region、使用者等具體範圍，並保留對照基準和查詢證據。
持續跟蹤並減少打擾：按周期更新問題狀態，區分新增、惡化、複發和恢複；利用已確認的業務語義和已知噪音最佳化後續巡檢，只在出現值得關注的變化時通知。
知識注入與多源分析：通過 Skill 補充商務規則、領域經驗和排查方法，通過 UModel 描述實體關聯、欄位語義，使 Agent 能夠關聯日誌、指標、Trace 等多來源資料進行綜合分析。對於具有明確業務語義或固定排查經驗的日誌情境，可通過自訂 Skill 進一步提升巡檢品質。
使用前準備
開始前，確認以下條件已滿足：
已擁有目標 Project 和 Logstore 的查詢許可權。
Logstore 已開啟索引，能夠正常查詢日誌。
日誌中存在可用於分析的欄位，例如
status、request_time、request_uri、region或version。日誌時間範圍內有可比較的資料；建立或資料量過少的 Logstore 可能無法形成有效基準。
如需接收通知，已準備連絡人、機器人或 Webhook 通知對象。
智能巡檢由 STAROps 提供，頁面明確提示使用會產生費用，請按實際需要設定執行循環。
本指南以華東 2（上海）地區的 charts-demo/charts-demo Logstore 為例。樣本日誌為 Nginx 訪問日誌，包含 status、request_time、request_uri 等欄位。
一、進入智能巡檢
登入Log Service控制台，進入目標 Project。
在左側日誌庫列表中選擇目標 LogStore。
在查詢分析頁面確認目前時間範圍內能夠正常查詢到日誌。
在查詢結果地區切換到智能巡檢頁簽。
進入後，頁面會展示當前 Logstore 下已有的巡檢任務。任務卡片中可以看到任務名稱、建立人、更新時間以及最近幾次執行記錄。請不要直接修改他人建立的任務；需要試用時，建議建立帶有明確測試標識的獨立任務。
二、建立巡檢任務
在智能巡檢工作清單中單擊建立任務。
填寫任務名稱。建議同時包含業務範圍和日誌類型，例如“支付網關 Nginx 日誌巡檢”。
設定計劃時間。樣本頁面支援按小時執行並指定每小時的分鐘數。
選擇執行任務的數字員工。
填寫巡檢要求。首次建立可以唯寫最重要的目標，系統會結合日誌特徵產生初始計劃。
按需選擇連絡人、機器人或 Webhook。沒有通知對象也可以建立，後續再配置。
檢查費用提示，確認後單擊立即建立。
建立成功後，新任務會顯示在列表頂部。剛建立時顯示“暫無執行記錄”，屬於正常狀態。
三、首次運行與查看巡檢結果
單擊任務卡片後，控制台會在新標籤頁開啟 STAROps 長期任務詳情。詳情頁提供三個核心頁簽：
對話：查看任務規划過程、補充業務語義或提出新的下探要求。
執行：查看周期執行記錄，也可以按需手動觸發一次執行。
報告：查看巡檢完成後產生的報告。
新任務尚未完成第一次執行時，執行和報告的數量為 0。首次執行完成後，再進入相應頁簽查看分析範圍、查詢證據、異常維度、Finding 和不確定性說明。
立即執行會額外發起一次巡檢，可能產生費用。只是檢查任務配置時，不需要單擊。
從空任務開始第一次巡檢
首次使用建議從一個沒有歷史執行、沒有歷史報告、沒有現成巡檢計劃的空任務開始。此時頁面頂部通常顯示“執行 0”“報告 0”，右側子任務規劃卡片會顯示播放按鈕。
空任務第一次運行時，系統不只是查詢一次日誌，還會自動完成以下初始化工作：
讀取任務中配置的地區、Project、Logstore、執行循環和補充要求。
識別日誌欄位和資料特徵，產生初始 Source Profile。
建立並校正巡檢計劃。
執行第一輪確定性檢查和異常下鑽。
產生首份巡檢報告，作為後續周期巡檢的比較基準。
主動運行空任務
如果任務建立後沒有自動開始，可在右側子任務規劃地區單擊播放表徵圖，或單擊子任務上的立即執行。
系統會彈出“確定立即執行該子任務嗎？”確認框，並提示確認後將建立並開啟一次新的執行會話。確認任務和資料範圍無誤後，單擊立即執行。
立即執行會產生一次實際的智能巡檢運行；如果頁面提示會產生費用，請先確認費用和資料範圍。
等待首次執行完成
單擊立即執行後，頁面右側會開啟本次執行會話。首次運行需要建立 Profile 和巡檢計劃，耗時通常會比後續周期執行更長。
執行過程中可看到“建立 Profile 和 InspectionPlan”“執行確定性檢查”“調查異常並下鑽”“產生巡檢報告”等階段。保持當前任務為“活躍”即可，不需要反覆單擊播放按鈕。
如果長時間沒有結果，可先查看執行會話中的失敗提示或查詢錯誤，再檢查地區、Project、Logstore、索引和查詢許可權是否正確。
查看執行記錄
單擊頁面頂部的執行。
計劃觸發的運行可在執行列表中查看開始時間、完成狀態和運行摘要；手動單擊立即執行時，可先在右側執行會話中查看即時進度。
執行列表出現記錄後，單擊記錄可重新查看該次運行；如果列表暫未出現記錄，不影響已經產生的報告，可直接轉到報告頁確認產物。
執行頁適合排查任務有沒有開始、是否完成、執行中斷在哪裡；它不是最終結論頁。
查看巡檢報告
單擊頁面頂部的報告。
在左側報告列表中展開月份和日期目錄，選擇需要查看的巡檢報告。
開啟報告詳情。
報告目錄有時不會立即重新整理。可先切換一次頁簽或重新整理任務頁面，再在報告頁展開月份、日期目錄；如果執行會話明確失敗，則先處理失敗原因後重新運行。
四、修改任務
修改任務名稱
在任務詳情頁單擊右上方更多。
選擇設定。
在長期任務名稱輸入框中修改名稱。
單擊輸入框外部完成儲存。
重新整理頁面，確認頁面標題仍顯示新名稱。
設定面板還會顯示任務 ID、建立時間、觸發方式和通知對象。任務 ID 可用於問題定位，請勿隨意修改或拼接。
補充巡檢要求
首次執行產生巡檢計劃後，可以在對話頁繼續描述需求，讓 STAROps 調整後續巡檢計劃。例如：
補充巡檢要求：將 /healthz 視為健全狀態檢查流量；
同時重點關注 upstream_response_time，
以及異常是否集中在特定來源地址或 User-Agent。發送後應等待 STAROps 返回計劃調整結果，再檢查後續執行是否包含新增檢查項。
新任務尚未完成首次執行時，還沒有可修改的巡檢計劃。此時 STAROps 可能要求補充 Project、Logstore、欄位和執行頻率等資訊。建議先等待首次執行完成，再提交計劃調整要求。
五、閱讀巡檢報告
報告產生後，建議依次確認以下內容，重點關注巡檢視窗、總體結論、異常發現、證據和後續建議：
分析範圍：當前視窗、對照視窗和實際查詢範圍是否符合預期。
巡檢計劃：本輪實際檢查了哪些指標、欄位和記錄模式。
問題結論：是否發現新增異常、問題惡化、問題複發或影響範圍擴大。
資料證據：結論由哪些日誌查詢、聚類結果或維度下探結果支援。
影響範圍：問題集中在哪些 URI、狀態代碼、來源地址、版本或其他維度。
不確定性：資料不足、基準不可比或欄位缺失時，報告會說明當前無法確認的部分。
指標變化不一定等於故障。例如慢介面流量佔比上升會推高整體 p90，但各介面自身的效能可能沒有惡化。應結合維度下探結果判斷變化是效能退化，還是流量組成變化。
報告讀取順序
建議按下面的順序閱讀：
先確認範圍：檢查 Project、Logstore、Region、巡檢視窗和對照視窗，避免把錯誤資料來源當成業務結論。
再看總體結論：先判斷“正常、需關注或異常”，並確認是否需要立即行動。
比較核心變化：關注總請求量、錯誤率、5xx 數量，以及 request_time 的 p50、p90、p99 與前一小時、昨日同期的差異。
查看關鍵發現和證據：確認異常集中在哪些 status、request_uri、request_method、來源地址或 User-Agent，並核對查詢時段和樣本數量。
落實後續行動：把需要持續跟蹤、需要應用側確認或需要配置警示的事項轉成明確負責人和截止時間。
本次空任務產生的第一份報告顯示：
巡檢狀態為“正常”。
當前視窗 HTTP 5xx 錯誤率為 0.39%（99 次），較前一小時和昨日同期下降。
request_time 的 p50、p90、p99 在三個視窗中保持一致。
5xx 沒有集中在單個 URI 或 Method，報告建議後續繼續跟蹤 500/501 比例和長尾變化。
這些結論僅代表該次巡檢視窗。後續應結合連續多次報告判斷趨勢，不應只憑一次結果下結論。
報告內容由 AI 產生，適合輔助發現問題和縮小排查範圍；涉及變更、擴容、熔斷等生產操作時，仍需結合原始日誌、監控指標和業務上下文進行人工複核。
六、通知配置
巡檢周期和通知頻率是兩件事。任務可以每小時執行，但正常結果不必每小時通知。建議僅在以下情況通知：
發現新的高風險問題。
已有問題明顯惡化。
問題恢複後再次複發。
影響範圍明顯擴大。
需要人工確認業務語義或處置方式。
如果建立時沒有選擇通知對象，可以在任務提示或設定頁中進入通知管理，後續再新增連絡人...、機器人或 Webhook。
七、持續最佳化建議
首次運行先確認資料範圍、欄位識別和基準是否正確。
將業務錯誤碼、欄位含義和正常行為告訴巡檢 Agent。
標記健全狀態檢查、壓測、機器人請求等已知噪音，並說明適用範圍。
對真實問題補充根因和處置經驗，供後續巡檢複用。
將通知設定為問題觸發，避免正常周期重複打擾值班人員。
日誌結構、版本欄位或營運目標變化後，重新檢查巡檢計劃。
自訂 Skill（可選）
對於具有明確業務語義、專用欄位或固定排查經驗的日誌情境，可以建立自訂 Skill，將團隊知識補充給執行巡檢的數字員工，提升巡檢結果的準確性、一致性和可複核性。建議在自訂 Skill 中沉澱以下內容：
欄位和狀態語義：說明業務錯誤碼、狀態欄位、版本、Region、租戶、使用者等欄位的含義。
正常行為與已知噪音：定義健全狀態檢查、壓測流量、機器人請求、定時任務等無需升級的問題，並寫清適用範圍。
異常判斷方法：規定需要重點比較的指標、基準視窗、聚類欄位和異常維度。
下鑽排查流程：把團隊常用的查詢語句、診斷順序、關聯條件和根因確認方法固化為標準步驟。
報告與證據要求：約定報告必須保留的時間範圍、對照資料、查詢證據、不確定性和後續行動。
STAROps 的自訂 Skill 使用 Markdown 編寫。技能設計除 SKILL.md 指令外，還可以包含 references/ 目錄中的參考資料和 scripts/ 目錄中的輔助指令碼。建立完成後無需安裝，可在使用範圍中關聯到執行日誌巡檢的數字員工。
建議先建立草稿，僅為測試數字員工啟用使用草稿，通過一次手動巡檢驗證欄位理解、查詢範圍和報告結果；確認無誤後再發布正式版本，供所有已關聯的數字員工使用。
操作入口：STAROps 控制台 > 技能中心 > 自訂技能 > 建立自訂 Skill。
自訂 Skill 建立後會對主帳號下的使用者可見並可被掛載使用。正式建立或發布前，應檢查內容中是否包含帳號憑據、個人資訊、內部地址等敏感資訊。
常見問題
為什麼新任務顯示“暫無執行記錄”？
任務剛建立時還沒有到計劃執行時間。可以等待下一個計劃時間；如確有需要，也可以在瞭解費用影響後單擊立即執行。
為什麼第一次巡檢沒有發現問題？
可能是當前視窗沒有顯著變化，也可能是日誌量不足、歷史視窗不可比或關鍵字段尚未建立索引。先檢查報告中的資料範圍和不確定性說明。
如何減少週期性通知？
將通知條件設定為新增問題、問題惡化、問題複發或影響範圍明顯擴大。對沒有變化的問題保留報告，但不必每個周期發送通知。
如何減少已知噪音？
在巡檢要求中寫清楚噪音內容、判斷依據和適用範圍。例如說明 /healthz 是健全狀態檢查，或某個機器人帳號只在指定時段執行授權操作。不要唯寫“忽略這個問題”，否則可能誤傷其他真實異常。
修改巡檢要求後何時生效？
計劃調整通常應用於後續巡檢。發送修改要求後，應先確認 STAROps 已完成計劃更新，再在下一次運行中檢查新增檢查項是否生效。