2018年12月25日中午吃完饭后，我们组三人去了一趟中国移动南方基地，去那里参加了一场《Elastic 技术交流会》，在这里不得不吐槽一下南方基地的安保入检是真的严格。
三场会议的体会
体会分别是：
第一场《Elastic Stack 技术讲解及演示和6.5版本的新特性介绍》要点有：
- logstash 与 beats 的关系是服务端与客户端的关系，logstash 对资源占用大，beats 则是轻量级；官方给的建议是logstash最好是独立部署，不要跟业务应用混合；
- 6.5 版本的 Elasticsearch 对内存的利用和回收的改进更大，支持了 java 11 ；官方说到他们的用户升级了版本后，各方面的参数对资源的占用也少了很多。
第二场《中国移动互联公司 Elastic Stack 用户案例》要点有：
- 中移动的ELK规模，业务现状，提升机器的利用率的方法，如：一台机器部署多个节点、多存储盘能提升 io 能力；
- 场景是采集日志到 ELK 栈，对接了14条业务线，日志标准是他们现阶段的业务繁忙点，标准化无论对于哪个公司来说都很重要；
- 也简单谈到了 k8s 的使用场景，封装 logstash 与业务日志的配置到 docker，在 k8s 上跑；
- 一些简单的优化方法，简单谈了一下社区里的工具链；
- 拆分了集群不同的角色，比较神奇的是他们的 client node 配置了128G 内存。
第三场《ECE 自动化运维管理平台介绍及演示》
- 没去听，出去跟官方人员聊技术细节了；
- 简单看了一下ECE，这个分享应该是官方对企业推销的运维一站式解决方案。
与官方架构师沟通
主要聊了一下我们的集群的现状，然后给了点监控信息他看，针对我们现有的问题去问，下面是一些记录：
- 目前我们的集群现有的一些指标比例是正常的。例如 22台节点，4257个分片，12.6Bil 条文档，17.58T 存储使用量；
- 时序的重要性，搜索范围的约束也很重要；
- 一台节点最大的 warm 数据处理能力是 1T 的数据；
聚合是一个较重的操作，会拿出搜索范围内的所有 segments 里的记录到的索引文件，从存储盘读到内存，然后再进行计算；
- 集群角色，master 对资源的要求很低，一些用户也会将 master 节点放到 k8s 上跑，把混合云的优势发挥出来；
- 焦群角色划分出来，会对性能有提升，他说可能会有10%~20%，一些特别的业务场景甚至会有一倍的提升；
- 关于 fielddata 里，他说一般只有文本搜索，关键词高亮的时候是会用到的，也就是说我们可以调小 fielddata 的比例，甚至是关掉；
- 关于 _id 的问题，感觉他也不是很清楚，他给了个说法，可能是 mapping 的问题，但 _id 默认是 keyword 的，没有 mapping 的事；
- 实时处理量与机器数量是线性关系。
都加了这位架构师的微信，后续还能继续沟通。
集群的改进点
听了这个会，我们可以做的改进有：
- 集群角色需要拆分，master 节点对配置需求低；
- 一台机器是可以部署多个节点的，可以充分提升机器的利用率；
- fielddata 配置是可以配少甚至是禁掉；
- 最好是多盘槽的机器，宁愿每个盘的容量少点，也要更多的盘，通常业务瓶颈主要是 io 上，多盘可以分担文件读写 io 的压力。
本文由 Chakhsu Lau 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。