不對全文內容進行索引的Loki到底優秀在哪裏,能夠佔據一部分日誌監控領域

總結下loki的優勢

1.低索引開銷

  • loki和es最大的不一樣是 loki只對標籤進行索引而不對內容索引
  • 這樣作能夠大幅下降索引資源開銷(es不管你查不查,巨大的索引開銷必須時刻承擔)

2.併發查詢+使用cache

  • 同時爲了彌補沒有全文索引帶來的查詢降速使用,Loki將把查詢分解成較小的分片,能夠理解爲併發的grep
  • 同時支持index、chunk和result緩存提速

3.和prometheus採用相同的標籤,對接alertmanager

  • Loki和Prometheus之間的標籤一致是Loki的超級能力之一

4.使用grafana做爲前端,避免在kibana和grafana來回切換

架構說明

架構說明

組件說明

promtail 做爲採集器,類比filebeat

loki至關於服務端,類比es

loki 進程包含 四種角色
  • querier 查詢器
  • ingester 日誌存儲器
  • query-frontend 前置查詢器
  • distributor 寫入分發器
能夠經過loki二進制的 -target參數指定運行角色

read path

  • 查詢器接收HTTP / 1數據請求。
  • 查詢器將查詢傳遞給全部ingesters 請求內存中的數據。
  • 接收器接收讀取的請求,並返回與查詢匹配的數據(若是有)。
  • 若是沒有接收者返回數據,則查詢器會從後備存儲中延遲加載數據並對其執行查詢。
  • 查詢器將迭代全部接收到的數據並進行重複數據刪除,從而經過HTTP / 1鏈接返回最終數據集。

write path

  • 分發服務器收到一個HTTP / 1請求,以存儲流數據。
  • 每一個流都使用散列環散列。
  • 分發程序將每一個流發送到適當的inester和其副本(基於配置的複製因子)。
  • 每一個實例將爲流的數據建立一個塊或將其追加到現有塊中。每一個租戶和每一個標籤集的塊都是惟一的。
  • 分發服務器經過HTTP / 1鏈接以成功代碼做爲響應。

使用本地化模式安裝

下載promtail和loki二進制

wget  https://github.com/grafana/loki/releases/download/v2.2.1/loki-linux-amd64.zip

wget https://github.com/grafana/loki/releases/download/v2.2.1/promtail-linux-amd64.zip

找一臺 linux機器作測試

安裝promtail

mkdir /opt/app/{promtail,loki} -pv 

# promtail配置文件
cat <<EOF> /opt/app/promtail/promtail.yaml
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /var/log/positions.yaml # This location needs to be writeable by promtail.

client:
  url: http://localhost:3100/loki/api/v1/push

scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: varlogs  # A `job` label is fairly standard in prometheus and useful for linking metrics and logs.
      host: yourhost # A `host` label will help identify logs from this machine vs others
      __path__: /var/log/*.log  # The path matching uses a third party library: https://github.com/bmatcuk/doublestar
EOF

# service文件

cat <<EOF >/etc/systemd/system/promtail.service
[Unit]
Description=promtail server
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/opt/app/promtail/promtail -config.file=/opt/app/promtail/promtail.yaml
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=promtail
[Install]
WantedBy=default.target
EOF

systemctl daemon-reload
systemctl restart promtail 
systemctl status promtail

安裝loki

mkdir /opt/app/{promtail,loki} -pv 

# promtail配置文件
cat <<EOF> /opt/app/loki/loki.yaml
auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

ingester:
  wal:
    enabled: true
    dir: /opt/app/loki/wal
  lifecycler:
    address: 127.0.0.1
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 1h       # Any chunk not receiving new logs in this time will be flushed
  max_chunk_age: 1h           # All chunks will be flushed when they hit this age, default is 1h
  chunk_target_size: 1048576  # Loki will attempt to build chunks up to 1.5MB, flushing first if chunk_idle_period or max_chunk_age is reached first
  chunk_retain_period: 30s    # Must be greater than index read cache TTL if using an index cache (Default index read cache TTL is 5m)
  max_transfer_retries: 0     # Chunk transfers disabled

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb_shipper:
    active_index_directory: /opt/app/loki/boltdb-shipper-active
    cache_location: /opt/app/loki/boltdb-shipper-cache
    cache_ttl: 24h         # Can be increased for faster performance over longer query periods, uses more disk space
    shared_store: filesystem
  filesystem:
    directory: /opt/app/loki/chunks

compactor:
  working_directory: /opt/app/loki/boltdb-shipper-compactor
  shared_store: filesystem

limits_config:
  reject_old_samples: true
  reject_old_samples_max_age: 168h

chunk_store_config:
  max_look_back_period: 0s

table_manager:
  retention_deletes_enabled: false
  retention_period: 0s

ruler:
  storage:
    type: local
    local:
      directory: /opt/app/loki/rules
  rule_path: /opt/app/loki/rules-temp
  alertmanager_url: http://localhost:9093
  ring:
    kvstore:
      store: inmemory
  enable_api: true
EOF

# service文件

cat <<EOF >/etc/systemd/system/loki.service
[Unit]
Description=loki server
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/opt/app/loki/loki -config.file=/opt/app/loki/loki.yaml
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=loki
[Install]
WantedBy=default.target
EOF

systemctl daemon-reload
systemctl restart loki 
systemctl status loki

grafana 上配置loki數據源

在grafana explore上配置查看日誌

查看日誌 rate({job="message"} |="kubelet"
前端

算qps rate({job="message"} |="kubelet" [1m])
linux

只索引標籤

以前屢次提到loki和es最大的不一樣是 loki只對標籤進行索引而不對內容索引
下面咱們舉例來看下

靜態標籤匹配模式

以簡單的promtail配置舉例

配置解讀

scrape_configs:
 - job_name: system
   pipeline_stages:
   static_configs:
   - targets:
      - localhost
     labels:
      job: message
      __path__: /var/log/messages
  • 上面這段配置表明啓動一個日誌採集任務
  • 這個任務有1個固定標籤job="syslog"
  • 採集日誌路徑爲 /var/log/messages ,會以一個名爲filename的固定標籤
  • 在promtail的web頁面上能夠看到相似prometheus 的target信息頁面

查詢的時候可使用和prometheus同樣的標籤匹配語句進行查詢

  • {job="syslog"}git

    scrape_configs:
     - job_name: system
     pipeline_stages:
     static_configs:
     - targets:
        - localhost
       labels:
        job: syslog
        __path__: /var/log/syslog
     - job_name: system
     pipeline_stages:
     static_configs:
     - targets:
        - localhost
       labels:
        job: apache
        __path__: /var/log/apache.log
  • 若是咱們配置了兩個job,則可使用{job=~」apache|syslog」} 進行多job匹配
  • 同時也支持正則和正則非匹配

標籤匹配模式的特色

原理

  • 和prometheus一致,相同標籤對應的是一個流github

    prometheus 處理series的模式
  • prometheus中標籤一致對應的同一個hash值和refid(正整數遞增的id),也就是同一個seriesweb

    • 時序數據不斷的append追加到這個memseries中
    • 當有任意標籤發生變化時會產生新的hash值和refid,對應新的series
loki處理日誌的模式
  • 和prometheus一致,loki一組標籤值會生成一個streamexpress

    • 日誌隨着時間的遞增會追加到這個stream中,最後壓縮爲chunk
    • 當有任意標籤發生變化時會產生新的hash值,對應新的stream

查詢過程

  • 因此loki先根據標籤算出hash值在倒排索引中找到對應的chunk?
  • 而後再根據查詢語句中的關鍵詞等進行過濾,這樣能大大的提速
  • 由於這種根據標籤算哈希在倒排中查找id,對應找到存儲的塊在prometheus中已經被驗證過了apache

    • 屬於開銷低
    • 速度快

動態標籤和高基數

因此有了上述知識,那麼就得談談動態標籤的問題了

兩個概念

何爲動態標籤:說白了就是標籤的value不固定api

何爲高基數標籤:說白了就是標籤的value可能性太多了,達到10萬,100萬甚至更多緩存

promtail支持在 pipline_stages中用正則匹配動態標籤

  • 好比apache的access日誌服務器

    11.11.11.11 - frank [25/Jan/2000:14:00:01 -0500] "GET /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
  • 在promtail中使用regex想要匹配 actionstatus_code兩個標籤

  • job_name: system
    pipeline_stages:

    - regex:
      expression: "^(?P<ip>\\S+) (?P<identd>\\S+) (?P<user>\\S+) \\[(?P<timestamp>[\\w:/]+\\s[+\\-]\\d{4})\\] \"(?P<action>\\S+)\\s?(?P<path>\\S+)?\\s?(?P<protocol>\\S+)?\" (?P<status_code>\\d{3}|-) (?P<size>\\d+|-)\\s?\"?(?P<referer>[^\"]*)\"?\\s?\"?(?P<useragent>[^\"]*)?\"?$"
    • labels:
      action:
      status_code:

    static_configs:

    • targets:

      • localhost

      labels:
      job: apache
      env: dev
      __path__: /var/log/apache.log

  • 那麼對應action=get/post 和status_code=200/400則對應4個流

    11.11.11.11 - frank [25/Jan/2000:14:00:01 -0500] "GET /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
    11.11.11.12 - frank [25/Jan/2000:14:00:02 -0500] "POST /1986.js HTTP/1.1" 200 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
    11.11.11.13 - frank [25/Jan/2000:14:00:03 -0500] "GET /1986.js HTTP/1.1" 400 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
    11.11.11.14 - frank [25/Jan/2000:14:00:04 -0500] "POST /1986.js HTTP/1.1" 400 932 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6"
  • 那四個日誌行將變成四個單獨的流,並開始填充四個單獨的塊。
  • 若是出現另外一個獨特的標籤組合(例如status_code =「 500」),則會建立另外一個新流

高基數問題

  • 就像上面,若是給ip設置一個標籤,如今想象一下,若是您爲設置了標籤ip,來自用戶的每一個不一樣的ip請求不只成爲惟一的流
  • 能夠快速生成成千上萬的流,這是高基數,這能夠殺死Loki
  • 因此爲了不高基數則應該避免使用這種取值分位太大的標籤

若是字段沒有被當作標籤被索引,會不會致使查詢很慢

Loki的超級能力是將查詢分解爲小塊並並行分發,以便您能夠在短期內查詢大量日誌數據

全文索引問題

  • 大索引既複雜又昂貴。一般,日誌數據的全文索引的大小等於或大於日誌數據自己的大小
  • 要查詢日誌數據,須要加載此索引,而且爲了提升性能,它可能應該在內存中。這很難擴展,而且隨着您攝入更多日誌,索引會迅速變大。
  • Loki的索引一般比攝取的日誌量小一個數量級,索引的增加很是緩慢

那麼如何加速查詢沒有標籤的字段

以上邊提到的ip字段爲例
  • 使用過濾器表達式查詢

    {job="apache"} |= "11.11.11.11"

loki 查詢時的分片 (按時間範圍分段grep)

  • Loki將把查詢分解成較小的分片,併爲與標籤匹配的流打開每一個區塊,並開始尋找該IP地址。
  • 這些分片的大小和並行化的數量是可配置的,並取決於您提供的資源
  • 若是須要,您能夠將分片間隔配置爲5m,部署20個查詢器,並在幾秒鐘內處理千兆字節的日誌
  • 或者,您能夠發瘋並設置200個查詢器並處理TB的日誌!

兩種索引模式對比

  • es的大索引,無論你查不查詢,他都必須時刻存在。好比長時間佔用過多的內存
  • loki的邏輯是查詢時再啓動多個分段並行查詢

在日誌量少的時候少加標籤

  • 由於每多加載一個chunk就有額外的開銷
  • 舉例 若是該查詢是{app="loki",level!="debug"}
  • 在沒加level標籤的狀況下只需加載一個chunk 即app="loki"的標籤
  • 若是加了level的狀況,則須要把level=info,warn,error,critical 5個chunk都加載再查詢

在須要標籤時再去添加

  • 當chunk_target_size=1MB時表明 以1MB的壓縮大小來切割塊
  • 對應的原始日誌大小在5MB-10MB,若是日誌在 max_chunk_age時間內能達到10MB,考慮添加標籤

日誌應當按時間遞增

  • 這個問題和tsdb中處理舊數據是同樣的道理
  • 目前loki爲了性能考慮直接拒絕掉舊數據
相關文章
相關標籤/搜索