Grafana團隊釋出Loki專案Alpha測試版,這是一個綑綁Grafana指標查詢與視覺化功能的日誌平臺,Loki增加了一個新的客戶端代理Promtail,以及伺服器端的日誌元資料索引和儲存日誌元件。

Grafana是用來監控與分析指標的工具,提供Graphite、InfluxDB和Prometheus儀表板功能。Grafana提供完整的時間序列資料的儀表板解決方案,支援超過40個資料來源,官方提到,現在儀表板故事(Dashboarding Story)已經成熟,他們希望把儀表板解決方案轉變成可觀察的平臺,成為偵錯系統的首選。

由於指標是事件回應的關鍵,警示則通常會以時間序列為條件寫入,但是指標只能用於揭露可預期的行為,需要預先宣告而且基數有限,因此指標只能用來敘述儀表板故事的一半,為了了解完整的事故原因,工程師通常會使用日誌來獲得更詳細的資訊。

事件的處理通常從警示開始,接著查詢儀表板,以找出發生錯誤的服務、主機或是執行個體,而後工程師會嘗試從各日誌中找出錯誤發生的根本原因。但由於目前的狀況,是將指標和日誌儲存在兩個不同的系統中,因此工程師需要轉換查詢,轉換語言成另一個系統的語言與介面。

日誌聚合方法可以簡化這樣的程序,有許多SaaS供應商與開源專案提供了像是時間序列監控專案,幾乎所有的解決方案都使用全文搜尋系統以檢索日誌,雖提供豐富強大的功能集,允許進行複雜的查詢,但對於日誌聚合來說,反而有規模複雜、資源密集且難以操作的問題。Grafana團隊提到,在這些系統執行日誌聚合工作,簡直就像殺雞用牛刀。

由於Grafana團隊對於現有的所有解決方案都不滿意,因此開始著手設計自有的系統Loki。Loki的設計目標,就是要最小化日誌和指標之間上下文切換,而這將有助於事故回應時間和改善使用者體驗。Loki由客戶端的Promtail代理和伺服器端的Distributor與Ingester元件組成。

Distributor從Promtail代理接收日誌資料,從標籤和日誌資料中使用者產生一致雜湊,並且傳送到多個Ingester中。Ingester接收條目建置成一組具特別標籤與時間跨度的日誌,並以gzip進行壓縮。Ingester使用元資料而非日誌內容建誌索引,以便簡單地供使用者進行查詢,還能與時間序列指標標籤相關聯。官方表示,這是在功能與操作複雜性中權衡的結果。

查詢API接受以時間範圍和標籤選擇器為條件,並且能與Ingester溝通尚未更新的最新資料。搜尋可以使用正規表示式,但由於日誌內容未編入索引,因此對內容搜尋的速度會比較緩慢。

經編列的日誌會定期更新至Amazon S3這類的物件儲存中,並指向Cassandra、Bigtable或DynamoDB等資料庫。AWS與GCP等公有雲供應商提供自定義的指標萃取,AWS還提供從指標導航到日誌的功能,兩者都使用不同的查詢語言以查詢日誌資料,而Loki可以簡化這個過程,並解決日誌從短暫來源Kubernetes pod崩潰時丟失的問題。


Advertisement

更多 iThome相關內容