剛剛通過了每年1億美元的經常性收入以各種方式,釺已經準備為未來大,獨立的公司。作為這一努力的一部分,我的團隊,網站可靠性工程(行為)組織在釺,一直專注於確保公司的可觀測性工具組織滿足快速增長的需求。在2019年12月,釺處理平均超過七十億傳入的API請求每一天從我們每月二十億活躍用戶。這導致超過70 tb的數據平均每個節日你可以想象,這是一個大量的數據來消化和理解!

自然,這是一個集中區域時增加可觀測性。因為數據集是如此之大,我們之前從來沒有記錄每一個API調用釺用於診斷目的。這導致了一些挑戰將在下麵討論。很大的行為為我們項目是讓更多的員工能夠調試請求數據,提供易於使用的工具,可以幫助我們的客戶更多的信息。manbetx万博全站客户端

從曆史上看,釺等係統Papertrail和哨兵我們使用集中的記錄我們所有的應用程序和係統日誌以及任何意想不到的錯誤。然而,這些係統是用來跟蹤日誌,使用布爾邏輯檢索,篩選問題的工程團隊。因為這一切,他們往往有一個入口點,需要相當的技術背景。哨兵,舉例來說,是非常有用的錯誤。它可以顯示你的堆棧跟蹤錯誤和警告,但這並不意味著作為診斷日誌記錄工具。與此同時,Papertrail集中式log-aggregation服務。它支持跟蹤日誌,分組通過係統或文件,創建警報和縮小在特定的時間戳。然而,我們在Papertrail數以萬計的服務器。集中的日誌管理是有益的,但它沒有提供任何可視化。最重要的是,日誌管理係統通常由g收費,和我們所有的請求數據達到tb,每天一個新的內部解決方案似乎最優和提供額外的幫助我們了解我們的高水平的數據。

我們也注意到我們在日常支持和成功團隊將不得不向工程團隊尋求幫助當故障排除特定的API調用在大海的每天七十億個電話。這個工作當我們是一個小公司隻有幾個customers-however,我們知道這種模式不會規模。manbetx万博全站客户端作為我們的發展計劃的一部分,團隊啟程來提高我們自己的可觀測性,和解決這些各種各樣的痛點。

釺使用內容分發網絡急劇。快速是我們網絡的最外層、路由流量我們的API端點,並提供分析和邏輯,在邊緣。急劇指導客戶的流量需要去的地方。manbetx万博全站客户端

快速有一個直觀、性能層測井和分析本質上建成的。我們可以看到類似的總要求:

他們還讓你看到不同的故障響應代碼你返回:

這是一個非常有用的方法來可視化和理解數據。然而,我們想知道如果我們可以複製這種模式在其他有用的方麵。例如,如果我們想看到這個趨勢為一個客戶,不允許我們向鑽。快速,但事實證明,提供了一個直接從釺網絡登錄服務的優勢。這是更有用的日誌從應用程序代碼中,在特定的一個原因。當主動規劃對於故障場景,我們知道有一些情況下,我們的API服務器會在能力和不能接受任何更多的數據。不幸的是,在這種情況下,我們必須把一些請求,如果我們從應用程序代碼記錄,我們會想念日誌完全這些請求!然而,如果從急劇發生日誌,我們仍然可以捕捉的請求。這非常重要,因為如果我們放棄一個請求,這是一個最有價值的時代有日誌!

所以我們開始快速整合日誌與麋鹿堆棧。麋鹿是一個縮寫,代表三個獨立的服務:Elasticsearch,logstash,Kibana。

• Elasticsearch是一種數據存儲的索引和存儲大量的數據。
• Logstash收集、解釋和轉換數據。
• Kibana是網頁界麵,允許您可視化數據。

堆棧還包括一個額外的元素:卡夫卡。因為大量的請求和大量的數據我們處理(每月超過兩個pb),我們決定利用卡夫卡從Logstash消費數據和Elasticsearch發布數據,為我們提供一個優雅的緩衝區。卡夫卡給我們停頓和重複數據的能力,同時也給我們一個更優雅比Elasticsearch錯誤處理工具包。Elasticsearch並不總是處理的數據量很好,所以能夠暫停,回放數據時錯誤可以幫助確保沒有數據丟失。最後,在卡夫卡集我們是不會過時的,因為我們總是可以擴大經紀人和添加更多的消費者如果我們決定我們想要發布數據在其他地方。

這並不是一個輕鬆的任務,因為我們麵臨著許多挑戰。首先,我們必須把麋鹿與快速設置堆棧卡夫卡處理巨大的體積流量。

我們的團隊必須確保加密來保證我們的數據安全,安全,以及設置路由規則直接所有流量。我們還必須Logstash服務器的數量規模,除了確定最有效的方式來分配CPU和內存。這些服務器需要能夠快速的所有數據發送,然後解析和轉換數據格式卡夫卡預計它的方式。

在高峰,我們快速處理200字節每秒從!卡夫卡為了寫那麼多數據,我們必須執行適當的容量規劃,確保卡夫卡經紀人可以滿足負載。這意味著調整之類的“分區”。Partitions allow you to parallelize a topic by splitting the data in a particular topic across multiple brokers. Each partition can be placed on a separate machine to allow for multiple consumers to read from a topic in parallel, and each partition can be written to separately.

為了讓這一切發生,我工作在這個項目上與我們的DevOps團隊。經過幾個月的努力,我們能夠建立架構,並準備回到快速記錄所有這些不同的信息,我們可能想看看。Kibana web UI,非常健壯的和優雅的Elasticsearch引擎的幫助下,我們現在能夠看到我們的數據在一些非常強大和易於使用的方式。

假設我們想要更多的了解我們的REST API是如何被使用的。一個問題我們之前麵臨的可靠性,我們有大量突發高峰流量。通常隻會持續幾分鍾,和跟蹤客戶的請求,請求的屍體是一種挑戰。manbetx万博全站客户端不了:

這是非常有用的尋找特定的請求和收集更多的數據。使用Kibana,我們可以很容易地放大,看這個API請求的飆升,並收集更多信息激增,如響應代碼、響應時間、用戶代理發送請求,被擊中的端點,甚至更多:

我們也想看看趨勢隨著時間的推移,這是我們選擇Kibana的另一個原因,因為Kibana特性來構建儀表盤可視化這些類型的趨勢。現在我們可以很容易地看到我們的分解各種使用URL端點。下麵的圖顯示了一個崩潰的API交通端點,與間歇峰值07:15和上午。注意所有很少使用端點流量基本保持一致,但endpoint-our攝入endpoint-spiked很高07:15am:

注意到這種趨勢,我們還可以看到不同的公司如何使用端點。按客戶分組相同的圖,我們可以很快看到淡黃色激增請求發生在07:15am和容易識別的顧客:

REST API 20分鍾的流量增長了兩倍多,因為一個客戶!很難規模零星的東西。這就是為什麼有所有這些信息可以幫助我們做出更好的決策。

所有這些細節組合成幾個不同的儀表板使我們能夠了解我們的API的數據量以全新的方式比以往任何時候都更快。我們也可以把任意數量的數據過濾,放大一個特定的公司,狀態代碼,URL,或者其他方式,看看在這些維度變化的趨勢。

最終的想法

自我們的API之上構建這個工具的數據,它給了我們新的方法來解釋的方式聚合。這也是讓更少的技術型員工的樂趣,因為這種方法是非常直觀的,不強迫他們學習一大堆公式或使用命令行來得到他們想要的數據。這是非常重要的,因為它使工程師花更多的時間來構建新的特性,以及讓我們的應用程序的支持團隊獲得正確的信息迅速用更少的人員應對客戶更快。manbetx万博全站客户端

像這樣的項目工作感興趣?我們招聘!