可观测性成本飙升非供应商之过，乃遥测质量差和治理不足。源头提升遥测数据质量，加强治理，方能降本增效，解决数据冗余与泄露。
译自：Why your observability bill keeps growing (and it's not your vendor's fault)
作者：Juraci Paixão Kröhling
过去一年中，我与数十个工程团队讨论了他们的可观测性管道，并直接分析了他们的生产遥测数据。对话的开头都如出一辙：成本不断增长，领导层要求给出解释，团队面临着削减账单的压力。以下姓名和识别信息已更改，但数字和模式都是真实的。
一家拥有数千名工程师的支付公司每月在可观测性工具上花费超过20万美元。他们由18人组成的平台团队每天监控成本估算。当估算呈上升趋势时，他们会调查是哪个团队导致了飙升，然后手动追踪该团队。他们建立了异常警报来自动化此过程，但警报校准得不够好。有时它们会向错误的团队发出警报；有时则完全不触发。
为了控制成本，该团队完全排除了调试日志，并在未格式化日志到达索引器之前丢弃了99%。它还削减了某些类别的信息级日志。该公司已经从一个可观测性供应商迁移到另一个，现在正在构建一个辅助的自托管堆栈作为成本对冲。
“这是几乎每个具有非普通可观测性部署的组织都认识到的成本螺旋。”
账单持续增长。底层的仪表化并未改变。
这是几乎每个具有非普通可观测性部署的组织都认识到的成本螺旋。本能地，人们将其视为供应商定价问题。评估更便宜的后端。添加采样。将信号路由到更便宜的层级。这些是合理的优化，但它们只是治标不治本。
治理鸿沟
真正的问题不同。我们正在生成什么遥测数据？谁拥有每个信号？其中是否有任何是真正有用的？
当我分析一家运行超过4700个服务的金融机构的生产遥测数据时，所有数据点中有82%缺少基本的service.name属性。这些指标，每五分钟就有数百万个数据点，没有归属。没有人能将它们归因于某个团队、产品领域或成本中心。该组织有仪表化指南。但没有大规模强制执行。
同样的分析发现，有1300个服务将敏感数据泄露到其可观测性管道中。一个框架级别的Java虚拟机（JVM）信任库密码泄露到352个服务中，这并非由于单个开发人员的错误，而是因为框架将其设置为系统属性，并且自动仪表化捕获了它。Kafka配置日志在479个服务中暴露了凭据。税务ID、银行账号和授权头信息出现在数百个其他服务中。安全团队有策略。但没有自动强制执行。
“这些不是供应商问题。更换后端并不能解决捕获凭据的仪表化问题。”
在另一家公司，财务运营（FinOps）审查每月进行两次。最初的追踪实现对每个服务都设置了100%的采样。多年后，没有人减少它，因为文化上期望所有追踪都可用。与此同时，用户ID和优惠ID泄露到指标属性中，导致高基数爆炸，随着每个新客户的增加而推高成本。
这些不是供应商问题。更换后端并不能修复捕获凭据的仪表化。采样并不能解决service.name缺失的问题。更便宜的层级并不能让75%的日志重复消失。
源头质量
管道级别的解决方案，如采样、过滤、路由和丢弃，在不提高信号质量的情况下减少了数据量。它们操作得太晚了。当遥测数据到达管道时，生成它的成本已经支付，敏感信息也已序列化。
在一家运行4000到6000个服务的公司，几乎所有服务都依赖自动生成的仪表化。结果是：追踪数据超过2000个span，主要由内部框架调用组成，这些调用无法回答任何操作问题。一位工程师直言不讳地描述：“我们几乎完全采用自动仪表化，结果看到了大量的垃圾数据和技术债务。”采样可以减少这些追踪的数据量，但无法使它们变得有意义。
“在源头解决质量问题意味着每个指标、span和日志的存在都有明确的原因。”
在我分析的另一个生产环境中，所有追踪数据中有81%由Redis PING命令和健康检查端点组成。在另一个组织中，75%的日志是完全重复的：Kafka客户端每隔几秒钟重复一次的聊天信息，Kubernetes事件循环播放相同的警告，一个服务在五分钟内发出了近2000行相同的日志。管道去重可以压缩这些数据，但问题依然存在：应用程序为何要生成这些数据？
在源头解决质量问题意味着每个指标、span和日志的存在都有明确的原因。仪表化遵循约定，属性携带归因所需的元数据，并且敏感数据永远不会进入管道。这就是将可观测性视为发生在代码上的事物，与将其设计到代码中的事物之间的区别。
治理的实际面貌
遥测治理是一种实践，旨在了解你收集了什么、谁拥有它以及它是否具有目的。基于我在这些组织中看到的模式，它涉及一些具体的能力。
仪表化评分给每个服务一个定量的质量基线。团队不再问“我们的仪表化好吗？”，而是问“本周哪些服务低于我们的阈值，为什么？”评分使质量变得可衡量和可追踪。
自动化审查在问题到达生产环境之前捕获它们。当开发人员添加包含用户ID的span属性或引入具有无限基数的指标时，反馈循环应该是即时的。而不是在下一次FinOps审查时。也不是在账单到达时。
对SDK版本、配置漂移和语义约定合规性的全舰队可见性解决了大规模治理问题。当60个团队加入一个集中平台，每个团队都按照自己的理解遵循指南时，手动强制执行是行不通的。
遥测数据中的个人身份信息（PII）检测，而不仅仅是应用程序逻辑中的检测，可以捕获代码审查遗漏的问题：框架级别的泄露、自动仪表化捕获头信息以及业务逻辑将交易详情记录到span属性中。
建设性的问题
下次有人问“为什么我们的可观测性账单这么高？”时，富有成效的答案不是“让我们更换供应商。”而是“让我们了解我们正在生成什么以及为什么。”
这次对话将重点从成本削减转移到质量改进。它将讨论从管道转移到源头。质量改进会带来成本节约的副作用，因为当仪表化是有目的时，需要收集、存储和支付的数据就越少。
在可观测性上花费最多的组织，并非是拥有最多服务的组织。而是那些从未询问过他们的遥测数据是否真正有用的组织。
