实践一把Loki,体验掌上起舞的轻盈
原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。
前两天,我们安利了一个轻量级的日志收集工具Loki。有多轻呢?假如她是个姑娘的话,我觉得是可以在手掌上跳舞的。你说她年轻?这不正是魅力所在么?
对此不太熟悉的同学,可以先看这篇文章。可以看到,他是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,欢迎添加好友,进一步交流。
近期热门文章
对2B和2C的一些思考
介绍Serverless,以及一些展望
后端技术索引,中肯火爆。全网转载上百次。
精准点评100多框架,帮你选型