总结下loki的长处

1.低索引开销

loki和es最大的不同是 loki只对标签进行索引而不对内容索引
这样做能够大幅升高索引资源开销(es无论你查不查，微小的索引开销必须时刻承当)

2.并发查问+应用cache

同时为了补救没有全文索引带来的查问降速应用，Loki将把查问分解成较小的分片，能够了解为并发的grep
同时反对index、chunk和result缓存提速

3.和prometheus采纳雷同的标签，对接alertmanager

Loki和Prometheus之间的标签统一是Loki的超级能力之一

4.应用grafana作为前端，防止在kibana和grafana来回切换

架构阐明

地址 https://grafana.com/docs/loki...

架构阐明

组件阐明

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.zipwget 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.yamlserver:  http_listen_port: 9080  grpc_listen_port: 0positions:  filename: /var/log/positions.yaml # This location needs to be writeable by promtail.client:  url: http://localhost:3100/loki/api/v1/pushscrape_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/doublestarEOF# service文件cat <<EOF >/etc/systemd/system/promtail.service[Unit]Description=promtail serverWants=network-online.targetAfter=network-online.target[Service]ExecStart=/opt/app/promtail/promtail -config.file=/opt/app/promtail/promtail.yamlStandardOutput=syslogStandardError=syslogSyslogIdentifier=promtail[Install]WantedBy=default.targetEOFsystemctl daemon-reloadsystemctl restart promtail systemctl status promtail

装置loki

mkdir /opt/app/{promtail,loki} -pv # promtail配置文件cat <<EOF> /opt/app/loki/loki.yamlauth_enabled: falseserver:  http_listen_port: 3100  grpc_listen_port: 9096ingester:  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 disabledschema_config:  configs:    - from: 2020-10-24      store: boltdb-shipper      object_store: filesystem      schema: v11      index:        prefix: index_        period: 24hstorage_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/chunkscompactor:  working_directory: /opt/app/loki/boltdb-shipper-compactor  shared_store: filesystemlimits_config:  reject_old_samples: true  reject_old_samples_max_age: 168hchunk_store_config:  max_look_back_period: 0stable_manager:  retention_deletes_enabled: false  retention_period: 0sruler:  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: trueEOF# service文件cat <<EOF >/etc/systemd/system/loki.service[Unit]Description=loki serverWants=network-online.targetAfter=network-online.target[Service]ExecStart=/opt/app/loki/loki -config.file=/opt/app/loki/loki.yamlStandardOutput=syslogStandardError=syslogSyslogIdentifier=loki[Install]WantedBy=default.targetEOFsystemctl daemon-reloadsystemctl restart loki systemctl status loki

grafana 上配置loki数据源

在grafana explore上配置查看日志

查看日志 rate({job="message"} |="kubelet"
算qps rate({job="message"} |="kubelet" [1m])

只索引标签

之前屡次提到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"}

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统一，雷同标签对应的是一个流
prometheus 解决series的模式
prometheus中标签统一对应的同一个hash值和refid(正整数递增的id)，也就是同一个series
- 时序数据一直的append追加到这个memseries中
- 当有任意标签发生变化时会产生新的hash值和refid，对应新的series

loki解决日志的模式

和prometheus统一，loki一组标签值会生成一个stream
- 日志随着工夫的递增会追加到这个stream中，最初压缩为chunk
- 当有任意标签发生变化时会产生新的hash值，对应新的stream

查问过程

所以loki先依据标签算出hash值在倒排索引中找到对应的chunk?
而后再依据查问语句中的关键词等进行过滤，这样能大大的提速
因为这种依据标签算哈希在倒排中查找id，对应找到存储的块在prometheus中曾经被验证过了
- 属于开销低
- 速度快

动静标签和高基数

所以有了上述常识，那么就得谈谈动静标签的问题了

两个概念

何为动静标签：说白了就是标签的value不固定
何为高基数标签：说白了就是标签的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想要匹配 action和status_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为了性能思考间接回绝掉旧数据