为什么需要loki
日志记录本质上是一个事件。大多数语言、应用程序框架或库都支持日志，表现形式可以是字符串这样原始的非结构化数据，也可以是JSON等半结构化数据。开发者可以通过日志来分析应用的执行状况，报错信息，分析性能…… 正因为日志极其灵活，生成非常容易，没有一个统一的结构，所以它的体量也是最大的。
对于单体应用，查看日志我们可以直接登上服务器，用head、tail、less、more等命令进行查看，也可以结合awk、sed、grep等文本处理工具进行简单的分析。但是分布式应用，面对部署在数十数百台机器的应用，亟需一个日志收集、处理、存储、查询的系统
为什么不是EFK？
开源社区最早流行的是Elastic体系的ELK。Logstash负责收集，ElasticSearch负责索引与存储，Kibana负责查询与展示。ElasticSearch支持全文索引可以进行全文搜索，而且支持DocValue可以用于结构化数据的聚合分析。再加上MetricBeats提供了监控指标的收集，APM提供的链路收集，Elastic俨然已是一个集Logging、Metrics、Trace的大一统技术体系。这主要是因为早期的Elastic野心很大，但是这也导致ElasticSearch并不专注在其中的一个领域。
1、使用全文索引受限于分词器，对于日志查询非常鸡肋(两个单词能搜索到，三个单词就搜索不到的现象也不少)。
2、而且索引阶段特别耗时，很多用户都无法忍受ElasticSearch索引不过来时抛出的EsReject。
3、另外，ElasticSearch除了用于全文搜索的倒排索引，还有store按行存储，在_source字段中存储JSON文档，docValue列式存储，对于不熟悉ElasticSearch的开发者来说，意味着存储体量翻了好几倍，ElasticSearch的高性能查询严重依赖于索引缓存，官方建议机器的内存得预留一半给操作系统进行文件缓存，这套吃内存的东西对普通的日志查询简直就是小题大做。
4、还有ElasticSearch在生产环境至少得部署三个节点，否则由于网络波动容易出现脑裂。
5、基于JVM的Logstash极其笨重，经常因为GC无响应导致日志延时，作为采集日志的agent有点喧宾夺主，为此Elastic专门用Go语言开发了轻量级的FileBeat日志采集工具。由FileBeat负责采集，Logstash负责解析处理。
目前K8s生态下以Fluentd和C语言编写的fluent-bit为主作为日志收集工具，Grafana开发的Loki负责存储。Loki去掉了全文索引，使用最原始的块存储，对时间和特定标签做索引，这和Metrics领域的Prometheus类似
Loki是如何存储数据的？
Loki是一个分布式日志聚合系统，它使用类似于Prometheus的标签查询语言来查询和过滤日志数据。Loki的数据存储方式与传统的日志存储方式不同，它使用了一种称为“无索引”的方式来存储数据。
在Loki中，日志数据被存储在称为“块”的文件中。每个块包含一定数量的日志条目，通常是几千到几万条。的大小可以配置，通常在几百MB到几GB之间。
Loki使用了一种称为“切片”的方式来组织块。每个切片包含一定数量的块，通常是几百到几千个。切片的大小也可以配置，通常在几GB到几十GB之间。
Loki使用一种称为“标签索引”的方式来查询和过滤日志数据。标签索引是一种基于标签的元数据存储方式它允许Loki快速地定位包含特定标签值的日志数据。
当Loki接收到新的日志数据时，它会数据写入一个新的块中。如果块已经达到了配置的大小限制，Loki会将块写入一个新的切片中。如果切片已经达到了配置的大小限制，Loki会将切片写入磁盘，并创建一个新的切片。
