摘要：可观测性 现在已成为基本要求——客户期望应用程序运行流畅，无论事件规模多大。寻求竞争优势的企业需要找到方法，将可观测性数据用于其他用例，不仅用于合规性和安全目的，还用于主动分析、商业智能 (BI) 和训练机器学习模型。
对于受困于可观测性或其他不提供数据联合平台的合同的企业来说，是时候考虑新的解决方案了。
译自 ObservaBIlity Isn't Enough. It's Time To Federate Log Data，作者 Franz Knupfer。
在过去十年中，可观测性已从流行词转变为最佳实践。企业正在从中受益，平均故障恢复时间 (MTTR) 更短，用户体验更好，并且停机时间更少。
可观测性 现在已成为基本要求——客户期望应用程序运行流畅，无论事件规模多大。寻求竞争优势的企业需要找到方法，将可观测性数据用于其他用例，不仅用于合规性和安全目的，还用于主动分析、商业智能 (BI) 和训练机器学习模型。
那么，企业需要做些什么才能从这些数据中提取更多价值，以用于预测客户流失、系统容量和库存需求等有价值的用例，同时检测威胁和异常等问题？这些问题必须得到解答，才能确定企业是蓬勃发展还是走向失败。
对于已经主要将日志数据发送到可观测性平台的企业来说，一个潜在的第一步是将数据导出到数据湖，然后使用Apache Spark和Databricks等工具进一步分析这些数据。但是，导出数据会增加额外的复杂性和成本，更不用说移动数据带来的潜在安全风险了。
相反，最佳实践是数据联合。通过数据联合，您可以跨许多不同的数据源查询数据，而无需移动数据。使用这种方法，无需额外的管道；没有出口成本，也没有迁移数据带来的任何安全风险。
最重要的是，您的团队不会被阻止访问和分析他们完成工作所需的数据。
一些可观测性平台（例如 Splunk）正在拥抱向联合数据的转变。但许多平台仍然是封闭的系统。即使它们能够与为 BI、机器学习和数据科学设计的其他分析平台连接，它们通常也不会拥有这些用例所需的高保真度、长期数据。
这是因为首先保留数据的时间通常太昂贵，并且降采样等做法很常见，从而降低了存储数据的保真度和质量。
它们首先且最重要的可观测性平台，它们应该如此，并且它们并非设计用于长期存储大型数据以进行分析。但是，日志数据已成为大数据——不仅对于每天都在摄取数 TB 日志数据（并且由于高成本而经常快速丢弃数据）的企业而言，而且对于希望从存储在数据湖和仓库中的 PB 级日志数据中获得新见解的最具创新性的企业而言也是如此。
因此，将日志数据保留在可观测性平台中，然后将其导出或联合到另一个分析平台并不是一种真正有效的方法。
相反，答案是将日志数据保留在适用于实时和长期分析的存储解决方案中。使用正确的存储解决方案，数据联合可以成为将可观测性和统一分析结合在一起的粘合剂，从而形成真正全面的视图，使您的企业获得竞争优势。
但是什么构成了正确的存储解决方案？
该解决方案必须能够经济高效地长期保留数据，这通常意味着使用廉价的商品对象存储——换句话说，就是数据湖。
但是，传统的数据湖虽然经济高效，但并不适用于实时分析，并且快速分析海量数据也可能具有挑战性，因此数据湖并不总是适用于统一的长期分析。
因此，除了经济高效之外，它们还必须具有高性能，能够查询数据，无论数据是几分钟前还是一年前的。
最近，AWS 推出了 S3 Tables 来提升对象存储的性能。S3 Tables 的影响力还有待观察——以及计算任务（例如压缩）是否会比预期增加更多成本——但这无疑是朝着正确方向迈出的重要一步。其他开放式表格格式（例如 Iceberg）也是如此，它们极大地提高了对象存储查询的性能，尽管仍然需要构建单独的实时流处理管道来摄取数据。
古老的格言仍然适用：对症下药。像 S3 Tables 这样的数据湖可以具有许多通用的优势，但它仍然无法提供专门为日志数据设计的解决方案所能达到的相同性能水平。通过数据联邦，您可以根据用例选择不同的工具来处理不同类型的数据，因此无需将自己限制在一个解决方案上。例如，您的组织可以根据数据类型和用例组合使用数据湖和专用解决方案。
可观测性平台通常吹嘘能够使用“单一视图”查看所有操作数据。虽然数据联邦可以帮助为操作提供统一的视图，监控和可观测性，但这单一视图不应以牺牲使用其他工具来分析和理解数据为代价。
通常，摄取到可观测性平台中的数据不再容易用于其他用例（例如长期分析），如下图所示。
在这种方法中，日志和遥测数据的目标是将其分析（通常存储）在可观测性平台中。大部分数据会被摄取并保留很短一段时间（通常最多几个月），然后会被丢弃、聚合或移动到冷存储。
在这个模型中，可观测性平台是一切的终点。虽然使用数据联邦来提供单一视图可以增加对更多摄取源的支持，提供与经济高效的日志存储解决方案的兼容性，并通过最大限度地减少数据移动来提高安全性，但这假设遥测数据的唯一价值在于系统可观测性。
但是，那些可以从数据中提取额外价值的数据分析平台、机器学习模型、计费系统和其他工具呢？为了使这些数据可用于这些用例，可观测性平台不能仅仅是遥测数据的联邦后端——它们还必须是 Databricks 等平台的联邦前端。
下图说明了可观测性平台如何能够同时摄取数据并作为数据源的联邦后端，同时也是数据分析平台等其他工具的联邦前端。
如前所述，可观测性平台的结构并不适合为其他分析工具存储数据。这很大程度上是因为它们并非设计用于长期保留或经济高效地存储大量数据。而且它们是围绕着一个有限的范例构建的，在这个范例中，遥测数据只在短时间内且仅对可观测性有价值。
一种更有效的数据联邦方法如下所示。
在这种方法中，为规模化设计的经济高效的日志存储解决方案是大量日志和事件数据的首选存储位置。可观测性解决方案是分析联邦数据的一种前端，但不是唯一的一种。
这种方法——存储和UI/分析是解耦的——可以被认为是“无头可观测性”，但这需要可观测性解决方案进行重大的范式转变。在这个范式转变中，它们不再专注于存储数据——或者如果它们专注于存储数据，则必须开发与其他分析工具的集成，同时提供长期、经济高效的存储。
在当前的范例中，使用可观测性平台作为所有日志数据的“单一视图”将妨碍使用这些数据进行长期分析。同时，您仍然需要可观测性工具，因为像 Databricks 这样的平台无法提供可观测性平台所能提供的相同级别的应用程序监控。
具有前瞻性的组织将采用混合的分析前端（例如，Splunk 和 Databricks）和数据存储解决方案。无论用例是什么，以及它们是前端、后端还是两者兼而有之，解决方案都必须具备以下特性： 他们必须拥抱数据联邦。对于分析前端来说，这意味着能够连接许多不同的后端数据源。而且通常它也意味着成为另一个分析前端的后端数据源。无法成为其他分析前端后端数据源的可观测性解决方案应该转向“无头可观测性”，即它们查询数据但不存储数据。
对于存储后端来说，这意味着拥有丰富的连接器和集成生态系统，允许在其他分析工具中查询数据而无需导出它。换句话说，集成必须同时支持来自其他来源的摄取和向其他来源发送分析。
他们必须兼顾性能和成本效益。企业可以廉价地将数据存储在数据湖中，但直到最近，权衡的是较低的查询性能。或者，他们可以使用紧密耦合的本地存储来提高性能，但这很快就会导致更大数据量的成本增加。
新的范式包括寻找方法来最大限度地提高经济型商品云存储的性能，使其能够满足实时和历史分析的需求。对于日志存储解决方案来说，这现在是一个基本要求。
对于分析前端（例如仍然依赖昂贵、紧密耦合存储的可观测性平台），这意味着要接受它们并不总是存储数据的正确工具，但它们仍然可以为分析提供强大的UI，并通过从异常检测到全套可观测性产品的各种功能提供价值。
在评估可观测性、网络安全、分析和日志存储方面的新的解决方案时，企业应该将这些考虑因素放在首位。对于那些与不提供数据联邦的可观测性或其他平台签订合同的企业来说，现在是认真考虑新的解决方案的时候了，否则就会输给那些能够更有效地做出数据驱动决策的公司。
对于在这些领域提供解决方案的企业来说，支持数据联邦和构建丰富的连接器生态系统是未来发展的基本要求。许多可观测性平台采用的封闭式花园方法将不再有效。虽然这可能会为采用这种方法的平台带来供应商锁定（和短期利润），但它也会带来更高的成本和更低的价值——这并不是未来增长的制胜法宝。
这些企业还必须仔细研究那些因昂贵、紧密耦合的存储架构而惩罚客户的定价模式，并提供更符合价值的定价。
最后，对于客户和平台来说，在连接器生态系统方面还有一个最终的关键考虑因素。平台的生态系统是否首先关注通过数据联邦等最佳实践为客户带来价值？或者它是否反而促使客户更加依赖平台（使数据更容易进入，但不容易出去），希望花园足够吸引人以至于可以隐藏围墙？
最终，重要的不是生态系统的规模，而是它包含的连接器是否允许您的团队在需要的时候和地点使用数据。这意味着利用这些生态系统来扩展遥测数据的价值，超越可观测性。
来源：郝董掉坑
