ElasticSearch构建千亿级日志分析系统-离线分析

1、背景介绍

上篇讲到实时日志的采集和分析，本篇介绍离线日志的分析，为何要做离线日志分析？业务场景的不同，系统的规模扩大后，日志量随着上升，上升到需要付出昂贵的成本才能满足分析，动辄每天几TB的日志，给索引和查询都带来很大的压力，

为尽量满足查询分析的诉求又合理控制成本，我们需要设计一套离线日志采集与分析系统，主要满足如下业务场景：

1)回溯半个月前的问题，遇到长假系统会在线上运行一周无人分析定位业务问题，而实时系统存储的数据量有限，半个月前的日志在实时系统已经查不到（过期删除），为回溯定位问题，我们可以从离线日志系统中拉取日志进行分析；

2)访问日志特征分析，例如，分析过去一个月的网站访问日志；

3)分析业务系统的全量日志，很多同学为定位问题方便习惯在线上打印很多Debug日志，Debug记录了详细的流水信息，往往日志量比较大，如果实时上传会给实时日志系统带来很大冲击，合理的做法是上传关键的Info日志，解决大部分问题定位，如需查找Debug日志进行详细的问题定位可以通过离线日志进行分析。

 

架构包含采集器、云存储、处理器、存储分析四个模块。

2、采集器

离线采集文件日志，本篇介绍的架构里使用Go语言开发了一个简单的离线日志采集器，监控日志文件目录，定期采集日志上传到AWS S3，如果没有使用AWS服务的同学可以将数据上传到其他云存储，实际场景中为管理方便，可以使用Ansible等配置管理工具来维护采集器（主要解决机器较多时的采集器版本升级），

3、云存储

这里使用了AWS S3服务，一个高可靠低成本的云存储，在AWS推荐的大数据分析方案里把S3作为数据湖解决方案的核心，如果没有使用AWS云平台的同学可以使用其他共享存储，由于本篇主要介绍架构，没有详细讲解实现的过程。

4、处理器

选择需要分析的时间段，读取对应时间段的离线日志，处理器负责将数据写入到ElasticSearch，单次分析的数据量较小可以考虑自己调用ElasticSearch API进行写入，涉及数据量较大可以使用Spark进行分析。

5、存储分析

存储使用全文搜索引擎ElasticSearch，ElasticSearch是一款高效率的全文索引软件，满足日志存储与分析的业务场景，

根据语言的区别我们可以设置不同的分词器来优化查询，分析工具使用Kibana，功能比较强大的UI分析工具，满足日常查询。

ElasticSearch官方地址：https://www.elastic.co/cn/elasticsearch

Kibana官方地址：https://www.elastic.co/cn/kibana

6、总结

对实时性要求不高的场景，离线分析基本上满足了问题定位于分析，通过合理的设置日志文件的切割大小，离线分析实际上可以做到小时级别的时效性，这种方案的性价比比较高，分析完的日志可以清理，离线分析的ElasticSearch集群的规模可以设置得比较小，如果规模上升到一定程度，应用节点较多会给运维工作带来一定的复杂度，后续会单独讲DevOps章节，如何提高运维效率，随业务的发展，整个架构系统都会随着变化。