看到人工智能与5G的快速并共同发展

通过把 logstash 升级至高版本 6.8 避免了这个问题(6.x 版本的 logstash 修复了这个问题，避免了 crash)。

场景 4：磁盘要满了，紧急扩容?

客户的游戏上线有一个月了，原先预估每天最多有 10TB 的数据量，实际则是在运营活动期间每天产生 20TB 的数据，原先 6TB*60=360TB 总量的数据盘使用率也达到了 80%。针对这种情况，我们建议客户使用冷热分离的集群架构，在原先 60 个热节点的基础上，增加一批 warm 节点存储冷数据，利用 ILM(索引生命周期管理)功能定期迁移热节点上的索引到 warm 节点上。

通过增加 warm 节点的方式，客户的集群磁盘总量达到了 780TB， 可以满足最多三个月的存储需求。但是客户的需求还没有满足：

XX 公司运维老大：给我们一个能存放一年数据的方案吧，总是通过加节点扩容磁盘的方式不是长久之计，我们得天天盯着这个集群，运维成本很高!并且一直加节点，ES 会扛不住吧?

bellen: 可以尝试使用我们新上线的支持本地盘的机型，热节点最大支持 7.2TB 的本地 SSD 盘，warm 节点最大支持 48TB 的本地 SATA 盘。一方面热节点的性能相比云盘提高了，另外 warm 节点可以支持更大的磁盘容量。单节点可以支持的磁盘容量增大了，节点数量就不用太多了，可以避免踩到因为节点数量太多而触发的坑。

XX 公司运维老大：现在用的是云盘，能替换成本地盘吗，怎么替换?

bellen: 不能直接替换，需要在集群中新加入带本地盘的节点，把数据从老的云盘节点迁移到新的节点上，迁移完成后再剔除掉旧的节点，这样可以保证服务不会中断，读写都可以正常进行。

XX 公司运维老大：好，可以实施，尽快搞起来!

云盘切换为本地盘，是通过调用云服务后台的 API 自动实施的。在实施之后，触发了数据从旧节点迁移到新节点的流程，但是大约半个小时候，问题又出现了：

XX 公司运维小: bellen, 快看一下，ES 的写入快掉 0 了。


 

bellen:呃，这个可以做，但是需要时间。是否可以采用 hadoop on COS 的架构，把存量的老的索引数据通过工具导入到 COS，通过 hive 去查询，这样成本会非常低，数据依然是随时可查的。

XX 公司运维老大：那不行，我们只想用成熟的 ELK 架构来做，再增加 hadoop 那一套东西，我们没那么多人力搞这个事!

bellen: 好吧，那可以先搞一个集群测试起来，看看性能怎么样。关于存量数据放在 COS 里但是也需要查询的问题，我们可以先制定方案，尽快实施起来。

XX 公司运维老大：行吧，我们现在按每天 10TB 数据量预估，先购买一个集群，能撑 3 个月的数据量就行，能给一个集群配置的建议吗?

bellen: 目前支持单节点磁盘最大 6TB, cpu 和内存的话可以放到 8 核 32G 单节点，单节点跑 2w qps 写入没有问题，后面也可以进行纵向扩容和横向扩容。

XX 公司运维老大：好，我们先测试一下。

场景 2：集群扛不住压力了

N 天后，架构师 A 直接在微信群里反馈：bellen, 客户反馈这边的 ES 集群性能不行啊，使用 logstash 消费 kafka 中的日志数据，跑了快一天了数据还没追平，这是线上的集群，麻烦紧急看一下吧。

我一看，一脸懵, 什么时候已经上线了啊，不是还在测试中吗?

XX 公司运维 B: 我们购买了 8 核 32G*10 节点的集群，单节点磁盘 6TB, 索引设置的 10 分片 1 副本，现在使用 logstash 消费 kafka 中的数据，一直没有追平，kafka 中还有很多数据积压，感觉是 ES 的写入性能有问题。

随后我立即查看了集群的监控数据，发现 cpu 和 load 都很高，jvm 堆内存使用率平均都到了 90%，节点 jvm gc 非常频繁了，部分节点因为响应缓慢，不停的离线又上线。

经过沟通，发现用户的使用姿势是 filebeat+kafka+logstash+elasticsearch, 当前已经在 kafka 中存储了有 10 天的日志数据，启动了 20 台 logstash 进行消费，logstash 的 batch size 也调到了 5000，性能瓶颈是在 ES 这一侧。客户 8 核 32G*10 节点的集群，理论上跑 10w qps 没有问题，但是 logstash 消费积压的数据往 ES 写入的 qps 远不止 10w，所以是 ES 扛不住写入压力了，只能对 ES 集群进行扩容，为了加快存量数据的消费速度，先纵向扩容单节点的配置到 32 核 64GB，之后再横向增加节点，以保证 ES 集群能够最大支持 100w qps 的写入(这里需要注意的是，增加节点后索引的分片数量也需要调整)。

所以一般新客户接入使用 ES 时，必须要事先评估好节点配置和集群规模，可以从以下几个方面进行评估：

• 存储容量：要考虑索引副本数量、数据膨胀、ES 内部任务额外占用的磁盘空间(比如 segment merge)以及操作系统占用的磁盘空间等因素，如果再需要预留 50%的空闲磁盘空间，那么集群总的存储容量大约为源数据量的 4 倍
• 计算资源：主要考虑写入，2 核 8GB 的节点可以支持 5000qps 的写入，随着节点数量和节点规格的提升，写入能力基本呈线性增长
• 索引和分片数量评估：一般一个 shard 的数据量在 30-50GB 为宜，可以以此确定索引的分片数量以及确定按天还是按月建索引。需要控制单节点总的分片数量，1GB 堆内存支持 20-30 个分片为宜;另外需要控制集群整体的分片数量，集群总体的分片数量一般不要超过 3w。

场景 3：logstash 消费 kafka 性能调优

上面遇到的问题是业务上线前没有对集群配置和规模进行合理的评估，导致上线后 ES 集群扛不住了。通过合理的扩容处理，集群最终抗住了写入压力，但是新的问题又随之出现了。

因为 kafka 积压的数据比较多，客户使用 logstash 消费 kafka 数据时，反馈有两个问题：

1. 增加多台 logstash 消费 kafka 数据，消费速度没有线性提升
2. kafka 的不同 topic 消费速度不均匀、topic 内不同 partition 消费的速度也不均匀

经过分析客户 logstash 的配置文件，发现问题出现的原因主要是：

1. topic 的 partition 数量少，虽然 logstash 机器数量多，但是却没有充分利用机器资源并行消费数据，导致消费速度一直上不去
2. 所有 logstash 的配置文件都相同，使用一个 group 同时消费所有的 topic，存在资源竞争的问题

分析后，对 kafka 和 logstash 进行了如下优化：

1. 提高 kafka topic 的分区数量
2. 对 logstash 进行分组;对于数据量较大的 topic，可以单独设置一个消费组进行消费，有一组 logstash 单独使用这个消费组对该 topic 进行消费;其它的数据量较小的 topic，可以共用一个消费组和一组 logstash
3. 每组 logstash 中总的 consumer_threads 数量和消费组总的 partion 数量保持一致，比如有 3 个 logstash 进程，消费的 topic 的 partition 数量为 24， 那么每个 logstash 配置文件中的 consumer_threads 就设置为 8

通过上述优化，最终使得 logstash 机器资源都被充分利用上，很快消费完堆积的 kafka 数据，待消费速度追平生成速度后，logstash 消费 kafka 一直稳定运行，没有出现积压。

另外，客户一开始使用的是 5.6.4 版本的 logstash，版本较老，使用过程中出现因为单个消息体过长导致 logstash 抛异常后直接退出的问题:

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!