您好,登录后才能下订单哦!
本篇内容主要讲解“Loki怎么配置使用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Loki怎么配置使用”吧!
Kubernetes
已经成为编排领域事实上的标准,同时Prometheus
也成为基于Kubernetes
平台之上、监控领域的标配。Prometheus
能够收集业务metrics
数据,Grafana
界面展示,AlertManager
告警,一站式的监控框架就此诞生。通过这一套框架可以在线监控服务运行状态,如果不正常,能够通过各种途径通知给相关人员;相关人员通过查看告警信息,通过日志分析出现问题具体原因。
如何查看日志?
我们可以进入Pod
中查询,如果Pod
进程已经崩溃,那么将无法进入容器内部,没关系,Pod
所在宿主机挂载的日志文件,你不得不查询已经崩溃Pod
所在宿主机,然后通过命令行进入宿主机中查询日志,这样的话如果碰到一个服务多个副本运行在同一个节点上,那么可能会出现日志交叉打印的情况,服务崩溃还没有解决,你已经崩溃了,其实出现这种问题的真正原因是Kubernetes
超强的自动横向扩容能力,你可能无法准确预测到服务副本数量和所在节点,大多数公司是基于ELK
(日志收集解决方案)搭建一套日志收集和查看平台,就这一套平台不仅耗费资源,而且需要Kibina
和Grafana
两套平台之间频繁切换,影响工作效率,为了解决此问题Loki
问世。
从此,一站式的监控、告警、日志分析平台解决了我们不用频繁切换系统的麻烦。
基于Loki
的完整的日志收集框架需要三部分完成
Promtail
:日志收集客户端,以DaemonSet
方式运行在各个计算节点上、当然也可以通过sidercar
方式运行在Pod
内部。Promtail
本身可以替换为fluent-bit
或者fluentd
Loki
:日志收集服务端,接收来自Promtail
发送的日志
Grafana
:日志展示
Loki
是一个高可用、可扩展、多租户的日志收集系统,受Prometheus
启发而出现,但Loki
侧重点在于日志并且通过客户端推送获取日志信息,Prometheus
更多在于监控指标并且通过拉取获取指标信息,相比于其它日志系统具有以下优势:
非常节省资源,提供日志压缩功能。
没有把全文添加到索引中,而是把标签加入到索引中,对于用过Prometheus
的人来说,使用起来非常顺手。
非常适合存储和搜索Kubernetes Pod
的日志,因为它能够把Pod
所在的节点信息、容器信息、命名空间、标签添加到索引中。
原生支持Grafana 6.0
以上版本。
它的主要功能是接收来自客户端的日志,Distributor
接收到日志之后,首先会校验正确性,校验通过之后会把它划分为多个批次,并发送给Ingester
。每个发送过来的流都对应一个Ingester
,当日志发送到Distributor
之后,Distributor
会根据hash
和元数据算法计算应该路由到那个Ingester
上。
其中Distributor
和Ingester
之间是通过gRPC
通信,都是无状态应用,支持横向扩展。
它的主要功能是接收来自Distributor
发送的日志并写入到后端存储中,其中后端存储可以是DynamoDB、 S3、 Cassandra、FS
等等。其中需要注意,ingester
会严格验证接收到的日志行是以时间戳升序接收的(即,每个日志的时间戳都比之前的日志晚一些)。
当ingester
收到不遵循此顺序的日志时,日志行将被拒绝,并返回错误(Entry out of order
)。
总结起来说,首先distributor
会接受来自外部数据流请求发送,每个数据流都有自己的一致性hash
,然后distributor
通过计算hash
,把数据流发送到正确的ingester
上面;ingester
会创建chunk
或者或者追加数据到已存在chunk
上面(必须保证租户和标签唯一),最后完成数据存储。
Chunks
是Loki
长期数据存储,旨在提供查询和写入操作,支持DynamoDB、Bigtable、 Cassandra、S3、FS
(单机)。index
是根据chunks
中元数据生成的索引,支持DynamoDB、Bigtable、 Apache Cassandra、BoltDB
(单机)。默认情况下Chunks
使用FS
本地文件系统存储,文件系统存储存在一定的限制,大约可以存储550W
个chunk
,超过这个限制可能会有问题。
Index
使用BoltDB
存储,BoltDB
是相当出名的Go
实现的KV
读写引擎, 用户有etcd
等。如果需要支持高可用部署,则需要引入大数据组件
Ingesters
内存中查询数据,然后再回退到后端存储中查询数据,支持并行化查询和数据缓存。Loki
的配置比较多,配置在/etc/loki/loki.yaml
中,如果需要优化存储或者日志接收出现异常问题时可能需要修改配置。比如Loki
在接收客户端发送日志可能会出现发送速率超过限制,这个时候可能需要修改ingestion_rate_mb
。
使用Loki
的过程中,可能会疑惑,为了提升查询速度,是不是应该使用尽可能多的标签,因为Loki
本身的索引是由标签生成的,使用其它日志系统的情况下,可以通过添加尽可能多的索引解决查询速度慢的问题,这是常见的思维方式。然而Loki
数据存储设计思想是使用尽可能少的索引,因为Loki
本身会把数据存储为多个数据块,并通过标签中的索引匹配数据块。如果你觉得查询速度慢,可以重新配置分片大小和间隔,也可以通过配置的方式使用尽可能多的查询器并行查询。较小的索引和并行蛮力查询与较大/较快的全文本索引之间的这种权衡使Loki
与其他系统相比可以节省成本。操作大索引的成本和复杂性很高,而且索引一旦建立,通常是固定的,如果您要查询或不查询,则全天24
小时付费,这种设计的优点意味着您可以决定要拥有查询要求是什么,可以根据需要进行更改,同时数据被大量压缩并存储在低成本对象存储中,以将固定的运营成本降至最低,同时仍然具有令人难以置信的快速查询功能,Loki
跟云原生思想也是契合的。
Loki
的安装方式大致有四种,TK
(官方推荐)、helm、docker
、二进制部署,我是通过k8s statefulset
方式编排运行的。具体请参考:
https://github.com/grafana/loki/blob/v1.5.0/docs/installation/README.md
看到这个名字就会想到Prometheus
,其实它们设计思想也是相通的,它作为一个客户端端代理运行在计算节点上,当然也可以通过边车模式运行在Pod
中,主要功能是收集日志、为日志流添加标签、推送日志。
clients
:用于配置Loki
服务端地址
positions
:收集日志文件位置,在Kubernetes
中服务以Pod
形式运行,Pod
生命周期有可能随时结束,所以需要记录日志收集位置并挂载到宿主机,通过位置记录方便下次继续收集。
scrape_configs
:日志文件收集配置,支持收集syslog、jouanl、docker、Kubernetes
、以及日志文件。根据收集需求,自行配置。
推荐使用DaemonSet
方式运行,具体参考官方yaml
编排示例:
https://github.com/grafana/loki/blob/v1.5.0/docs/clients/promtail/installation.md
不在赘述。
Grafana
版本应该使用6.0
以上版本。
admin
账号登录
Grafana
实例Configuration > Data Sources
+ Add data source
按钮Loki
服务地址,如果在本地输入
http://localhost:3100
或者
Loki svc
地址:
https://loki:3100
Explore
,会提示
Log labels
搜索按钮,点击即可搜索。到此,相信大家对“Loki怎么配置使用”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。