驗證事件攝取和架構

接受的 API 請求並不是儀器檢查的結束。在將事件複製到更多路由、工作人員或服務之前，請驗證結果資料表和行。

此頁面假設您從 傳送您的第一個結構化事件 傳送了合成 api_request_completed 事件。

找到桌子

開啟您的 Telemetry 團隊，選擇 表格，然後開啟 api_request_completed。如果該資料表不存在：

1. 確認 API 請求返回成功回應。
2. 確認金鑰屬於目標團隊並且具有可寫範圍。
3. 檢查規範化後的確切資料表名。
4. 使用新的合成 request_id 重試一次。
5. 在更改架構之前遵循 事件攝取故障排除。

避免在沒有新識別符號的情況下重複傳送同一事件；重試可能會使以後的計數變得不明確。

檢查推斷的架構

合成的 API 範例應公開類似於以下內容的欄位：

如果某個重要欄位的型別錯誤，請在傳送產量之前停止並修復生產者。從數字更改為任意文字的欄位可能會使儲存的 SQL 和圖表更難以推理。

檢查確切的行

使用 Samples或Table 檢視並找到 request_id = req_demo_001。確認：

• 該行屬於預期的環境和版本。
• latency_ms 是 184，而不是 0.184 或 184000。
• 該路線不包含真實的報告或帳戶識別符號。
• 不包含授權標頭、cookie、請求正文、秘密、提示或私人客戶內容。
• 生成的時間與傳送視窗匹配。

預期行是事件契約有效的證據。它不是效能基準或代表性的生產分佈。

透過API驗證

您還可以透過程式設計方式檢查表和模式：

curl https://api.telemetry.sh/tables \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

然後請求資料表架構：

curl https://api.telemetry.sh/tables/api_request_completed/schema \
  -H "Authorization: Bearer $TELEMETRY_API_KEY"

使用可讀金鑰進行自動化驗證。 表格 API 記錄分頁、規範化、保留和模式回應。

記錄合約

在擴充套件儀器之前，寫下：

• 事件名稱和業務粒度。
• 必填和可選欄位。
• 欄位型別和單位。
• 允許的狀態和錯誤類別。
• 同一性和相關性欄位。
• 禁止的欄位。
• 所有者和預期保留期限。

繼續 編寫您的第一個 SQL 查詢。有關架構更改策略，請參閱 模式演化。