paint-brush
可审计和运营使用数据之间的区别经过@openmeter
202 讀數

可审计和运营使用数据之间的区别

经过 OpenMeter5m2023/07/13
Read on Terminal Reader

太長; 讀書

随着人工智能的采用,使用归因和退款用例正在增加。现代企业渴望收集使用数据来推动计费、销售、产品开发和云成本分析。 FinOps 基金会最近公布了其 [FOCUS](https://focus.finops.org/)(开放成本和使用规范)的初稿
featured image - 可审计和运营使用数据之间的区别
OpenMeter HackerNoon profile picture
0-item
1-item

随着人工智能的采用,使用归因和退款用例正在增加。现代企业也渴望收集使用数据并将其分配给客户和内部部门,以推动计费、销售、产品开发和云成本分析。


FinOps 基金会最近还公布了其FOCUS (开放成本和使用规范)的初稿。为什么使用数据可能很复杂,事件计量与时间序列指标有何不同?


基于使用的计费的时间序列

使用数据用例

在深入研究计费、分析和监控用例的复杂性之前,让我们先定义一下使用数据的含义。使用情况描述了某人在一段时间内消费某种商品。例如,在下午 1 点到 2 点之间,Alice 通过 Twillio API 发送了 100 条短信。


使用情况通常描述一个时间段而不是单个日期,因为计算机速度很快,但人类却很慢。让我们看一下需要使用数据的一些常见用例:


计费:这需要准确的使用数据,因为客户是根据具有法律约束力的合同条款付费的。虽然数据维度通常有限,但基数很高,因为必须跟踪每个客户的使用数据。


实时数据是可选的,但当用户达到计费阈值时需要及时通知。数据保留对于验证账单至关重要,尽管一旦发票结算,这一点就变得不那么重要了。


监控:这需要实时使用数据以用于警报目的。准确性很重要,但比计费更灵活。监控系统通常受到基数的限制。


由于存储大量监控数据的成本较高,且几周后很少被利用,因此数据保留时间通常很短。


分析:云成本、利润分析和定价等典型用例需要过去三到五年的准确历史数据来训练模型并有效识别趋势。分析很少是实时的。


总结为一张表:

用例

准确性

基数

即时的

保留

计费

高的

高的

缓和

1-2年

监控

缓和

低的

高的

周数

分析

高的

缓和

低的

3年以上


正如您所看到的,每个用例都有不同的需求,这在讨论使用数据时可能会令人困惑。

了解可审计和运营数据

将数据分类为可审计或可操作的概念是在 2018 年通过Honeycomb.io联合创始人 Charity Majors 的一条推文首次引起我的注意。


当任何数据记录的丢失都无法容忍并且需要完全保留记录时,可审计数据就被归类为可审计数据。当使用可审计的数据集时,它应该是全面和完整的。


可审计数据的示例包括事务日志、复制日志和计费/财务事件。


相反,操作数据不需要严格的完整性。为了维持可管理的成本,通常采用抽样,并且一定程度的数据丢失是可以接受的。


设计用于管理运营数据的工具通常优先考虑工作效率,绕过重试和昂贵的一次交付保证。操作数据的示例包括遥测、指标和描述每个请求和系统组件的上下文数据。


在决定收集、处理和存储使用数据的方法之前,确定您的数据是否需要可审计或可操作非常重要。


在下一节中,我们将比较两种数据收集策略:事件驱动的计量(通常更适合可审计的用例)和时间序列监控(收集操作使用数据的首选方法)。

事件驱动计量与时间序列指标

收集使用数据的主要方式有两种:


  1. 事件驱动的计量


  2. 时间序列监控系统


他们的比较如下:


事件驱动的计量:基于使用情况的计费公司喜欢这种方法,因为它在处理独特事件方面具有内在的一致性,因此可以进行审计。事件可以在分布式系统中进行双重传送,并使用唯一标识符进行重复数据删除,以防止计费过高或过低。


计量可以很好地处理高基数,这是跟踪每个客户的使用情况所必需的。然而,挑战在于数据收集。该行业拥有强大的基础设施收集器用于监控,但这些收集器的设计考虑的不是事件。


大多数供应商提供用于事件提交的 POST API,将收集过程留给用户。


时间序列监控: Prometheus 等监控系统抓取计数器和直方图,以存储和提供指标作为时间序列操作数据。


建议保持较低的基数,这使得大规模跟踪单个用户资源消耗变得困难。指标收集是业界一条成熟的道路,开箱即用的指标提取器可用于大多数基础设施组件。


APM 供应商在 OpenTelemetry 等标准上投入了大量资金,以简化数据收集。挑战在于指标收集器在交付和重复数据删除方面的保证有限,因为它们是在设计时考虑到操作数据用例的。


Prometheus 贡献者在此分享了一些关于准确性的想法。如果您想更深入地挖掘,您还可以在这里找到一些关于调整抓取以提高计数器准确性的争论。


总结为一张表:

收集使用情况

可审计

一致性

收集者和标准

事件计量

是的

高的

低的

时间序列指标

缓和

高的

使用的未来:整合

当前的挑战在于收集和整合使用数据。这些任务很复杂,因为使用情况收集必须根据用例以不同的方式平衡准确性、基数和实时方面(如事件与指标比较所示),而由于需要使用规范标准,集成非常耗时。


只需考虑所有自定义供应商 API 或通用 PromQL 接口即可。这种缺乏整合的情况给将使用数据集成到计费、退款和成本分析用例中带来了困难,通常会导致使用数据收集的系统不同,而不是相互共享。

FinOps 的焦点:使用集成的新规范

FinOps 的 FOCUS(开放成本和使用规范)旨在解决使用数据的集成挑战。 FOCUS 概述了云提供商和 SaaS 供应商生成和使用标准化使用情况以及计费数据的规范。


FOCUS 将使您能够无缝集成供应商之间的使用数据,用于计费和云成本分析用例。


FOCUS规范目前正在开发中; 0.5预览版于2023年6月下旬刚刚发布,目前规范更多地关注计费而非使用数据。


您可以在此处关注或加入 FOCUS 工作组。

协调准确性、基数和及时性

我预计事件计量和指标系统不会融合,因为它们各自平衡不同的业务和工程权衡以适应其用例。只需考虑一下可审计数据和操作数据之间的差异即可。


但我确实预计围绕集成供应商之间的使用数据的标准会趋同,例如 FinOps 的 FOCUS。


我们需要您的意见。 OpenMeter 是否应该提取指标并与 Prometheus 集成以简化计费和退款用例?


请在我们的开源存储库中告诉我们:https: //github.com/openmeterio/openmeter