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 JSONSorry, 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 參照。我們還有一些「操作方法」指南，包括有關如何將 API 連接到 Grafana 的資訊。
ABR 和 Analytics Engine
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 的所有內容——加入交談！