设计事件架构
事件架构是发出数据的代码与使用数据的每个查询、仪表板、告警或导出之间的契约。仪器仪表前的少量设计可以防止数月的模糊数据。
命名结果
使用稳定的名词和过去时结果，例如 api_request_completed、job_failed 或 subscription_renewed。避免频繁更改的 UI 措辞。当成功和失败共享相同的有用字段时，具有受控 status 值的一个事件通常比单独的表更容易比较。
从问题中选择字段
对于每个计划的问题，确定操作：
- 过滤器需要环境、功能、路线或状态等字段。
- 组需要受控维度，例如模型、版本或错误类型。
- 计算需要具有明确单位的键入测量值。
- 调查需要连接相关事件的安全标识符。
记录 latency_ms，而不是 latency。将数值存储为数字，将布尔值存储为布尔值。使用 UTC 时间戳。优先选择 route_template 而不是原始 URL，优先选择 error_type 而不是无界异常消息。
记录标识符是否代表个人、帐户、请求或工作。如果字段可能包含敏感数据，请在创建事件之前忽略或转换它。
改变计划
附加更改通常是最安全的：查询可以容忍新的可为空字段。重命名字段或更改其类型可能会破坏每个消费者。当语义发生重大变化时，添加 event_version，编写处理迁移窗口的查询，并仅在消费者移动后删除旧形状。
保留具有代表性的成功、失败、重试和超时示例以进行验证。在发布仪器更改之前运行重要的 SQL。仅当真实分支生成的值与其记录的含义相匹配时，模式才是完整的。
审查清单
询问事件是否有明确的所有者、一组有界的状态值、明确的单位、安全标识符和保留需求。确认至少有一个实际查询使用每个字段。仅仅因为它们可用而删除包含的值。