共计 4309 个字符,预计需要花费 11 分钟才能阅读完成。
前言
提及日志收集搜寻框架,最常看到的解决方案就是 ELK。尽管当初有 Docker、k8s 帮咱们简化了部署流程,但 ELK 对硬件的要求却很高。光是 Elasticsearch 官网就提及到须要 8 GB 内存以上的机器部署,可见占据的资源之多。为了能降本增效 ( 穷~~~),在网上看到了 Grafana 团队的日志框架: Loki。为此进行了深刻的理解并利用在了一些我的项目上。
Loki 介绍
Loki 是 Grafana 团队开源的一款高可用、高拓展、多租户的日志聚合零碎,和 ELK 的组件性能一样,Loki 有负责日志 存储查问 的主服务,有在客户端负责 收集 日志并推送的代理服务,还有 Grafana 最拿手的 可视化 面板展现。
不同的是,Loki 不再依据日志内容去建设大量的索引,而是借鉴了 Prometheus 外围的思维,应用 标签 去对日志进行特色标记,而后归集统计。这样的话,能防止大量的内存资源占用,转向便宜的硬盘存储。当然 Loki 会对日志进行分块存储并压缩,保留大量的元数据索引,兼顾硬盘的查问效率。
除此之外,Loki 还有以下个性:
- 一个 Loki 实例容许面向多个租户,不同租户的数据齐全与其余租户隔离。
- LogQL:Loki 本人的日志查询语言,很容易上手应用的。
- 高拓展性,Loki 的所有组件能够跑在同一个程序里,也能够按微服务的形式去部署它们。
- 反对市面上许多风行的日志客户端插件,能较好的汇合在一起。
说白了,Loki 吸引人的中央就在于领有和 Prometheus 相似机制的时序数据库以及不便拓展的硬盘资源。
Loki 架构
上面,咱们来意识下 Loki 的总体架构。就像后面提及到的,Loki 次要分为了三局部:
- agent client:日志代理客户端,负责收集日志发送到主服务 Loki,目前官网有本人的 client:Promtail,也反对支流的组件,如 Fluentd、Logstash、Fluent Bit 等。
- loki:日志主服务,负责存储收集到的日志以及对日志查问解析。
- grafana:日志数据展现面板。
能够看到,外围的组件其实是 Loki 这个主服务,对于它的外部组成,其实还能够细分为几局部:
- Distributor:负责解决客户端发送过去的日志数据,测验正确性后将其分发给后续组件。
- Ingester:负责将日志按块存储。
- Query frontend:可选服务,对外提供查问 API,负责一些查问调整和整合。
Loki 的简略应用
Loki 的装置
对于 Loki 的装置十分的简略,大伙能够看官网的连贯:Install Grafana Loki with Docker or Docker Compose。自己实际了一下,应用了上面的 yaml 文件,以 docker-compose 形式进行了部署:
version: "3"
services:
loki:
image: grafana/loki:2.4.0
ports:
- "3100:3100"
command: -config.file=/etc/loki/config.yaml
volumes:
- ./config/loki:/etc/loki
- loki-vm:/loki
grafana:
image: grafana/grafana:7.3.0
ports:
- "3000:3000"
volumes:
- grafana-vm:/var/lib/grafana
environment:
GF_SECURITY_ADMIN_PASSWORD: 123456
GF_SERVER_HTTP_PORT: 3000
promtail:
image: grafana/promtail:2.4.0
volumes:
- /var/log:/var/log
command: -config.file=/etc/config.yml
network_mode: "host"
volumes:
- "./config/promtail/etc:/etc"
- "./my-service/log:/var/log"
- "./my-service/log-position:/var/log-position"
volumes:
grafana-vm:
loki-vm:
其中,对于 Loki 的配置文件,在本机的 ./config/loki
目录下须要有个 config.yaml,配置如下:
auth_enabled: false
server:
http_listen_port: 3100
log_level: debug
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
wal:
dir: /loki/wal
compactor:
working_directory: /loki/persistent # 压缩目录,个别也作为长久化目录
compaction_interval: 10m # 压缩距离
retention_enabled: true # 长久化开启
retention_delete_delay: 5m # 过期后多久删除
retention_delete_worker_count: 150 # 过期删除协程数目
schema_config:
configs:
- from: "2020-07-31"
index:
period: 24h
prefix: loki_index_
object_store: filesystem # 长久化形式:本地文件
schema: v11
store: boltdb-shipper
storage_config:
boltdb_shipper:
active_index_directory: /loki/boltdb-index # index 目录
cache_location: /loki/boltdb-cache # cache 目录
filesystem:
directory: /loki/chunks # chunks 目录
limits_config:
retention_period: 240h # 多久过期
对于 promtail 的配置文件,在本机的 ./config/promtail/etc
目录下须要有个 config.yaml,配置如下:
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /var/log-position/positions.yaml # 日志上传地位
client:
url: http://127.0.0.1:3100/loki/api/v1/push
scrape_configs:
- job_name: my-service
static_configs:
- targets:
- localhost
labels:
job: my-service
__path__: /var/log/*.log
其中,在 promtail 的配置文件里有 __path__
门路,这个就是咱们想要上传的 日志文件 门路了,它反对正则表达式。这样的话,只有咱们的服务有新的日志文件产生,那么它就会被 推送 到 Loki 了。
Grafana 的应用
下面将会把日志数据推送到 Loki,接下来咱们就能够应用 Grafana 里的数据展现面板来查问咱们的日志了。在应用之前,咱们还得配置下 Grafana,在 http:// 服务器地址:3000 里输出配置的账号密码后,按以下步骤配置:
Data Sources 配置:
Manage 的配置:
最初一张图的输入框就是咱们想要查找 日志关键字 的中央了!
日志的标签
除了有 String Match
的输出外,咱们还看到了 App 的抉择。而这个 App 的抉择就是咱们提及 Loki 的重点:标签。此标签是咱们在 promtail 配置文件里 scrape_configs 下的 label 里的。只有咱们在这里配置一些标签,那么就能够对收集的日志进行标记而后在此过滤了,比方服务名、命名空间等。此外,它还反对 json 等格局的标签解析。
日志查询语言: LogQL
为了能满足各式各样的查问,比方蕴含、不蕴含、正则等查问,Loki 开发了属于本人的日志查询语言:LogQL。它就像 Prometheus 的 PromQL 一样,具备丰盛的查问语义,例如咱们能够点击如下的查问按钮:
就会跳转到如下界面:
如果咱们想要查找日志不蕴含某些关键字的,那么能够这么输出:
{job="my-service"} != "内容"
LogQL 的应用非常简单,这里列举一些罕用的语法:
|=: 蕴含
!=: 不蕴含
|~: 正则匹配
!~: 不在正则匹配里的
总体上来讲,LogQL 的过滤分为了三种过滤,别离如下:
- 标签匹配(Label matchers):例如 {job=”my-service”},个别至多须要一个标签匹配,否则将检索所有数据了。
- 行过滤器(Line filters):例如 != “ 内容 ”,是对日志内容进行匹配过滤的。
- 标签过滤器(Label filters):须要对标签进行转换计算,效率较低。
在 Loki 的官网里,有对于日志查问的一些最佳实际,上面总结列举一下,不便大家部署时留神:
- 尽量应用动态标签,不应用动静标签,免得产生大量的小块文件
- 在配置文件里尽量应用缓存,能放慢查问速度,配置反对 in-memory、memcached 和 redis。
- Loki 的过滤成果是按标签匹配 (Label matchers)、行过滤器(Line filters)、标签过滤器(Label filters) 逐级递加的,过滤条件越到前面匹配,将会越慢。尽量在后面就进行条件过滤。
遇到的问题
过期配置
在应用本地模式收集日志时,心愿日志的存储能在肯定工夫后革除,免得有限减少。过后看了官网的 Table Manager 和 Compactor。尝试了多种配置后,始终不失效,前面才发现,须要在 limits_config
里也配置。
查问超时
以后应用 Loki 的时候,发现查问日期较远,查问较简单时,会呈现 time out 状况,并且会莫名重启。前面发现原来是 2.4.0 的版本有 bug,会不定时的呈现 AllByUserID
的空指针拜访。前面更新到最新的 2.4.2 版本就能够了。
总结
Loki 在应用的过程中,的确比拟不便简略,特地是汇合了 Grafana 的查问面板以及它的类 Prometheus 的标签机制,让咱们的日志解决方案更加轻量。应用 Loki 期间也的确遇到了很多问题,大伙如果有趣味的话,能够尝试上手,后续一起交换探讨。
感兴趣的敌人能够搜一搜公众号「阅新技术」,关注更多的推送文章。
能够的话,就顺便点个赞、留个言、分享下,感激各位反对!
阅新技术,浏览更多的新常识。