共同事件契约
使这些查询可重用的字段
- 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 和结果