可观测性2.0？还是只是日志的卷土重来？

快猫运营团队 2025-05-07 16:19:10

最近行业内讨论 Observability 2.0 又多起来了，怎么算是 2.0？如果我没记错，最原始的观点应该是 Honeycomb 的 CTO 提出来的。她说：三大支柱（指标、日志、链路追踪）时代是 Observability 1.0 时代，三类数据分散存储，不好统一分析，而 Observability 2.0 时代是三类数据统一存储，甚至不再归类为三类数据，而是统一归为“宽事件”数据，每个事件有很多字段和标签。

本文作者这个标题也是非常犀利：Observability 2.0? Or Just Logs All Over Again? 说，啥 Observability 2.0 呀，不就是给日志换了个名字吗！

本文作者也是位响当当的人物：Todd Persen，他是 Hydrolix 的 CTO，Hydrolix 是一个设计用于大规模实时和历史日志分析的流式数据湖。此前，他是 Era Software 的 CEO 和联合创始人，Era Software 创建了 EraSearch，这是一种针对 petabyte 规模的云原生存储产品。再之前，是 InfluxData（他们有个很有名的产品：InfluxDB）的联创和 CTO。

原文链接：https://thenewstack.io/observability-2-0-or-just-logs-all-over-again/

作者的核心观点可以用一句话来总结：日志的价值不仅仅是为了可观测性，如果日志是面向分析的，那就极大地扩展了其现在和未来的价值。 行业老炮应该一下子就 get 到作者的点了，无需继续阅读了，如果你还不太明白，继续往下看。

下面是原文的主要内容 👇👇👇

最近，很多人都在谈论 Observability 2.0 和从可观测性的三大支柱（或四大支柱，视谁的观点而定）向统一的真实来源转变：任意宽泛、结构化的日志事件。

如果我们简化一下，我们似乎又回到了起点——某种程度上是这样。最初，只有日志，而现在我们又回到了宽泛的日志（结构化、高维度时间序列事件）和比以往任何时候都多的日志。那么，我们是如何走到这一步的？我们究竟要去向何方？

三大支柱

三大支柱是日志、指标和跟踪。有人说还有第四支柱：事件。这样正好组成了一个巧妙的缩写：MELT（Metrics、Events、Logs、Traces） 🤣 随意吧。实际上，可观测性宇宙的基本构建块始终是日志。所谓的三大支柱、四大支柱，都是挺随意的叫法，核心问题还是：如何实时洞察海量、高基数的时间序列数据。

在 2010 年代初，可观测性首次兴起的时候，大型公司使用 Splunk，它在集中处理日志方面表现出色。值得一提的是，Splunk 在 2012 年 4 月上市时，年收入已经超过 1 亿美元。即使在那时，企业就已经对 Splunk 的高昂成本感到担忧，而大多数企业的日志数据量也已经大幅增加。

然后，由于日志数据难以快速做分析、聚合，于是，第一波可观测性浪潮兴起，大家都在想，有没有更好的数据格式、存储方式，不要像日志这么笨重，可以方便对大量数据做聚合分析呢。

为了解决这个问题，我们又增加了一个支柱，即指标。当我于 2012 年创立 InfluxData 时，时间序列数据库领域正在兴起，这将从 Graphite/Whisper 转向 InfluxDB、Prometheus、Timescale 和 Facebook 的 Gorilla 等工具。这些工具专门针对存储指标和执行聚合进行了优化，通过平均请求延迟和总错误等指标，可以为团队提供系统健康状况的全面视图。这种高度专注细分的解法，填补了传统日志管理系统中的空白。

但是你无法使用这些系统来搜索字符串或深入分析日志。虽然数值时间序列数据可以提供一个整体视图，但它缺乏足够的细节来进行根本原因分析，以便在问题出现时真正解决问题。而且在大多数情况下，这些系统通过创建汇总聚合并丢弃底层原始数据来应对高流量的问题。

分布式跟踪作为三大支柱之一，旨在解决分布式系统中的根因分析问题。Google 的 Dapper 论文于 2010 年发布，而基于 Dapper 论文的另一个早期分布式跟踪工具 Zipkin 则在 2012 年开源。分布式跟踪允许团队追踪应用程序中请求的流动，从而更容易地识别瓶颈和问题。

从高基数、高体积数据的角度来看，分布式跟踪本应帮助团队过滤掉噪音，深入到重要的细节中。但跟踪只能很好地解决一些特定的问题——而对于其他问题则效果不佳。它并不能帮助处理指标或日志。而对于处理高请求数量的系统来说，跟踪还会进一步增加数据量，产生更多的噪音。随机采样（只保留一定比例的跟踪）理论上可以解决这个问题，但这样你就再次失去了全分辨率可观测性的优势。

三根支柱可以给你深入系统内部的洞察。但尽管有所有创新和发展，基础仍然比较脆弱——因为没有任何一根支柱真正解决了问题。

三根支柱无法解决高基数问题

在过去 15 年中，随着可观测性解决方案似乎变得更加成熟，我们仍然看到客户在管理其可观测性资产方面遇到困难，尤其是在云原生架构的增长方面。所谓的“统一”可观测性解决方案带来了管理三大支柱的工具，但成本和复杂性仍然是主要的痛点。与此同时，数据量一直在增加，据 2023 年的数据显示，37%的企业每天摄入超过一太字节的日志数据。

传统的日志解决方案通常通过较短的保留窗口和分层存储来应对高数据量和基数的问题——这意味着数据要么在较短时间内被丢弃，要么存储在冻结的分层中，使其变得不可见。同时，其他时间序列或指标数据库会将高数据量的源数据聚合为指标，然后丢弃底层日志。

最终，跟踪会产生大量的数据，以至于大多数跟踪根本不会被存储。头部采样会保留一小部分跟踪，通常是随机的，而尾部采样允许更智能地过滤，但代价是处理效率降低。然后，跟踪通常会在短时间内被丢弃。

这里有一个共同的主题：虽然可观测性的所有支柱提供了理解并分析系统的方法，但它们都通过丢弃数据来处理高基数问题。如果你的系统规模较小且封闭，那么你可能还好——但在这种情况下，太多的可观测性工具可能就是过度了。对于可观测性真正要帮助的最大规模的系统，这三大支柱的成本太高，提供的价值也太少。

可观测性是基于系统输出来理解系统状态。丢弃输出，你就不再真正拥有可观测性。你只剩下三根摇摇欲坠的支柱、大量的复杂性和高昂的成本——对于拥有分布式系统的企业来说，你仍然没有获得承诺的真正可观测性。

解决高基数（和维度）问题

我们不需要重新发明更好的版本的离散度量、跟踪和日志工具。我们只需要一个工具来解决这三个问题。

这样的话，我们其实回到了起点。归根结底，这都是关于日志——广泛的结构化事件。换句话说，可观测性就是关于输出的，这些输出就是日志——度量和跟踪可以从结构化日志中推导出来。你只需要一个工具来应对高基数和高维度数据下的查询性能问题。

高基数

高基数数据包含许多唯一的值，换句话说，它结合了高体积和高唯一性。这使得数据更难压缩，导致存储中数据更多，查询时的计算密集型读取更多。我们可以将高体积和基数的问题大致归类为处理大数据的巨大挑战。

如我们所讨论的，大多数系统试图通过丢弃数据或降低其粒度来解决这个问题。我们将看到越来越多的平台使用 AI“智能”地决定哪些日志应丢弃和保留——换句话说，试图将信号与噪声区分开来。虽然 AI 工具对于检测模式和洞察力非常有用，但它们不应该只是另一个用来堂而皇之丢弃数据的借口。

答案是一个解决方案，旨在摄入、查询和分析大量日志数据，同时保持成本效益 —— 不丢弃底层原始数据。

高维度

为了使日志能够提供我们通常期望从分布式跟踪中获得的好处，它们需要能够保留所有必要的上下文。这包括用于逻辑分组和关联日志以及跟踪请求通过系统的上下文。

这就是“任意宽的结构化日志事件”发挥作用的地方。即使不添加这些额外的上下文，日志也可以具有高维度（宽，有很多属性）。我们见过有数千个字段的日志，即使今天的业务价值可能模糊不清，但如果数据科学团队明年需要它们，你从未保留它们，这可能会导致重大遗憾。

为了适应不同维度的需求，即使大多数用户不知道他们的日志字段是什么数据类型，你也需要一个具有灵活模式的解决方案，比如数据湖。有了灵活的模式，你的日志可以任意宽，具有任意维度，并且数据类型可以随时间变化。

为了确保在高维数据下实现高性能的分析，解决方案应该利用列式存储，这是在线分析处理解决方案（OLAP）的典型特征，同时采用灵活的索引格式以支持具有不同维度的字段。许多 OLAP 功能非常适合日志数据。例如，“写一次，读多次”的不可变方法可以确保日志保持为一个安全且不可更改的真相来源，同时还能提高分析性能。

实时分析的需求和场景是可观测性的超集

最终，我认为 Observability 2.0 并不是关于构建一个新的解决方案，而是回到可观测性的根本，并结合实时分析，实现高效、高 volume 的日志处理。当我们通过分析的视角来看待日志数据，而不是仅仅从可观测性的角度，我们可以极大地扩展其价值。

日志数据不仅仅是运维团队关注应用性能的工具，尽管这对关键任务来说非常重要。相反，它构成了整个组织更大范围可观测性图景的一部分。日志数据，以及一般的时间戳数据，提供了关于企业过去、现在和未来的基础故事。传统上在可观测性平台中孤立存在的真实用户监控数据可以为营销、广告和容量规划提供见解。交易日志可以帮助数据科学团队剔除欺诈行为。同时，安全团队可以使用相同的数据进行威胁狩猎，并发现高级持续威胁。数据集越大，其用于训练用于异常检测等场景的 AI/机器学习（ML）模型的潜在价值就越高。

多种数据孤岛式可观测性解决方案，成本不断提升。而原始处理大量数据的方法是将其丢弃，这在企业需要从数据中获取更多洞察的时期，反而造成了更多的信息缺口。真正的解决方案是构建既能实时分析高 volume、高维度的日志，又能保持成本效益的解决方案，并确保这些日志在需要的地方可用。

巴辉特总结：

Todd Persen 这个观点，也是 Honeycomb CTO Charity Majors 的观点延展。Charity Majors 说需要 Observability 2.0，需要宽事件的新概念，Todd Persen 则说，Observability 2.0 其实就是日志的卷土重来，把日志搞得更结构化、更宽，存储原始日志数据，增加压缩降低成本，提升查询效率。而且，Todd Persen 稍微升华了一下日志的价值，说日志不止是为了可观测性，还是为了分析，这才能解锁更多日志的价值。

我们怎么看？我们创业做 Flashcat 一站式智能观测平台，也算是这个赛道的玩家。说说我的个人观点：