随着技术和组织的发展，可观测性成本不断攀升，有必要采取相应措施加以控制。
译自 A DIY Framework for Optimizing Observability Costs，作者 Chris Cooney 是 Coralogix 的开发者倡导者，他对一切可观测性、组织领导力和前沿工程充满热情。
可观测性成本正在飙升，因为企业努力通过高性能和 24/7 可用性来提供最佳客户满意度。
2024 年全球可观测性年度支出远超 24 亿美元，预计到 2028 年将达到 41 亿美元。对于单个公司而言，这体现为可观测性成本占整体基础设施支出的 10% 到 30%。
随着数字环境的扩张和日益复杂化，这些成本无疑将继续上升。因此，对于注重成本的公司来说，评估如何在保持整体可观测性卓越性的同时最佳降低这一成本至关重要。
让我们来讨论为什么可观测性软件需求如此之高，如何实施 DIY 成本优化方法，以及选择现成方案确保可观测性成本保持在尽可能低的水平的标准。
导致可观测性成本增长的最明显原因是，企业必须满足当今消费者对闪电般快速、按需、24/7 访问任何数字服务的期望。监控系统运行状况对于现代公司至关重要。但除此之外，各种技术和组织因素也推高了可观测性成本。
让我们来看看其中的一些因素:
微服务比等效的单体应用程序产生更多的可观测性数据。这对于跟踪数据尤为显著，跟踪数据展示了数据如何通过所有相交接口在应用程序中流动。存在的微服务越多，就会产生越多的数据——而且相互依赖性也越来越复杂。
过去，一台服务器可以运行多年;但在我们以云为中心的世界里，按需启动服务器的能力、对 spot 实例的日益广泛使用，以及微服务和容器化的本质，使得短暂服务器非常常见。这也推高了基础设施的复杂性，增加了数据量。
站点可靠性工程师 (SREs) 通常使用混沌工程来测试应用程序，有意引入失效以验证其稳健性。例如，SREs 会摧毁一台服务器，只为看看系统会作何反应。由此产生的故障通常无法在日常系统行为中看到，因此，观察数据也会增加，以涵盖这些测试模式和场景。
由于上述因素，可观测性解决方案必须摄取和处理大量数据，以便公司了解存在问题的位置，并确保其应用程序或网站的健康状况未受到损害。然而，这通常需要对数据进行索引以加快搜索和查询操作的速度，然后将数据存储在热存储中以便频繁快速检索。这直接推高了可观测性成本，尤其是因为热存储极其昂贵。
虽然一些可观测性供应商会建议限制数据摄取以降低成本，但这种策略可能会损害可观测性，导致生产问题被遗漏、无法获得进行根本原因分析所需的宝贵数据，以及违反各种监管要求的风险增加。
在讨论如何更好地管理数据及其相关成本之前，让我们先看一些令人咋舌的统计数据，这些数据是关于超过 1,000 家公司的数据消耗情况。
来源: Coralogix
对于经验丰富的 DevOps 和 SRE 团队，自行实施 (DIY) 可能是最佳选择。在构建自行实施的可观测性时，您需要了解以下信息。
鉴于数据管理的复杂性，很容易迷失在细节中。但是，要降低可观测性成本并将其保持在较低水平，您只需从正确的方法着手。
降低可观测性成本不需要大规模或复杂的咨询项目。您需要遵循的关键步骤如下:
您可以使用以下三个类别进行整理:
- 每天需要搜索的数据
- 用于仪表板和警报但很少搜索的数据
- 仅为合规性目的而保留的数据
许多开源工具都可以让您了解哪些内容被搜索量最多。例如，Prometheus 的查询日志可以告诉您运行次数最多的查询是什么，因此也可以知道最重要的时间序列指标是什么。
在实践过程中，您可能希望扩展上述类别，因为您的组织无疑有许多不同的数据使用场景。然而，从这个基本分类开始是必不可少的，因为我们后面需要用到它。
对于可观测性解决方案，一种典型的倾向是在类似 OpenSearch 的工具中对所有摄取的数据进行索引，然后随着时间推移将其移至更便宜的存储选项，如 S3。但并非所有摄取的数据都需要进行快速搜索，实际上有 30% 的数据从未被使用过。索引非常昂贵，因此应该只局限于将被频繁搜索的数据进行索引。
之所以会出现这种典型模式，是因为很容易设置此类流程。然而，通过定义用例，团队可以创建一种更智能的数据路由模式，在确定该如何处理数据之前先对其进行分类。
一旦确定了数据的使用情况和统计数据，对数据进行分类就变得更加直观。这些分类可以让团队了解哪些数据需要快速查询、哪些数据永远不会被查询以及介于两者之间的数据。基于这些类别，您可以决定将数据路由到存档、固态硬盘 (SSD) 热存储或类似亚马逊 Elastic Block Store (EBS) 卷的中间选择。
通过这种流程，只有高度重要且经常被搜索的数据才会被索引并存储在昂贵的 SSD (热存储) 中。另一方面，不会增加运营价值的合规性数据可以直接发送到低成本存档存储。需要间歇使用的数据可以存储在磁盘 EBS 卷中。
#@# 不要进行重新索引操作
当数据已经存放在存档存储中，但您需要再次访问它时，就会执行重新索引操作。例如，监管数据可能会定期存档，但每年您需要生成一份报告时就需要访问这些数据。重新索引的操作非常昂贵，即使数据最终会从热存储中删除。此外，当将这些大量数据重新添加到索引时，也会降低操作查询的速度。
作为一种昂贵且低效的重新索引的替代方案，归档数据应该以易于访问的开源格式(如 Parquet 或 CSV) 保存。通过这种方式，可以直接查询归档数据，而无需进行索引。这不仅降低了可观测性费用，更重要的是，它将历史数据和运营数据分开，确保运营数据查询保持快速。
停止生成不必要的日志、跟踪和指标。我们所描述的分类将帮助您了解哪些数据有用，哪些数据无用。
出于合规性或为了心安理得而需要的数据应该直接存储到低成本的存档存储中。大多数时候这些数据不会被使用，但可以直接从存档中查询，如前一节所述。
并没有规定说你必须以原始形式摄取数据。由于日志的大小，存储日志的成本特别高。日志数据中并非所有字段都有用。如果日志中只有有限的有用字段，可以考虑将它们转换为时间序列指标，并从存储中删除原始日志。与日志相比，指标的大小更小，存储成本也更低。DevOps 团队也可以获得相同的洞察，因为这些数据仍然可以被索引;只是要索引的数据量大大减少了，从而优化了成本。
存储指标的成本较低的一个例外情况是高基数指标。这些指标具有许多不同值的标签，例如支持数百万用户的 IP 地址指标。标签下的每个不同值都提供了一种查询数据的方式。这会降低查询速度，增加成本，并导致更长时间的中断。相对于单个具有大量高基数和高维度标签的时间序列，更应该使用多个不同的简单时间序列。
为避免高基数，团队可以聚合指标以减少标签，删除不必要的标签或生成更小的低基数指标。这些操作将有助于降低成本，对于保持高性能标准也至关重要。
有时，自行管理可观测性解决方案的运营开销过高。这种开销可能会分散您团队的注意力，并给他们带来维护可观测性堆栈及其底层基础架构的沉重负担。如果您正在考虑采用托管的可观测性解决方案，以下几节提供了一些通用指导。
在评估 SaaS 可观测性选项时，成本优化将因供应商、其架构以及在其专有系统中生成见解的方式而有所不同。
以下是一些选择具有成本效益的解决方案的技巧。
对于使用 SaaS 可观测性提供商的消费者来说，每个系统都应该有一种优化成本的方式。无论您是否已经与供应商集成，或者是第一次选择供应商，一定要以特定的方式询问有关成本优化的问题。询问:"您为客户提供哪些工具来优化成本？"
供应商提供的答复将揭示他们投资并构建了哪种工具，而不是直接将成本优化的责任放在作为消费者的您身上。由于在使用第三方解决方案时，客户无法完全控制流程，减少数据量通常被视为降低成本的回应。但正如我们所讨论的，这不是最佳选择，因为您也可能无法洞悉软件系统的运行状况，而且实施这些减少措施需要大量工程时间(进一步增加成本)。因此，如果实际的成本优化工具没有内置在产品中，很可能意味着供应商不希望您优化成本，在这种情况下应该避免选择该供应商。
这可能需要更多努力，但仔细阅读细则至关重要。如果一个供应商提供了许多捆绑服务，强制您购买不需要的功能;如果按主机定价但未区分主机大小;或者对每个功能收取不同且没有标准化的费用，那么您应该三思而行。
寻找提供简单明了的定价的供应商，这样您就可以轻松估算成本并避免昂贵的超支费用。