不要滚动自己的高基数分析，请使用 Workers 分析引擎

Workers Analytics Engine （简称 Analytics Engine）是提供给开发人员的一个新工具，用于存储和分析有关使用 Cloudflare Workers 的时间序列分析信息，现正公测！Analytics Engine 非常擅长从 Cloudflare Workers 收集高基数和大容量数据集的时间序列数据。Cloudflare 使用 Analytics Engine 来提供有关客户如何使用 Cloudflare 产品的洞察。

例如，Analytics Engine 用于观察驱动 Instant Logs 的后端。Instant Logs 允许 Cloudflare 将其域的 HTTP 日志的实时会话流式传送到 Cloudflare 仪表板。Instant Logs 的后端是使用 Cloudflare Workers 构建的。

简而言之，Instant Logs 后端通过接收来自每个处理客户 HTTP 流量的 Cloudflare 服务器的请求来工作。这些请求包含客户 HTTP 流量的 HTTP 日志。然后，Instant Logs 后端通过 WebSocket 将这些 HTTP 日志转发到客户的浏览器。

为了确保 HTTP 日志能够顺利地传递到客户的浏览器，我们需要跟踪所有活动 Instant Logs 会话的请求速率。我们还需要跟踪所有 Cloudflare 数据中心的请求速率，因为 Instant Logs 使用 Cloudflare Workers 构建，且 Cloudflare Workers 建立在 Cloudflare 的庞大网络之上。因此，Instant Logs 的数据集拥有非常庞大的基数。

像 Prometheus 那样的“传统”指标系统不太适合支持高基数数据。幸运的是，这正是 Analytics Engine 设计要解决的问题。因此，我们将所有 Instant Logs 后端请求日志发送到 Analytics Engine。日志，日志，日志!

通过使用 Analytics Engine API (它有一个 SQL 接口)，我们能够可视化上月顶级会话和顶级数据中心的 Instant Logs 后端请求速率。“放大”到一个值得关注的时段也非常快。我们将 Analytics Engine 设计成查询总是在交互性窗口内响应(下文会详细介绍)。这使得它非常适合使用仪表板工具进行交互式调试(在本例中，我们使用的是 Grafana)。

封测期间，我们收到了大量很棒的反馈。开发人员对 SQL API、与 Workers 轻松集成、在 Grafana 中查询数据的能力(未来会有更多的集成)和我们简单的定价模型(免费!)感到兴奋。然而，在进入公测阶段之前，我们需要解决许多问题。

开发人员支持我们选择使用 SQL (世界通用数据库语言)作为 Analytics Engine API 的接口。然而，当开发人员使用 Analytics Engine API 时，他们发现错误消息是不透明的，很难调试。对于公测版本，我们从头开始重写了 API，以提供更好的错误消息传递。

以前：> SELECT column_that_does_not_exist FROM your_dataset FORMAT JSON      Sorry, we were unable to evaluate your query

现在：> SELECT column_that_does_not_exist FROM your_dataset FORMAT JSONcannot select unknown column: "column_that_does_not_exist"

除了了解出了什么问题之外，开发人员还希望了解 API 的功能。对于公测，我们为 Analytics Engine 编写了一个全面的 SQL 参考。我们还有一些 “How To” 指南，包括有关如何将 API 连接到 Grafana 的信息。

Analytics Engine 使用 Cloudflare 的 ABR 技术来快速进行查询。这意味着每个查询都由与查询匹配的数据的分辨率来满足。例如，如果我们查看上个月的数据，我们可能会使用比查看最近一个小时的数据分辨率更低的 Analytics Engine 数据版本。较低分辨率的数据将提供正确的答案，但将在交互窗口内响应。通过使用相同数据的多种不同分辨率，ABR 提供了一致的响应时间。

要考虑数据的不同分辨率，每个事件都携带了关于该事件来自的数据分辨率的信息。该信息编码在 _sample_interval 列。例如，如果一个事件来自原始数据的 1% 数据，则其 _sample_interval 将被设为 100。要重建原始数据中的事件数量，我们可以使用查询：

SELECT sum(_sample_interval) AS count FROM dataset

对于公测，我们将把 _sample_interval 直接暴露给开发人员。将来，我们将通过提供方便的函数来自动考虑数据的不同分辨率，从而使处理该字段变得更容易。我们还希望提供理解这些函数返回的估计的置信度的能力。

这只是 Workers Analytics Engine 的开端。在内部，对根据 Analytics Engine 所捕获数据定义警报的能力需求很高。这也是我们希望开发人员能够做到的事情。

在封测中，字段通过具有基于 1 的索引（blob1、blob2、double1、double2 等）的名称访问。将来，我们将允许开发人员将名称附加到字段，且这些名称将可用于通过 SQL API 检索数据。

我们想在 Cloudflare 仪表板中提供丰富的用户体验(想象一下 Cloudflare 仪表板中类似 Grafana 的东西 )。最终，我们不希望开发人员必须建立自己的基础设施来探索使用 Analytics Engine 捕获的数据。

欢迎立刻试用 Workers Analytics Engine！如果您有任何不支持的想法或更高级的用例，请告诉我们。我们也在 Discord 频道上讨论有关 Analytics Engine 的一切 —— 欢迎加入！