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