· 更多精彩内容，请下载阅读全本《Elastic Stack实战手册》
创作人：朱祝元
审稿人：朱永生
技术架构
- 物理部署：
1master；5 Data；1 Logstash+kibana；3 kafka 3 主 3 从交叉部署
- 应用框架：
项目采用 springboot 作为基础框架开发分布式应用；
- 实施方案：
通过每个应用服务器上部署 filebeat，上传到 kafka；由 kafka 分发消息到 logstash； Logstatsh 写入日志到 Elasticsearch 集群；
- 应用目标：
收集 50 台机器的日志，可以及时发现日志中的错误日志以及日志对应的上下文。
日志解决方案的演进
阶段一、项目上线一切刚开始
每个程序员通过 ssh 将数据 copy 到堡垒机。然后把数据从堡垒机下载到本地处理数据，分析日志；
遇到的问题
- 下载日志到本地，文件太大难以处理：每个日志文件大概 500M，这种体量，Windows 上任何文本工具打开都很吃力，还要下载多个文件，下载速率也有很大影响；
- 远程服务器上查找，服务器关联多：同一个服务部署的有多个节点，那么找一个需要的日志就要多个服务器都执行类似于下面的命令来查找蛛丝马迹：
more INFO-2020-12-17.0.log |grep -C 5 'scanRecord'如果遇到关联的服务日志查询，还会让事情的复杂度变的更高。
阶段二、测试环境建立ELK环境
实践过程：
刚开始的时候 1 master+ 3 data；有一个普遍的认知就是，单个 Elasticsearch data 节点的每个分片数据大小：30GB-50GB。因为我们的系统是 4 核 8G 的配置，因此我们采用了下限，也就是每个 Shard 30G。这样子运行了 3 个月。
采用策略：
按天产生 index，一些 IP，APP 应用名等不需要分词查询的字段都禁用了 index (这样可以节省磁盘)，只保留一周的日志回溯，3 天的日志 alive 查询，4 天的日志 close。一周以上的 index 直接 delete ，晚上 12点 定时执行 forcemerge。
遇到瓶颈，系统扩容：
因为随着系统票件量的提升，日志数据逐步增加。慢慢就会感到系统查询非常慢，磁盘空间慢慢的无法做到保留一周日志回溯，立马进行了系统扩容。
扩容后：
系统会自动进行索引分片重分配，会把分片均匀的分布到所有的节点上。比如刚开始 3 台 data 节点 6 个分片，平均每个机器会有 2 个分片，那么系统扩容一倍后，会变成 6 个 data 节点，那么这 6 个分片，会自动平均分布到 6 个 data 节点上。每个节点有一个 shard。
扩容步骤
修改配置文件
主要修改所有 Elasticsearch 节点的elasticsearch.yml中的 IP 地址，如果一个机器上部署多个节点，记得将端口号加上。
一个机器上部署三个节点实例
discovery.zen.ping.unicast.hosts:["192.168.207.43:9300","192.168.207.43:9301","192.168.207.43:9302"]配合的属性：
http.port: 9202
transport.tcp.port: 9302分批启动ES
- 启动顺序：先启动 master 节点，再启动其他类型的节点。
- 启动命令：
nohup ./bin/elasticsearch > nohup.out 2>&1 &
心路旅程
1、资源并不是充裕的。可以使用 Stack Monitoring 上的磁盘监控功能，随时监控磁盘的剩余空间。
并且，可以在数据可靠性要求允许的情况下，在索引生命周期管理中，把冷数据的index.number_of_replicas设置为 0。
2、最佳的 Kafka 分发效率。如果使用了 Kafka，注意 Kafka 的 Partition 与 Topic 的配置关系，通常来说 Logstash 中 Worker 的数量应该等于或大于 Kafka Partition 的数量，以便于达到最优的分发效率
3、SSD 的取舍。数据量过大。磁盘 IO 也真的能成为瓶颈，对比集群没有数据和集群数据量达到磁盘容量的50%的时候，写入的速率差别很大。业务需求需要实时查询的场景能上 SSD 就上SSD。
创作人简介：
朱祝元，从事 JAVA 企业级应用开发十余年，获得 pmp，acp 项目管理认证。有扎实
的企业级开发经验，以及分布式应用开发架构经验，参与了千万级的复杂项目数据场景
业务处理。
