ELK集群部署搭建
业内常用Elastic Stack的部署方案图
各部件说明
- Beats: 一个收集器,可以收集日志文件、http数据包等等
- Kafka:消息队列,用来缓冲存放从Beats流向LogStash数据
- Redis:也用作消息队列(Zset),缓冲存放从Beats流向LogStash数据
- LogStash:数据的处理器,使用多个Filter对数据进行预处理或者丰富数据
- ElasticSearch:数据处理后的最终存储位置,用于数据的存储和索引查询
- Kibana:数据的可视化显示效果
- X-pack:对集群进行一个安全监控验证
常见数据流程
- Logstash->Elasticsearch->Kibana
- Beats->Elasticsearch->Kibana
- Beats->Logstash->Elasticsearch->Kibana
- Beats->Kafka/Redis->Logstash->Elasticsearch->Kibana
综上所述总结
随着流程的细化,系统可靠性得到提高,所以我们接下来选用Beats->Kafka/Redis->Logstash->Elasticsearch->Kibana数据流程作为我们的解决方案。
案例背景
- 对现有轨迹存储方案,环境搭建,数据导入,数据测试,服务编写,测试结果对比
- 性能分析纬度: 数据量,时间范围,空间范围,空间类型
- 数据量:1千万,1亿,10亿条
- 时间范围:1天,1周,1月 时间跨度
- 空间范围:1平方公里,10平方公里,50 平方公里,
- 空间类型:多边形,圆形,矩形
案例分析
- 数据来源较为单一,可以使用PackageBeats或者LogStash直接进行数据采集
- 基于稳定性思考,采用kafka进行弹性消息处理,避免LogStash宕机造成数据丢失
- 数据不需要预处理,可以考虑从Beats->Kafka->ES,但是需要部署Kafka-connector
- 保留LogStash,Beats->Kafka->LogStash->ES ,不需要部署Kafka-connector
案例部署方案图
案例部署说明
- Packetbeat:类似于抓包,从客户端数据源抓取数据
- Kafka:弹性消息队列,缓冲数据源相关数据
- LogStash:消息预处理过滤器,这里主要是用来替代Kafka-connector连接器的作用
- ElasticSearch:存储处理后数据,这里数据无需处理,直接存取即可
- Kibana:对数据进行可视化效果展示
案例资源说明
服务名称 | IP | 运行内存 | 硬盘大小 | CPU |
---|---|---|---|---|
PacketBeat | 192.168.62.10 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
Kafka | 192.168.62.11 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
Logstash | 192.168.62.12 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
ElasticSearch | 192.168.62.13 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
ElasticSearch | 192.168.62.14 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
ElasticSearch | 192.168.62.15 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |
Kibana | 192.168.62.15 | 2GB | 20GB | 酷睿i7-2820QM @ 2.30GHz |