Loki誕生背景

Kubernetes已經(jīng)成為編排領域事實上的標準，同時Prometheus也成為基于Kubernetes平臺之上、監(jiān)控領域的標配。Prometheus能夠收集業(yè)務metrics數(shù)據(jù)，Grafana界面展示，AlertManager告警，一站式的監(jiān)控框架就此誕生。通過這一套框架可以在線監(jiān)控服務運行狀態(tài)，如果不正常，能夠通過各種途徑通知給相關人員；相關人員通過查看告警信息，通過日志分析出現(xiàn)問題具體原因。

如何查看日志？

我們可以進入Pod中查詢，如果Pod進程已經(jīng)崩潰，那么將無法進入容器內部，沒關系，Pod所在宿主機掛載的日志文件，你不得不查詢已經(jīng)崩潰Pod所在宿主機，然后通過命令行進入宿主機中查詢日志，這樣的話如果碰到一個服務多個副本運行在同一個節(jié)點上，那么可能會出現(xiàn)日志交叉打印的情況，服務崩潰還沒有解決，你已經(jīng)崩潰了，其實出現(xiàn)這種問題的真正原因是Kubernetes超強的自動橫向擴容能力，你可能無法準確預測到服務副本數(shù)量和所在節(jié)點，大多數(shù)公司是基于ELK（日志收集解決方案）搭建一套日志收集和查看平臺，就這一套平臺不僅耗費資源，而且需要Kibina和Grafana兩套平臺之間頻繁切換，影響工作效率，為了解決此問題Loki問世。

從此，一站式的監(jiān)控、告警、日志分析平臺解決了我們不用頻繁切換系統(tǒng)的麻煩。

Loki架構設計思路

基于Loki的完整的日志收集框架需要三部分完成

• Promtail：日志收集客戶端，以DaemonSet方式運行在各個計算節(jié)點上、當然也可以通過sidercar方式運行在Pod內部。Promtail本身可以替換為fluent-bit或者fluentd

• Loki:日志收集服務端，接收來自Promtail發(fā)送的日志

• Grafana：日志展示

Loki是一個高可用、可擴展、多租戶的日志收集系統(tǒng)，受Prometheus啟發(fā)而出現(xiàn)，但Loki側重點在于日志并且通過客戶端推送獲取日志信息，Prometheus更多在于監(jiān)控指標并且通過拉取獲取指標信息，相比于其它日志系統(tǒng)具有以下優(yōu)勢：

• 非常節(jié)省資源，提供日志壓縮功能。

• 沒有把全文添加到索引中，而是把標簽加入到索引中，對于用過Prometheus的人來說，使用起來非常順手。

• 非常適合存儲和搜索Kubernetes Pod的日志，因為它能夠把Pod所在的節(jié)點信息、容器信息、命名空間、標簽添加到索引中。

• 原生支持Grafana 6.0以上版本。

Loki內部組件介紹

 

• Distributor

它的主要功能是接收來自客戶端的日志，Distributor接收到日志之后，首先會校驗正確性，校驗通過之后會把它劃分為多個批次，并發(fā)送給Ingester。每個發(fā)送過來的流都對應一個Ingester，當日志發(fā)送到Distributor之后，Distributor會根據(jù)hash和元數(shù)據(jù)算法計算應該路由到那個Ingester上。

 

其中Distributor和Ingester之間是通過gRPC通信，都是無狀態(tài)應用，支持橫向擴展。

• Ingester

它的主要功能是接收來自Distributor發(fā)送的日志并寫入到后端存儲中，其中后端存儲可以是DynamoDB、 S3、 Cassandra、FS等等。其中需要注意，ingester會嚴格驗證接收到的日志行是以時間戳升序接收的（即，每個日志的時間戳都比之前的日志晚一些）。

 

 

當ingester收到不遵循此順序的日志時，日志行將被拒絕，并返回錯誤（Entry out of order）。

總結起來說，首先distributor會接受來自外部數(shù)據(jù)流請求發(fā)送，每個數(shù)據(jù)流都有自己的一致性hash，然后distributor通過計算hash，把數(shù)據(jù)流發(fā)送到正確的ingester上面；ingester會創(chuàng)建chunk或者或者追加數(shù)據(jù)到已存在chunk上面（必須保證租戶和標簽唯一），最后完成數(shù)據(jù)存儲。

• Chunks和index

Chunks是Loki長期數(shù)據(jù)存儲，旨在提供查詢和寫入操作,支持DynamoDB、Bigtable、 Cassandra、S3、FS（單機）。index是根據(jù)chunks中元數(shù)據(jù)生成的索引，支持DynamoDB、Bigtable、 Apache Cassandra、BoltDB（單機）。默認情況下Chunks使用FS本地文件系統(tǒng)存儲，文件系統(tǒng)存儲存在一定的限制，大約可以存儲550W個chunk，超過這個限制可能會有問題。

 

Index使用BoltDB存儲，BoltDB是相當出名的Go實現(xiàn)的KV讀寫引擎, 用戶有etcd等。如果需要支持高可用部署，則需要引入大數(shù)據(jù)組件

• Query
  主要負責調度前端的查詢請求，首先會     Ingesters內存中查詢數(shù)據(jù)，然后再回退到后端存儲中查詢數(shù)據(jù)，支持并行化查詢和數(shù)據(jù)緩存。

Loki配置

Loki的配置比較多，配置在/etc/loki/loki.yaml中，如果需要優(yōu)化存儲或者日志接收出現(xiàn)異常問題時可能需要修改配置。比如Loki在接收客戶端發(fā)送日志可能會出現(xiàn)發(fā)送速率超過限制，這個時候可能需要修改ingestion_rate_mb。

Loki使用建議

使用Loki的過程中，可能會疑惑，為了提升查詢速度，是不是應該使用盡可能多的標簽，因為Loki本身的索引是由標簽生成的，使用其它日志系統(tǒng)的情況下，可以通過添加盡可能多的索引解決查詢速度慢的問題，這是常見的思維方式。然而Loki數(shù)據(jù)存儲設計思想是使用盡可能少的索引，因為Loki本身會把數(shù)據(jù)存儲為多個數(shù)據(jù)塊，并通過標簽中的索引匹配數(shù)據(jù)塊。如果你覺得查詢速度慢，可以重新配置分片大小和間隔，也可以通過配置的方式使用盡可能多的查詢器并行查詢。較小的索引和并行蠻力查詢與較大/較快的全文本索引之間的這種權衡使Loki與其他系統(tǒng)相比可以節(jié)省成本。操作大索引的成本和復雜性很高，而且索引一旦建立，通常是固定的，如果您要查詢或不查詢，則全天24小時付費，這種設計的優(yōu)點意味著您可以決定要擁有查詢要求是什么，可以根據(jù)需要進行更改，同時數(shù)據(jù)被大量壓縮并存儲在低成本對象存儲中，以將固定的運營成本降至最低，同時仍然具有令人難以置信的快速查詢功能，Loki跟云原生思想也是契合的。

Loki安裝

Loki的安裝方式大致有四種，TK（官方推薦）、helm、docker、二進制部署，我是通過k8s statefulset方式編排運行的。具體請參考：

https://github.com/grafana/loki/blob/v1.5.0/docs/installation/README.md

Promtail

看到這個名字就會想到Prometheus，其實它們設計思想也是相通的，它作為一個客戶端端代理運行在計算節(jié)點上，當然也可以通過邊車模式運行在Pod中，主要功能是收集日志、為日志流添加標簽、推送日志。

功能配置

• clients：用于配置Loki服務端地址

• positions：收集日志文件位置，在Kubernetes中服務以Pod形式運行，Pod生命周期有可能隨時結束，所以需要記錄日志收集位置并掛載到宿主機，通過位置記錄方便下次繼續(xù)收集。

• scrape_configs：日志文件收集配置，支持收集syslog、jouanl、docker、Kubernetes、以及日志文件。根據(jù)收集需求，自行配置。

安裝部署

推薦使用DaemonSet方式運行，具體參考官方yaml編排示例：

https://github.com/grafana/loki/blob/v1.5.0/docs/clients/promtail/installation.md

不在贅述。

Grafana配置

Grafana版本應該使用6.0以上版本。

• admin賬號登錄     Grafana實例
• 左側菜單欄點擊     Configuration > Data Sources
• 點擊     + Add data source按鈕
  輸入     Loki服務地址，如果在本地輸入     http://localhost:3100或者     Loki svc地址：     https://loki:3100

• 

• 點擊右側     Explore，會提示     Log labels搜索按鈕，點擊即可搜索。