共同事件契約
使這些查詢可重用的欄位
- timestamp_utc、event_name、源、環境和 schema_version
- correlation_id、request_id、user_id、team_id 和釋放
- 輸入狀態、持續時間、金額、計數和分類錯誤欄位
SQL 之前的定義
查詢無法為您做出的決定
- 1使用一個事件來表示已完成的工作單元，而不是使用許多部分訊息。
- 2保留型別化欄位和顯式單位，以便 SQL 保持可移植性。
- 3在活動合約之外保留秘密和原始私人內容。
推薦順序
先建立檢測，然後診斷
分析模式
讓結果解釋決定
發出一個規範的完成事件
記錄已完成的工作單元的輸入、結果、持續時間、穩定識別符號和分類的故障上下文。
使用型別化、有界的尺寸
優先選擇顯式數字、布林值、單位和命名類別，而不是需要解析或建立無界組的值。
保持相關性經過深思熟慮
僅在連線已定義問題所需的事件時使用請求、執行、交付、帳戶或作業識別符號。
完整的查詢範例
複製查詢，然後驗證假設
入門service_heartbeats
檢測丟失的服務心跳
查詢在故障事件出現之前停止報告的服務、工作人員或計劃任務。
哪些預期遙測源已停止傳送心跳？
檢視 SQL 和結果中級agent_events
查詢巢狀 AI 工具呼叫事件
過濾點巢狀欄位並對失敗的工具進行排名，而無需展平原始事件負載。
哪些人工智慧工具和參數與失敗次數最多的呼叫相關？
檢視 SQL 和結果高階api_requests
使用滾動基線檢測錯誤率峰值
將每小時 API 錯誤率與滾動七桶平均值進行比較，而不是依賴一個永久閾值。
哪些每小時錯誤率遠高於其最近的基線？
檢視 SQL 和結果高階workflow_timeline_events
重建相關的工作流程時間線
根據共享工作流程識別符號重建有序的跨服務工作流程步驟和經過的時間。
在最近一次失敗的工作流程中，按順序發生了什麼？
檢視 SQL 和結果