再見,ELK!

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

最近,在對公司容器雲的日誌方案進行設計的時候,發現主流的ELK或者EFK比較重,再加上現階段對於ES複雜的搜索功能很多都用不上最終選擇了Grafana開源的Loki日誌系統,下面介紹下Loki的背景。

背景和動機

當我們的容器雲運行的應用或者某個節點出現問題了,解決思路應該如下:

A69CB788_BDF0_49dc_B59B_368DEF544DFF

我們的監控使用的是基於prometheus體系進行改造的,prometheus中比較重要的是metric和alert,metric是來說明當前或者歷史達到了某個值,alert設置metric達到某個特定的基數觸發了告警,但是這些信息明顯是不夠的。我們都知道,k8s的基本單位是pod,pod把日誌輸出到stdout和stderr,平時有什麼問題我們通常在界面或者通過命令查看相關的日誌,舉個例子:當我們的某個pod的內存變得很大,觸發了我們的alert,這個時候管理員,去頁面查詢確認是哪個pod有問題,然後要確認pod內存變大的原因,我們還需要去查詢pod的日誌,如果沒有日誌系統,那麼我們就需要到頁面或者使用命令進行查詢了:

AE1844ED_F07E_49be_A86E_C0774CD680EB

如果,這個時候應用突然掛了,這個時候我們就無法查到相關的日誌了,所以需要引入日誌系統,統一收集日誌,而使用ELK的話,就需要在Kibana和Grafana之間切換,影響用戶體驗。所以 ,loki的第一目的就是最小化度量和日誌的切換成本,有助於減少異常事件的響應時間和提高用戶的體驗

ELK存在的問題

現有的很多日誌採集的方案都是採用全文檢索對日誌進行索引(如ELK方案),優點是功能豐富,允許複雜的操作。但是,這些方案往往規模複雜,資源佔用高,操作苦難。很多功能往往用不上,大多數查詢只關注一定時間範圍和一些簡單的參數(如host、service等),使用這些解決方案就有點殺雞用牛刀的感覺了。

4A79AB71_109F_4855_93CE_1A2963C8DCB9

因此,Loki的第二個目的是,在查詢語言的易操作性和複雜性之間可以達到一個權衡。

成本

全文檢索的方案也帶來成本問題,簡單的說就是全文搜索(如ES)的倒排索引的切分和共享的成本較高。後來出現了其他不同的設計方案如:OKlog(https://github.com/oklog/oklog),採用最終一致的、基於網格的分佈策略。這兩個設計決策提供了大量的成本降低和非常簡單的操作,但是查詢不夠方便。因此,Loki的第三個目的是,提高一個更具成本效益的解決方案。關注公衆號互聯網架構師,回覆關鍵字2T,獲取最新架構視頻資料。

整體架構

Loki的架構如下:

BFA13057_C247_4563_9C1F_893A70658AF5

不難看出,Loki的架構非常簡單,使用了和prometheus一樣的標籤來作爲索引,也就是說,你通過這些標籤既可以查詢日誌的內容也可以查詢到監控的數據,不但減少了兩種查詢之間的切換成本,也極大地降低了日誌索引的存儲。Loki將使用與prometheus相同的服務發現和標籤重新標記庫,編寫了pormtail, 在k8s中promtail以daemonset方式運行在每個節點中,通過kubernetes api等到日誌的正確元數據,並將它們發送到Loki。下面是日誌的存儲架構:

931FDC3D_4595_4772_A773_25D403D49D89

讀寫

日誌數據的寫主要依託的是Distributor和Ingester兩個組件,整體的流程如下:

93731123_3321_4252_8665_231F1344ACE2

Distributor

一旦promtail收集日誌並將其發送給loki,Distributor就是第一個接收日誌的組件。由於日誌的寫入量可能很大,所以不能在它們傳入時將它們寫入數據庫。這會毀掉數據庫。我們需要批處理和壓縮數據。

Loki通過構建壓縮數據塊來實現這一點,方法是在日誌進入時對其進行gzip操作,組件ingester是一個有狀態的組件,負責構建和刷新chunck,當chunk達到一定的數量或者時間後,刷新到存儲中去。每個流的日誌對應一個ingester,當日志到達Distributor後,根據元數據和hash算法計算出應該到哪個ingester上面。

0246DAB1_6E20_4469_9A65_829515CE63D4

基本上就是將日誌進行壓縮並附加到chunk上面。一旦chunk“填滿”(數據達到一定數量或者過了一定期限),ingester將其刷新到數據庫。我們對塊和索引使用單獨的數據庫,因爲它們存儲的數據類型不同。

E1AFB312_BF58_405a_9046_3E9CEF7C04BD

刷新一個chunk之後,ingester然後創建一個新的空chunk並將新條目添加到該chunk中。

Querier

讀取就非常簡單了,由Querier負責給定一個時間範圍和標籤選擇器,Querier查看索引以確定哪些塊匹配,並通過greps將結果顯示出來。它還從Ingester獲取尚未刷新的最新數據。

對於每個查詢,一個查詢器將爲您顯示所有相關日誌。實現了查詢並行化,提供分佈式grep,使即使是大型查詢也是足夠的。

C6DBDAD2_80A1_494c_888C_E006E022186B

可擴展性

Loki的索引存儲可以是cassandra/bigtable/dynamodb,而chuncks可以是各種對象存儲,Querier和Distributor都是無狀態的組件。對於ingester他雖然是有狀態的但是,當新的節點加入或者減少,整節點間的chunk會重新分配,已適應新的散列環。而Loki底層存儲的實現Cortex已經 在實際的生產中投入使用多年了。有了這句話,我可以放心的在環境中實驗一把了。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/zhibo

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-29
本文作者:互聯網架構師
本文來自:“互聯網架構師”,瞭解相關信息可以關注“互聯網架構師

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章