Workers Analytics Engine 是今年早些時候宣布推出的一款新工具，，能讓開發人員及產品團隊構建有關任何內容的時間序列分析，具有高維度、高基數，並可輕鬆擴展。我們為團隊構建了 Analytics Engine，可深入了解他們在 Workers 中執行的程式碼，為最終客戶提供分析，甚至構建基於使用情況的帳單。
在這篇部落格文章中，我們將講述如何使用 Analytics Engine 來構建分析引擎。我們使用分析引擎檢測了專屬的 Analytics Engine SQL API，並使用這些資料來查找錯誤，並確定新產品功能的優先順序。我們希望這能為其他團隊帶來靈感，他們正尋找方法來檢測自己的產品以及蒐集回饋。
我們為何需要分析引擎？
藉由分析引擎，您可以使用短短幾行程式碼從 Workers 產生事件（或「資料點」）。使用 GraphQL 或SQL API，您可以查詢這些事件，並建立有關業務或技術堆疊的實用洞見。如需進一步了解如何開始使用分析引擎，請查閱我們的開發人員文件。
自我們於 9 月發布分析引擎公測版以來，我們一直在基於開發人員的回饋快速添加新功能。不過，在產品的可見性方面，我們還有兩個很大的差距。
首先，我們的工程團隊需要回答典型的可觀測性問題，譬如我們收到了多少個請求，有多少個請求導致錯誤，這些錯誤屬於什麼性質等。他們需要能夠檢視彙整資料（如平均錯誤率或 p99 回應時間），並深入了解單個事件。
其次，由於這是一個新發布的產品，我們正在探尋產品洞見。透過檢測 SQL API，我們能夠了解客戶編寫的查詢及其所看到的錯誤，這有助我們確定缺失功能的優先順序。
我們意識到，Analytics Engine 將成為一個妙不可言的工具，既能解答我們的技術可觀測性問題，亦可蒐集產品洞見。原因就在於，我們能夠記錄向 SQL API 發出的每個查詢事件，然後查詢彙整的效能問題以及客戶執行的單個錯誤及查詢。
在下一節中，我們將引導您了解如何使用 Analytics Engine 來監控此 API。
新增檢測設備至我們的 SQL API
藉由分析引擎 SQL API，您能以與普通資料庫相同的方式來查詢事件資料。幾十年來，SQL 一直是查詢資料最常使用的語言。我們希望提供一個介面，讓您立即開始詢問關於資料的問題，而不必學習新的查詢語言。
我們的 SQL API 會解析使用者 SQL 查詢，執行轉換及驗證，然後針對後端資料庫伺服器予以執行。隨後，我們將有關查詢的資訊重新寫入分析引擎，以便我們能夠運行自己的分析。
從 Cloudflare Worker 寫入資料至分析引擎輕而易舉，我們的文件中已做出解釋。我們以與使用者相同的方式檢測了 SQL API，以下程式碼摘要顯示了我們寫入分析引擎的資料：
這些資料現儲存於分析引擎中，我們隨後能夠提取關於所報告各欄位的洞見。
查詢洞見
透過將我們的分析放在 SQL 資料庫中，您可以自主寫入可能想要的任何查詢。與通常採用預定義方式且具有明確目的之指標等內容相比，您可以定義所需的任何自訂資料集，並輕鬆質詢資料來提出新問題。
我們需要支援包含數萬億個資料點的資料集。為了實現這一點，我們實施了一種稱為自適應位元速率 (ABR) 的取樣方法。透過使用 ABR，如果您有大量的資料，您的查詢可能會返回取樣事件，以便在合理時間內作出回應。如果您有更典型的資料量，分析引擎將查詢您的所有資料。這樣一來，您可以執行想要的任何查詢，並且仍可在短時間內取得回應。現在，您必須說明如何進行查詢的取樣，但我們正探索如何實現自動化。
任何資料可視化工具均可視覺化展示您的分析。Cloudflare 會大量使用 Grafana（您也可以！）。這對於可觀測性用例尤為實用。
觀察查詢回應時間
我們關注的一個查詢為我們提供了後端資料庫叢集效能的相關資訊：
如您所見，99% 的百分位數（對應於要執行的最複雜查詢的 1%）有時會達到大約 300 毫秒的峰值。但平均而言，我們的後端會在 100 毫秒內回應查詢。
此視覺化展示效果本身就是從 SQL 查詢產生的：
來自高基數資料的客戶洞見
分析引擎的另一個用途是從客戶行為中取得洞見。我們的 SQL API 特別適合做這件事，因為您可以充分利用 SQL 的強大功能。得益於我們的 ABR 技術，即使是龐大的資料集，也能執行昂貴的查詢。
我們可使用此功能來幫助確定分析引擎改進的優先順序。我們的 SQL API 支援相當標準的 SQL 方言，但功能尚不完整。如果使用者嘗試執行 SQL 查詢不予支援的作業，則會返回結構化錯誤訊息。這些錯誤訊息會通報至分析引擎。我們能夠彙整客戶遇到的錯誤類型，這有助知曉下一步要優先考量哪些功能。
SQL API 以 type of error: more details 的格式傳回錯誤，因此我們能夠參閱冒號之前的第一部分來了解錯誤類型。我們依此進行分組，並計算該錯誤發生的次數及其影響的使用者數量：
如需使用普通指標系統來執行上述查詢，我們需要利用不同的指標來表示每種錯誤類型。報告來自各微服務的諸多指標會帶來可擴展性挑戰。分析引擎不會出現這種問題，因為其設計用於處理高基數資料。
分析引擎等高基數儲存的另一大優勢是，您可以深入了解具體細節。如果 SQL 錯誤出現激增，我們可能希望知悉哪些客戶遇到問題，以便幫助他們或確定他們想要使用哪些功能。使用另一個 SQL 查詢可輕鬆實現這一點：
Cloudflare 內部素來依賴於查詢後端資料庫伺服器來獲悉此類資訊。藉由分析引擎 SQL API，我們現能向客戶開放我們的技術，以便他們輕鬆蒐集有關其任何規模服務的洞見！
結論及後續措施
我們蒐集的有關 SQL API 使用情況的洞見對我們的產品優先順序決策極為有用。我們已經新增支援 substring 及 position 功能，我們在上面的視覺化展示效果中已經使用。
查看頂部的 SQL 錯誤，我們看到與選擇列相關的許多錯誤。這些錯誤主要來自與 Grafana 外掛程式相關的一些可用性問題。新增對 DESCRIBE 函數的支援應能緩解這種情況，因為沒有這個，Grafana 外掛程式就無法理解表格結構。這一點以及我們 Grafana 外掛程式的其他改進均在我們藍圖的範疇之內。
我們還可以看到，使用者正嘗試查詢不再存在之舊資料的時間範圍。這表明我們的客戶會讚賞延長資料保留期。我們最近將保留期從 31 天延長至 92 天，我們將密切關注這一點，看看是否應提供進一步延期。
我們看到了與常見錯誤或對正確 SQL 語法所產生誤解相關的大量錯誤。這表明我們可以在文件中提供更好的範例或錯誤解釋，以協助使用者排解其查詢的疑難。
敬請關注我們的開發人員文件，以便在我們繼續反覆運算及新增更多功能時獲得通知！
您可以立即開始使用 Workers 分析引擎！分析引擎現已進入公測階段，可免費保留 90 天。立即開始使用或加入我們的 Discord 社群與團隊交談。