LPG（Loki+Promtail+Grafana） 日志收集系统实践和踩坑经历

自从买了一套云服务器以后，部署好了kubernetes，也部署了自己写的一套后台接口SHOP，通过Drone+Helm发到自己的kubernetes集群中，因此希望收集服务运行日志供查看。

日志收集系统，一般以ELK架构居多，现在很多也会考虑用 Fluentd 组成EFK。但对于资源有限的集群来说，部署一个ElasticSearch的成本实在太高，幸好现在已经有一套新的低成本开源方案，那就是LPG。也同样能达到日志收集和检索的目的，占用的资源还少。

Loki

Loki是Grafana公司出的一款开源的日志存储和检索系统，对标的是ElasticSearch，但是设计理念完全不同，ElasticSearch核心是倒排索引，而Loki的核心是基于KV标签的索引+原始日志存储。在存储占用上，Loki的占用量天生就比ElasticSearch少，这里我不想具体分析Loki的架构，因为官方文档和一些技术文章都介绍的很详细了，我想从主观上记录下与ElasticSearch使用上的不同点。

1. Loki 更适合日志
   ElasticSearch我们都知道，是一个搜索引擎，可以处理分词、排序、聚合计算等等搜索引擎需要的功能，用于日志的话，更多是在使用它的存储能力和全文检索能力，但实际使用时，不但它提供的排序、聚合等操作我们用不上，还得学习它的检索语法，还得处理好日志字段的索引规则，要优化的点比较多，换句话说，学习成本和维护成本比较高。而我们平常查看日志，无非是希望日志能可靠的存储起来，查询时能根据某些条件进行筛选，就够用了。Loki在设计时也考虑到了这些方面，所以它并不是索引全部的日志记录，而是索引日志的标签，比如说，Node: 10.0.17.1 标签、Service: sk-shop 标签、LogLevel: Info 标签等。可以通过这些标签去缩小日志范围，再通过扫描日志内容的方式grep出需要的日志。听起来好像不靠谱，好比我一个服务每天打印几十G日志，你一条条的筛选内容效率不是O(n)了吗，但实际上，我们日志查询其实只是查某段时间内的日志，实际查询时量没那么大的，而且Loki在筛选是可以并行化筛选，所以速度其实不慢，实测下来并没有什么大的影响。
2. Loki资源占用少
   我本地机器是2核4G，上面不止跑了loki，还跑了很多其它应用，查询速度也没受到什么影响，如果换成ElasticSearch，我怀疑可能这配置都运行不起来。
3. Loki和kubernetes结合的比较好
   Grafana出的很多开源产品，都借鉴了Prometheus的设计，比如标签，比如Prometheus的查询语言是PromQL，Loki就搞出一个LogQL，比如自动服务发现，天生就支持在kubernetes中自动发现，配置起来比较简单，这点也是ElasticSearch做不到的。

Promtail

Promtail说白了就是个Loki专用的日志收集工具，实际上其它的日志收集工具比如：Filebeat、Fluentd等也可以使用，我觉得哪个用的熟练就用那个，都没用过就用Promtail。

Promtail的官方文档藏在Loki文档里面，而且写的比较乱，实际上它的工作流程就是：从配置文件中读取服务发现配置，然后去抓取对应的服务的日志文件，比如配置了kubernetes_sd_config，部署方式是DaemonSet，那就去节点的/var/log下去抓日志文件，它会保存当前读取的日志文件的offset，所以重启也不用担心会重复抓取，在这个抓的过程中，就可以配置一些标签，方便后续查询。

Promtail抓取到文件后，就可以通过它提供的Pipelines能力过滤日志内容，每条日志都会进入Pipelines进行处理，管道的操作可以分为四种：解析、转换、动作、过滤。如果管道什么都不做，那就会把抓到的日志原样送到Loki中存储。

• 解析
  一般是解析日志内容，获取一些KV值，供后序操作读取和使用。比如通过正则表达式去解析出一些匹配组，或者解析js