摘要：可观测性2.0回归日志本质，需解决高基数和高维度挑战。传统MELT三大支柱通过丢弃数据应对，已不适用云原生架构。未来需AI赋能，构建支持高容量、高维度日志的实时分析方案，利用OLAP和数据湖等技术，赋能AIOps和安全等场景，释放日志数据价值。
可观测性2.0回归日志本质，需解决高基数和高维度挑战。传统MELT三大支柱通过丢弃数据应对，已不适用云原生架构。未来需AI赋能，构建支持高容量、高维度日志的实时分析方案，利用OLAP和数据湖等技术，赋能AIOps和安全等场景，释放日志数据价值。
译自：Observability 2.0? Or Just Logs All Over Again?
作者：Todd Persen
最近，关于可观测性 2.0 以及从三个（或者四个，取决于你问谁）可观测性的支柱向统一的事实来源转变的讨论很多：任意宽的、结构化的日志事件。
如果我们将其归结为一点，我们又回到了起点——某种程度上。一开始，只有日志，现在我们又回到了原点，有了更宽的日志（结构化的、高维度的时间序列事件），而且比以往任何时候都多（加上高基数）。那么，我们是如何走到这一步的？我们究竟要走向何方？
可观测性的三大支柱是 日志、指标和追踪。如果你真的想要一个巧妙的缩写，你可以加上 事件来创建 MELT。然而，可观测性宇宙的基本构建块一直是日志。我认为，三大支柱的演变实际上是一种随意的处理方式，旨在解决需要解决的实际问题：如何实时洞察高容量、高基数的时间序列数据。
早在 2010 年代初，当第一波可观测性浪潮出现时，大型公司拥有 Splunk，它擅长集中和处理日志。值得反思的是，Splunk 于 2012 年 4 月首次公开募股，当时的年收入已经超过 1 亿美元。（即使在当时，企业已经开始关注 Splunk 的高成本，而且自那时以来，大多数企业的日志量绝对是爆炸式增长。）
但第一波可观测性更多的是关于你不能用日志做的所有事情。根本不可能快速地对大量的日志数据进行分析和聚合。
为了解决这个问题，我们添加了另一个支柱，指标。当我在 2012 年共同创立 InfluxData 时，时间序列数据库领域正在兴起一股创新浪潮，它将摆脱 Graphite/Whisper，并催生 InfluxDB、Prometheus、Timescale 和 Facebook 的 Gorilla 等产品。这些工具经过专门优化，用于存储指标和执行聚合，你可以通过平均请求延迟和总错误等指标，为团队提供系统运行状况的整体视图。这种过度关注旨在填补传统日志管理系统中的空白。
但是你不能使用这些系统来搜索字符串或深入研究日志。数值时间序列数据可以为你提供整体视图，但不包括提供根本原因分析的粒度，以便你可以在问题出现时实际解决它们。在大多数情况下，这些系统通过创建摘要聚合和丢弃底层原始数据来处理高容量问题。
第三个支柱，分布式追踪，旨在解决分布式系统中的根本原因分析问题。Google 的 Dapper 论文 于 2010 年发布，Zipkin 是另一个基于 Dapper 论文的早期分布式追踪工具，于 2012 年开源。分布式追踪允许团队追踪流经应用程序的请求，从而更容易识别瓶颈和问题。
从高基数、高容量数据的角度来看，分布式追踪应该帮助团队筛选噪音并深入研究重要的细节。但是追踪可以很好地解决一组非常离散的案例——而其他所有情况都很糟糕。它对指标或日志没有帮助。对于处理高请求量的系统，追踪还会进一步扩大数据量，并产生更多的噪音。抽样（随机仅保留一小部分追踪）理论上可以帮助解决这个问题，但是你再次失去了完全分辨率的可观测性的好处。
总而言之，三大支柱可以让你深入了解你的系统。但是，尽管进行了所有的创新和开发，但基础比应有的要脆弱——因为没有一个支柱真正解决了实际问题。
随着可观测性解决方案在过去 15 年里表面上变得更加成熟，我们仍然看到客户在管理其可观测性资产方面遇到困难，尤其是在云原生架构不断增长的情况下。所谓的“统一”可观测性解决方案带来了管理三大支柱的工具，但成本和复杂性仍然是主要的痛点。与此同时，数据量一直在上升，截至 2023 年，有 37% 的企业每天摄取超过 1 TB 的日志数据 (截至 2023 年)。
传统的日志记录解决方案通常通过较短的保留期和分层存储来处理高数据量和基数的问题——这意味着数据要么在相当短的时间后被丢弃，要么存储在冻结层中，在那里它会变得不可见。
与此同时，其他时间序列或指标数据库获取高容量的源数据，将其聚合为指标，然后丢弃底层日志。
最后，追踪会生成大量数据，以至于大多数追踪甚至根本没有被存储。基于头部采样的保留一小部分追踪，通常是随机的，而基于尾部采样的允许您更智能地过滤，但代价是高效处理。然后，追踪通常会在短时间后被丢弃。
这里有一个共同的主题：虽然可观测性的所有支柱都提供了不同的方式来理解和分析您的系统，但它们都通过丢弃数据来处理高基数的问题。如果您的系统很小且包含在内，那么您可能没问题——但在这种情况下，太多的可观测性工具可能就显得过犹不及了。对于可观测性真正应该帮助的最大的系统来说，三大支柱的成本太高，而提供的价值太少。
可观测性完全是关于基于系统的输出来理解系统的状态。丢弃输出，您就不再真正拥有可观测性了。您有三个摇摇欲坠的支柱，大量的复杂性和高成本——对于拥有分布式系统的企业来说，您仍然没有获得您被承诺的真正的可观测性。
我们不需要重新发明更好的离散指标、追踪和日志记录工具的版本。我们只需要一个可以解决所有三个问题的工具。
通过这种方式，我们有点回到了起点。这实际上只是关于日志——宽的、结构化的事件。换句话说，可观测性完全是关于输出的，而这些输出是日志——指标和追踪可以从结构化日志中派生出来。您只需要一个工具来解决在高基数和高维度数据面前的查询性能问题。
高基数数据由许多唯一值组成——换句话说，它将高容量与高唯一性结合在一起。它更难压缩，导致存储中的数据更多，并且查询的计算密集型读取更多。我们可以将高容量和基数的问题归结为处理大数据的大规模挑战。
正如我们所讨论的，大多数系统试图通过丢弃数据或降低其粒度来解决这个问题。我们将看到平台越来越多地使用 AI 来“智能地”确定要丢弃和保留哪些日志——换句话说，试图将信号与噪声分离。虽然 AI 工具对于检测模式和洞察力非常有用，但它们不应该只是丢弃数据的另一个借口。
相反，答案是一种旨在摄取、查询和分析大量日志数据，同时保持成本效益的解决方案——所有这些都无需丢弃底层原始数据。
为了使日志提供我们通常期望从分布式追踪中获得的好处，它们需要能够保留所有必要的上下文。这包括将日志在逻辑上分组和关联在一起所需的上下文——以及通过系统追踪请求。
这就是“任意宽的、结构化的日志事件”发挥作用的地方。即使不添加此附加上下文，日志也可能是高维度的（宽的，具有很多属性）。我们已经看到具有数千个字段的日志，甚至那些今天可能看起来具有模糊商业价值的日志，如果您的数据科学团队明年想要它们，但您从未保留它们，可能会导致重大遗憾。
为了适应不同程度的维度，即使知道大多数用户不知道其日志字段的数据类型是什么，您也需要一个具有灵活模式的解决方案，例如数据湖。借助灵活的模式，您的日志可以任意宽，具有任意数量的维度，并且随着时间的推移具有变化的数据类型。 为了确保使用高维度数据进行高性能分析，该解决方案应利用列式存储，这对于在线分析处理解决方案 (OLAP) 来说很典型，以及灵活的索引格式，以支持具有不同维度的字段。许多 OLAP 功能天然适合日志数据。例如，不可变的“一次写入，多次读取”方法可确保日志保持安全、不可更改的真实来源，同时还能提高分析性能。
最终，我认为可观测性 2.0 不是要构建一个新的解决方案，而是回归可观测性的根本，并实现高效、大容量的日志处理与实时分析相结合。当我们通过分析的视角而不是仅仅通过可观测性的视角来考虑日志数据时，我们可以极大地扩展其价值。
日志数据不仅仅适用于专注于应用程序性能的运维团队，尽管这是一个关键任务用例。相反，它是整个组织中更大的可观测性图景的一部分。日志数据以及通常带有时间戳的数据，提供了关于企业过去、现在和未来的基础故事。真实用户监控数据（传统上隔离在可观测性平台中）可以为营销、广告和容量规划提供见解。事务日志可以帮助数据科学团队消除欺诈。与此同时，网络安全团队可以使用相同的数据进行威胁搜寻和发现高级持续性威胁。而且数据集越大，它在训练用于异常检测等用例的 AI/机器学习 (ML) 模型方面的潜在价值就越大。
隔离数据的可观测性解决方案的成本不断上升。而通过丢弃大量数据来处理高容量数据的原始方法，只会为企业在需要从其数据中获得更多洞察力的时候制造更多的差距。真正的答案是构建能够处理高容量、高维度日志以进行实时分析，同时保持成本效益的解决方案——并确保这些日志在任何需要的地方都可用。
来源：小火车聊游戏