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 社群與團隊交談。