elk架构生产实际使用

架构图

一台目标机器3个g数据量，集群每天处理n*3 G的数据量，支持上百台目标机器数据收集，处理的数据大部分为时序数据，kafka集群用单分区保证有序性，若增加分区，可进一步提升数据的吞吐量。

架构组件解析

生产者端：目标机器为真实业务数据，采集端采集业务数据日志、服务器网络、io、cpu、内存、硬盘等信息，通过filebeat生产者运输至kafka，并自动生成单分区topic(kafka配置，保证日志的时序性，否则日志容易产生错乱)。

消费者端：logstash多实例组成一个统一消费者组(logstash配置)，保证消费者组内只有一个消费者在消费某个topic数据，不会产生重复数据，并通过模板(logstash配置)运输至elasticsearch，构建需要的索引字段，并对外提供查询服务。

zookeeper在这个过程的作用

1. 为采集端提供分布式配置，解决不同采集需求的变更
2. 同时为采集端提供监控节点作用，随时检测上上层服务是够正常，并随着配置节点的更改而更改自身采集配置
3. 为kafka集群保存topic offset和选主功能
4. 为上层运用提供其他分布式服务

 

生成实践过程中的困难

1. elasticsearch 堆栈内存不够，导致es堆栈报错 ，这个增大es堆栈内存就可以
2. es在实际生产中，占cpu量很高，优化中(查找热线程发现线程一直在refresh，解决方式一：对实时刷新要求较低索引，增加refresh时间，降低cpu阈值；)
3. es实际索引出现字段超过1000的情况，(分解索引，防止字段过多，影响更新速度和查询)
4. 时序日志防错乱问题，解决可用kafka单分区解决， 防重复，logstash统一消费者组，每个消费者只能消费一个主题的分区，不会发生数据重复，若有多个消费者组，则有可能发生两个消费者消费同一分区数据
5. es索引数据定时清理，防止查询效率降低，Kafka数据默认七天自动清理，若需保存，需建立对应表，定时拉取es数据保存至数据库
6. 采集端，go自研，大量脚本需要维护，耗费精力，考虑引入其他监控服务器状态服务
7. es索引状态在生产环境中经常数据不能写入，需要有服务监控索引，es服务状态等，防止数据不更新或者服务挂掉
8. es集群恢复过程中出现锁阻塞，导致集群无法恢复，增大恢复线程数量
9. kafka集群出现挂掉的情况，待排查
10. 当生产上线出现问题，集群不稳定现象很容易出现，排查较难，尤其是kafka和es集群故障，需要监控一些关键状态数据