你所需要的只是 Wide Events，而不是“指标、日志和追踪”
“wide events” 的支持者——即富结构化、高基数的事件记录——认为它们可以把日志、指标和追踪统一到一个更灵活的可观测性模型中。评论者普遍认为，这种方法类似于结构化日志加上强大的查询能力，但也强调在规模化场景下存储和索引如此详细的数据成本很高，因此必须在采样、模式设计以及 Kafka、Elasticsearch、ClickHouse 或专用时序数据库等存储后端之间做权衡。许多人最终认为，wide events 对调试和探索性分析非常有价值，但最好与传统、更便宜的指标以及对数据量、隐私和团队实践的严格控制结合使用。
“wide events”相对于日志、追踪和指标是什么
- 很多评论者将“wide events”与结构化日志等同起来：即可以表示指标、跨度和追踪的键值记录（通常是 JSON）。
- 可以通过带有 trace/span ID 的事件日志重建追踪；指标可以被视为一种事件“测量”。
- 也有人认为“wide events”这个术语主要强调的是：包含大量上下文字段，并使用针对多列优化的存储。
wide events 的感知收益
- 将日志、追踪和指标统一到一个概念模型和后端中。
- 对“未知的未知”非常有用：可快速进行临时探索、跨维度关联，以及调试复杂故障。
- 如果埋点得当，仅靠日志也能产出指标和追踪，并支持强大的取证式调试。
成本、规模与基数问题
- 对成本存在很强的怀疑：以规模化方式存储原始、高基数事件，尤其是使用厂商方案时，被描述为“真的很贵”，对较小组织来说有时甚至是过度设计。
- 有些人表示在非巨型规模下，使用 Kafka + Elasticsearch、ELK、ClickHouse 或自建工具的 wide-event 系统取得了成功，但也承认硬件和运维成本存在。
- 也有人指出，列式存储和时序数据库可以缓解成本，但并不能消除围绕索引和基数的权衡。
采样：必要性与争议
- wide-event 支持者高度依赖采样（通常是动态的 / 按 trace 采样），以在保留丰富上下文的同时控制成本。
- 另一些人称遥测采样是“悲剧”或“胡说”，认为你根本不应该需要采样，或者采样带来的噪声和偏差会损害准确性。
- 折中观点：对成功、均匀的流量大量采样；对错误/慢路径保留全部数据。
指标 vs wide events
- 指标因其极低成本、长保留周期，以及在计数和 SLI 方面的准确性而受到称赞，尤其是在高吞吐场景下。
- 许多人认为 wide events 并不能取代指标；二者是互补的。指标更适合告警和长期趋势；事件/日志更适合深入排查。
- 有人提到 exemplars 和 span-metrics 作为混合方案：用特定 wide events/追踪链接增强指标。
实现模式和工具
- 建议的技术栈包括：Kafka + ES、基于 ClickHouse 的系统、类似 Loki 的日志架构、TSDB（Prometheus、VictoriaMetrics、QuestDB）、OpenTelemetry + Tempo/Loki/Prometheus，以及适合小型部署的 PostgreSQL JSONB。
- 多位评论者强调了倒排索引系统（Elasticsearch、Splunk）与适用于 PB 级遥测的追加写入/列式方案之间的差异。
组织、UX 与数据质量问题
- 工具可用性和用于探索性查询的简单 UI 被视为至关重要；原始查询语言虽然强大，但对许多用户而言是门槛。
- 将事件流过度共享为“API”会给下游带来脆弱依赖和模式变更痛苦。
- 对厂商围绕“日志都是垃圾”或“停止采样”等营销说法持怀疑态度。
- 也有人担心会不小心把 PII 记录进大范围可观测性存储，并指出需要防护措施。