实践一把Loki，体验掌上起舞的轻盈

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

前两天，我们安利了一个轻量级的日志收集工具Loki。有多轻呢？假如她是个姑娘的话，我觉得是可以在手掌上跳舞的。你说她年轻？这不正是魅力所在么？

日志系统新贵Loki，确实比笨重的ELK轻

对此不太熟悉的同学，可以先看这篇文章。可以看到，他是grafana家族的，界面支持上自然有保证。有了它，就不用在grafana和kibana之间来回切换了。

但是，事情并不是那么简单。作为一个日志收集工具，不可避免的要有agent收集端、日志存储端、日志展现端。

对于Loki这一些列的组件来说，使用最为复杂，配置最为繁琐的部分，其实是它的agent端 promtail 。下面我们就以Linux环境为例，说一下配置方面的东西。

Loki端的安装其实是非常非常简单的。

$ curl -O -L "https://github.com/grafana/loki/releases/download/v1.5.0/loki-linux-amd64.zip"
# extract the binary
$ unzip "loki-linux-amd64.zip"
# make sure it is executable
$ chmod a+x "loki-linux-amd64"

可惜的是，解压之后，只有这么一个执行文件。我们需要手动喂它一个配置文件。

auth_enabled: false

server:
  http_listen_port: 3100

ingester:
  lifecycler:
    address: 127.0.0.1
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
    final_sleep: 0s
  chunk_idle_period: 5m
  chunk_retain_period: 30s

schema_config:
  configs:
  - from: 2020-05-15
    store: boltdb
    object_store: filesystem
    schema: v11
    index:
      prefix: index_
      period: 168h

storage_config:
  boltdb:
    directory: /tmp/loki/index

  filesystem:
    directory: /tmp/loki/chunks

limits_config:
  enforce_metric_name: false
  reject_old_samples: true
  reject_old_samples_max_age: 168h

然后，使用下面的命令启动。

./loki-linux-amd64 -config.file loki.yml

相对于loki来说，promtail的配置就复杂的多。promtail的复杂配置分为四个部分。

• server_config 配置promtail作为一个服务器。开启一个http端口
• client_config 配置promtail怎么连接loki，它作为loki的客户端
• position_config 指明promtail的配置文件在什么地方生成，重启的时候会读取一些信息s
• scrape_config 配置一些常用的抓取策略

我们主要配置的地方，就是 scrape_config 。它又分为几种常见的抓取方式，比如

• journal_config

• syslog_config

• relabel_config

• static_config

• file_sd_config

• kubernetes_sd_config

对于我们来说，最常使用的就是 static_config ，比如指定业务的某个日志文件。这部分的描述很长，具体可以参考github文档。

https://github.com/grafana/loki/blob/master/docs/clients/promtail/configuration.md

经过测试，一个配置文件中，是可以针对不同类型的日志文件同时进行监控的。比如下面的长长的配置文件，就加入了三个抓取策略。这很棒，不用启动多个agent浪费资源。

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://localhost:3100/loki/api/v1/push

scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: 'unit'
  - job_name: system
    pipeline_stages:
    static_configs:
    - labels:
       job: varlogs
       host: yourhost
       __path__: /var/log/*.log
  - job_name: biz001
    pipeline_stages:
    - match:
       selector: '{app="test"}'
       stages:
       - regex:
          expression: '.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*).*component=(?P<component>[a-zA-Z]+)'
       - labels:
          level:
          component:
          ts:
          timestrap:
    static_configs:
    - labels:
       job: biz001
       app: test
       node: 001
       host: localhost
       __path__: /alertmgr/dingtalk/nohup.out

我们配置了三个job（概念见普罗米修斯）， journal ， system 和 biz001 。尤其注意 biz001 的配置，这代表了我们对一些日志的通用配置方式。

首先，看一下biz001的日志格式。

level=info ts=2020-04-30T01:20:38.631Z caller=entry.go:22 component=web http_scheme=http http_proto=HTTP/1.1 http_method=POST remote_addr=[::1]:57710 user_agent=Alertmanager/0.20.0 uri=http://localhost:8060/dingtalk/webhook1/send resp_status=200 resp_bytes_length=2 resp_elapsed_ms=5207.398549 msg="request complete"

在将日志传送到Loki之前，promtail可以对其进行一系列的操作。比如过滤一些日志，提取一些label，替换一些日志的内容等。

对于这部分的操作，现有的日志收集工具都搞了一套自己的，而且都很难用。

比如logstash的ruby脚本（grok），能让人写的怀疑人生。对于Loki的promtail来说，折磨我们的，变成了正则表达式。对应上面日志的输出信息，相应的正则解析就是下面这行。

.*level=(?P<level>[a-zA-Z]+).*ts=(?P<timestamp>[T\d-:.Z]*).*component=(?P<component>[a-zA-Z]+)

不得不说是非常难用了。

整体来说，对日志行的处理，分为四个场景。解析，转换，替换，过滤等。

目测这些函数和处理方式，不是最终版，后面肯定会有变动。因为现在有些用法太难用了。文档暂且放在下面。

https://github.com/grafana/loki/blob/master/docs/clients/promtail/pipelines.md

针对于以上配置的三个job，我们要做一个简单的查询界面了。

登陆到grafana，添加新的数据源Loki。填上地址即可起舞。

在grafana的模版配置里，创建一个变量。语法和prometheus是非常像的。

label_values(up,job)

点击下拉选择框，即可在不同的项目日志之间进行切换。选择不同的时间段，即可查看不同时间区域的数据。

可以看到，相对于ELKB，Loki的使用是非常简单的。但它所宣称的过滤，是需要建立相应的label的，并不和grep命令等同。

对于大型项目来说，这个组件显得有些鸡肋。但从它逆天的star数来看，其实大部分应用，并不是那么庞大，大家只想要一个轻量级的小小日志收集就可以了。

庞大的日志量对任何日志系统来说，都是挑战。建议在目前的使用中，聚焦在错误日志的收集，以及一些非常重要的日志收集上。

作者简介： 小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。