設計事件架構
事件架構是發出資料的程式碼與使用資料的每個查詢、儀表板、警示或匯出之間的契約。儀器儀資料表前的少量設計可以防止數月的模糊資料。
命名結果
使用穩定的名詞和過去時結果，例如 api_request_completed、job_failed 或 subscription_renewed。避免頻繁更改的 UI 措辭。當成功和失敗共享相同的有用欄位時，具有受控 status 值的一個事件通常比單獨的資料表更容易比較。
從問題中選擇欄位
對於每個計劃的問題，確定操作：
- 過濾器需要環境、功能、路線或狀態等欄位。
- 組需要受控維度，例如模型、版本或錯誤型別。
- 計算需要具有明確單位的鍵入測量值。
- 調查需要連線相關事件的安全識別符號。
記錄 latency_ms，而不是 latency。將數值儲存為數字，將布林值儲存為布林值。使用 UTC 時間戳。優先選擇 route_template 而不是原始 URL，優先選擇 error_type 而不是無界異常訊息。
記錄識別符號是否代表個人、帳戶、請求或工作。如果欄位可能包含敏感資料，請在建立事件之前忽略或轉換它。
改變計劃
附加更改通常是最安全的：查詢可以容忍新的可為空欄位。重新命名欄位或更改其型別可能會破壞每個消費者。當語義發生重大變化時，新增 event_version，編寫處理遷移視窗的查詢，並僅在消費者移動後刪除舊形狀。
保留具有代表性的成功、失敗、重試和超時範例以進行驗證。在發布儀器更改之前執行重要的 SQL。僅當真實分支生成的值與其記錄的含義相匹配時，模式才是完整的。
審查清單
詢問事件是否有明確的所有者、一組有界的狀態值、明確的單位、安全識別符號和保留需求。確認至少有一個實際查詢使用每個欄位。僅僅因為它們可用而刪除包含的值。