共同事件契約
使這些查詢可重用的欄位
- timestamp_utc、received_at、event_id、event_name 和 schema_version
- 來源、環境、producer_version、必填業務欄位
- ingestion_status、validation_error 和重複結果
SQL 之前的定義
查詢無法為您做出的決定
- 1分別為每個源定義預期事件量和新鮮度。
- 2在嘗試重複資料刪除之前選擇穩定的事件識別符號。
- 3僅在真正需要欄位的情況下測量欄位完整性。
推薦順序
先建立檢測，然後診斷
分析模式
讓結果解釋決定
監控遙測本身
除了它們支援的產品指標之外，還將新鮮度、完整性、獨特性和模式採用視為一流的訊號。
將事件時間與接收時間分開
比較工作發生的時間和到達的時間，以暴露延遲的客戶、回填和阻塞的攝取。
按生產商細分
按源、環境、架構版本或版本分解迴歸，以便所有者和部署邊界清晰。
完整的查詢範例
複製查詢，然後驗證假設
入門telemetry_events
測量事件攝取新鮮度
查詢停止傳送資料或比發生時間晚得多的事件源。
哪些生產事件源現在已過時或已延遲？
檢視 SQL 和結果入門telemetry_events
查詢重複的事件 ID
識別多次傳遞的事件識別符號並衡量重複處理是否有效。
哪些事件 ID 被多次接收？
檢視 SQL 和結果入門product_events
測量必填欄位空率
查詢所需帳戶、狀態或相關欄位正在消失的事件合約。
哪些事件名稱的帳戶識別符號丟失率不可接受？
檢視 SQL 和結果中級ingestion_events
測量遲到事件
按源測量事件傳遞延遲，並識別傳送過時或無序資料的生產者。
哪些事件生產者提供資料的時間足夠晚以至於扭曲了分析？
檢視 SQL 和結果入門product_events
追蹤事件架構版本採用情況
衡量生產者的模式版本部署，並查詢部署後仍保持活動狀態的舊事件合約。
哪些生產者仍然發布關鍵事件的舊版本？
檢視 SQL 和結果入門telemetry_ingestion_events
按事件名稱測量 Telemetry 音量
在更改保留或收集策略之前，按有效負載位元組、平均事件大小和拒絕率對事件型別進行排名。
哪些事件合約創造了最大的攝取量？
檢視 SQL 和結果