日誌系統新貴 Loki

2021-10-23 22:32:57 字數 2378 閱讀 2929

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

背景和動機

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

我們的監控使用的是基於prometheus體系進行改造的,prometheus中比較重要的是metric和alert,metric是來說明當前或者歷史達到了某個值,alert設定metric達到某個特定的基數觸發了告警,但是這些資訊明顯是不夠的。

我們都知道,k8s的基本單位是pod,pod把日誌輸出到stdout和stderr,平時有什麼問題我們通常在介面或者通過命令檢視相關的日誌

舉個例子:當我們的某個pod的記憶體變得很大,觸發了我們的alert,這個時候管理員,去頁面查詢確認是哪個pod有問題,然後要確認pod記憶體變大的原因,我們還需要去查詢pod的日誌,如果沒有日誌系統,那麼我們就需要到頁面或者使用命令進行查詢了:

如果,這個時候應用突然掛了,這個時候我們就無法查到相關的日誌了,所以需要引入日誌系統,統一收集日誌,而使用elk的話,就需要在kibana和grafana之間切換,影響使用者體驗。

所以 ,loki的第一目的就是最小化度量和日誌的切換成本,有助於減少異常事件的響應時間和提高使用者的體驗

elk存在的問題

現有的很多日誌採集的方案都是採用全文檢索對日誌進行索引(如elk方案),優點是功能豐富,允許複雜的操作。

但是,這些方案往往規模複雜,資源占用高,操作苦難。很多功能往往用不上,大多數查詢只關注一定時間範圍和一些簡單的引數(如host、service等),使用這些解決方案就有點殺雞用牛刀的感覺了。

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

成本全文檢索的方案也帶來成本問題,簡單的說就是全文搜尋(如:es)的倒排索引的切分和共享的成本較高。

後來出現了其他不同的設計方案如:oklog(採用最終一致的、基於網格的分布策略。

這兩個設計決策提供了大量的成本降低和非常簡單的操作,但是查詢不夠方便。因此,loki的第三個目的是,提高乙個更具成本效益的解決方案。

整體架構

loki的架構如下:

不難看出,loki的架構非常簡單,使用了和prometheus一樣的標籤來作為索引,也就是說,你通過這些標籤既可以查詢日誌的內容也可以查詢到監控的資料,不但減少了兩種查詢之間的切換成本,也極大地降低了日誌索引的儲存。

loki將使用與prometheus相同的服務發現和標籤重新標記庫,編寫了pormtail, 在k8s中promtail以daemonset方式執行在每個節點中,通過kubernetes api等到日誌的正確元資料,並將它們傳送到loki。下面是日誌的儲存架構:

讀寫日誌資料的寫主要依託的是distributor和ingester兩個元件,整體的流程如下:

distributor

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

loki通過構建壓縮資料塊來實現這一點,方法是在日誌進入時對其進行gzip操作,元件ingester是乙個有狀態的元件,負責構建和重新整理chunck,當chunk達到一定的數量或者時間後,重新整理到儲存中去。每個流的日誌對應乙個ingester,當日誌到達distributor後,根據元資料和hash演算法計算出應該到哪個ingester上面。此外,為了冗餘和彈性,我們將其複製n(預設情況下為3)次。

ingester

ingester接收到日誌並開始構建chunk:基本上就是將日誌進行壓縮並附加到chunk上面。一旦chunk「填滿」(資料達到一定數量或者過了一定期限),ingester將其重新整理到資料庫。我們對塊和索引使用單獨的資料庫,因為它們儲存的資料型別不同。

重新整理乙個chunk之後,ingester然後建立乙個新的空chunk並將新條目新增到該chunk中。

querier

讀取就非常簡單了,由querier負責給定乙個時間範圍和標籤選擇器,querier檢視索引以確定哪些塊匹配,並通過greps將結果顯示出來。它還從ingester獲取尚未重新整理的最新資料。

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

可擴充套件性

loki的索引儲存可以是cassandra/bigtable/dynamodb,而chuncks可以是各種物件儲存,querier和distributor都是無狀態的元件。

對於ingester他雖然是有狀態的但是,當新的節點加入或者減少,整節點間的chunk會重新分配,已適應新的雜湊環。而loki底層儲存的實現cortex已經 在實際的生產中投入使用多年了。有了這句話,我可以放心的在環境中實驗一把了。

安裝 loki 輕量級日誌監控系統

文章 自 使用docker compose安裝 yum install y docker composewget o docker compose.yaml 修改docker compose.yaml檔案,設定指定的日誌檔案路徑 nano docker compose.yaml 修改 promtai...

5分鐘搭建輕量級日誌系統Loki

loki 是乙個水平可擴充套件,高可用性,多租戶日誌聚合系統,靈感來自 prometheus 其設計非常經濟高效,易於操作。它不索引日誌的內容,而是為每個日誌流設定一組標籤。與其他日誌聚合系統相比,loki 基於loki的日誌記錄堆疊包含3個元件 大部分文章都是基於 k8s docker compo...

docker容器使用loki收集日誌

loki進行日誌聚合處理 類似elk中的es promtail是日誌收集,類似elk中的logstash filebeat等,如果是只收集docker容器的日誌則可以用loki的docker plugin替代 grafana是日誌顯示,類似elk中的kibana,可以通過各種標籤和表示式過濾顯示日誌...