结构化事件与文本日志
文本日志描述了程序做了什么。结构化事件记录有关工作流程的稳定事实。两者都很有用，但它们针对不同的问题进行了优化。
文本日志非常适合本地诊断：启动消息、意外分支、库输出和堆栈跟踪。它的自由格式信息为狭窄时间范围内的阅读者保留了上下文。当必须在多个请求中重复回答同一问题时，结构化事件更适合：按路线的失败率、按模型的成本、按源的激活或按队列的重试。
查询差异
假设应用程序写入 invoice sync failed for team_123 in 940ms。搜索可以找到该句子，但图表必须首先提取团队、持续时间和结果。有了结构化字段，查询就可以直接操作：
SELECT
error_type,
COUNT(*) AS failures,
approx_percentile_cont(duration_ms, 0.95) AS p95_duration_ms
FROM billing_syncs
WHERE status = 'failed'
AND timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY error_type
ORDER BY failures DESC;
事件契约使字段类型和类别变得明确。它还可以防止微小的措辞更改破坏已保存的查询。
两者同时使用，无需重复所有内容
保留详细的、短期的诊断日志，以便工程师调查事件。在工作流边界发出一组较小的持久结构化事件。使用请求 ID、跟踪 ID、作业 ID 或其他安全相关值将两者链接起来。不要将完整的堆栈跟踪或请求正文复制到每个分析事件中。
一个事件不会因为它是 JSON 而自动变得更好。一堆不断变化的键和任意字符串仍然很难分析。该价值来自经过深思熟虑的合同：稳定名称、记录字段、受控类别以及审查更改的所有者。
实用的选择规则
当您希望根据数据聚合、比较、告警或构建仪表板时，请选择结构化事件。当主要用途是在特定调查期间阅读详细上下文时，选择文本日志。如果两者都需要，请发出共享关联标识符的一个紧凑事件和一个诊断记录。