在工程生涯中，采用宽事件式的工具是最具影响力的变革之一，能收紧所有变更的反馈循环，使调试系统更简单，让原本可怕的系统更易管理。近期有很多关于“宽事件”含义及重要性的博客文章，如 Ivan Burmistrov 的All you need is Wide Events, not “Metrics, Logs and Traces”、Boris Tane 的Observability wide events 101、Charity Majors 的Is it time to version Observability? (Signs point to yes)。

简而言之，对于系统中的每个工作单元（通常是 HTTP 请求/响应，但不总是），发出一个包含该工作所有可收集信息的“事件”，可将“事件”替换为“日志行”或“跨度”。Charity Majors 近期以“Observability 2.0”之名推广此方法，虽不是新想法，但得到了新的关注，如 Brandur Leach 在 2016 年及 2019 年 Stripe 的相关文章中都有提及，AWS 也将其作为最佳实践推荐。

如何实现“宽事件”

1. 选择工具：需要用工具来检测代码（跟踪或结构化日志行）并发送到可查询和可视化的地方，推荐使用 OpenTelemetry 和 Honeycomb，也可使用 ElasticSearch 等日志搜索工具，要专注于掌握三种核心技术（可视化、分组、过滤）来筛选事件。
2. 编写中间件：使用 OpenTelemetry SDK 时可通过获取活动跨度来设置属性，但存在问题，可通过在上下文中保存对主跨度的引用解决，示例代码可参考这里，Heroku 有内部的 OpenTelemetry 分布可自动设置。

3. 添加到“主”跨度的信息：

   • 约定过滤：用main属性标识“宽事件”跨度，方便查询服务流量。
   • 服务元数据：添加服务相关信息，如服务名称、环境、所属团队、Slack 频道等，还可添加实例相关信息，如实例 ID、内存、CPU 等，无论使用何种平台都可获取有用信息。
   • 构建信息：将构建系统的信息添加到生产系统中，如版本、构建 ID、Git 哈希、部署触发信息等，在事故排查时非常有价值。
   • HTTP 信息：添加 HTTP 请求和响应的相关信息，如服务器地址、路径、请求方法、响应状态码等，还可解析User-Agent头为结构化数据，提取路由参数和查询参数。
   • 路由信息：添加 API 端点相关信息，如路由模式、路由参数、查询参数等，方便查询不同路由的性能。
   • 用户和客户信息：添加用户相关信息，如用户 ID、类型、认证方式、所属团队、组织 ID 等，对区分不同用户的流量很重要。
   • 速率限制：添加速率限制信息，如限制、剩余、已使用、重置时间等，方便排查速率限制相关问题。
   • 缓存：添加缓存相关信息，如缓存会话信息、功能标志缓存等。
   • 本地化信息：添加本地化选项信息，如语言方向、国家、货币等。
   • 正常运行时间：添加服务运行时间相关信息，如运行秒数、以 10 为底的对数等，有助于排查各种类型的问题。
   • 指标：添加系统指标信息，如内存、CPU 负载、垃圾回收次数等，可快速获取系统状态，但不建议设置警报。
   • 异步请求摘要：添加异步请求相关统计信息，如 HTTP 请求数、Postgres 查询数等，方便排查异步请求相关问题。
   • 采样：进行采样以控制数据量，工具会根据采样率计算，要跟踪每个跨度的采样率，相关文章有I was first introduced to this idea in the Scuba paper等。
   • 时间：将请求处理的各个重要环节的时间添加到主跨度中，方便查询和可视化。
   • 错误：添加错误信息，如错误类型、堆栈跟踪、预期错误等，方便排查错误。
   • 功能标志：添加功能标志信息，方便测试代码变更。
   • 重要事物的版本：添加运行时、框架、库等的版本信息，有助于排查问题。
   • 特定应用信息：添加应用特定的信息，如资产上传路径、与供应商的交易 ID 等。

注意事项

1. 应添加可能需要的数据，边际成本小，可根据数据量调整事件大小和采样率。
2. 热图很有用，能帮助发现异常和多模态分布。
3. 拥抱反馈循环，修改代码时添加遥测数据以查看影响，释放代码后检查结果。
4. 遵循语义约定和命名一致性，可先以获取数据为目标，后期再优化一致性。

常见反对意见

1. 是否有效：在多个生产系统中证明有效，能发现很多意想不到的问题。
2. 感觉不对：结构化数据是为机器读取设计，不是给人类看的，让机器人帮忙能提高效率。
3. 工作量大：实现全部内容工作量大，但即使实现简单子集也有价值，可将逻辑放入共享库。
4. 数据量和成本：与当前日志量比较，可通过采样控制成本，实时 OLAP 系统也在变得更便宜。
5. 重复数据：通过压缩等技术，实际数据量不大，如使用 DuckDB 压缩后文件很小，存储成本低。
6. 查询多个跨度：可通过 Honeycomb 过滤其他跨度的字段，但这较高级，应保持简单快速。
7. 是否需要指标：仍应生成高级指标，但可减少数量。