前言
由于接入日志平台的项目越来越多，ES不堪重负，各项系统性能持续在高位，影响读写性能。原有1.0架构无法满足大量的日志写入ES，所以调整架构，引入2.0版本，提高吞吐量，增加日志缓存层及日志处理层，满足日志大批量多索引查询的需求。
1.0和2.0架构对比
1.0架构如下：
在应用服务器上部署filebeat收集日志，同时对日志格式进行处理，然后将日志直接写入ES；ES为三节点架构。
缺点：1.由于需要进行日志处理，filebeat在应用服务器上需要进行大量计算，导致CPU占用较多，抢占了应用本身的资源。
2.filebeat不经过缓存直接写入ES集群，造成队列变大，影响日志写入的时效性。
3.三台ES集群无法同时承受大量的读写，导致查询变慢，甚至出现超时。
4.由于filebeat直连ES，如果ES集群节点出现，将导致日志写入失败，等到集群恢复后，部分日志无法在ES进行查询。
综上所述，我们升级架构，增加缓存层和处理层，对日志进行缓存，同时进行ES集群的冷热分离，解决上面出现的问题。
2.0架构如下：
将filebeat收集的日志，存储到kafka进行缓存，保留三天数据；然后由logstash从kafka中实时读取数据进行处理，再将处理完的数据写入ES；ES集群由3台server升级为8台，进行冷热分离，热区只保留5天数据，超过5天的数据通过ES的生命周期管理(ILM)，自动转移到冷区并通过脚本将索引关闭，冷区server配置较低，主要用于存储及方便一些历史查询需要。由于热区索引控制，分片数减少，同时采用SSD盘，读写性能提升明显，满足业务及测试的查询需求。
未来3.0架构调整方向思考
1.降低成本冷区存储由硬盘改用OSS归档存储，配置存储策略定期进行清理。
2.增加日志分析及告警功能。
3.如果日志量持续增大考虑将kafka单机改为集群，同时拆分logstash为单独机器。
4.增加热区server数量，做读写分离。