阿里巴巴高级工程师赵汉青主要从五个方面对Elasticsearch在日志分析场景的应用与运维实践的问题进行详细讲解，分别对Elasticsearch及相关产品介绍、基于ELK+Kafka的日志分析系统、Elasticsearch运维实践、Elasticsearch优化经验以及阿里云Elasticsearch服务几个方面进行了详细的介绍。
数十款阿里云产品限时折扣中，赶快点击这里，领券开始云上实践吧！
直播视频回顾
PPT下载请点击
以下是精彩视频内容整理：
Elasticsearch及相关产品介绍
Elasticsearch是当下非常热门的分布式实时分析搜索引擎，其主要有查询近实时、内存消耗小搜索速度快、可扩展性强以及高可用等特点。Elasticsearch适用于存储文本数据，存储文本数据结构是用到了FST，主要是对词典中单词前缀和后缀的重复利用并压缩存储空间，压缩比率一般在3-20倍之间。查询复杂度一般是O（len(str)）,并且范围搜索与前缀搜索比传统的hashmap有明显优势。
对于数值型结构采用BKDTree（Block k-d tree）的存储结构，对于数值型数据来说，K=1时为二叉搜索树，查询复杂度是log(N),若K=2,则确定切分维度，切分点选这个维度中间的点。
对于Elasticsearch可扩展性主要是通过索引分片机制来实现的，index即为索引，每个index下面又分为n个shard,真正的数据以doc的形式存储在每个shard中。Elasticsearch的高可用主要是通过shard冗余备份、跨可用区域部署以及数据快照等方式来实现的，并能够应对集群节点故障和数据损坏。
除对于Elasticsearch以外还有一些非常优秀的产品，例如Kibana,其注重的是数据可视化以及与Elasticsearch的交互。Logstash偏向与数据收集、过滤和转换。Beats是一系列比Logstash更灵巧的工具，例如Filebeat、Metricbeat、Packetbeat、Winlogbeat等。
基于ELK+Kafka的日志分析系统
产线日志通过kafka传到ELK集群中，在产线数据收集时推荐使用filebeat与logstash。在ELK集群中主要有三种node,第一个是data node,其下面部署了logstash与Elasticsearch，起作用是消费kafka中的认知数据，将其存储到Elasticsearch设计中。Web node部署了kibana和Elasticsearch，主要是通过kibana访问Elasticsearch的数据，master node主要是安装了Elasticsearch，一般需要奇数个master node。
Logstash的优点
主要的特点是提供了大量的用于数据过滤、转换的插件，比较常用的有以下几种：
- drop:其作用是丢掉不需要的数据。
- grok:其作用是正规匹配抓取数据中想要的数据串。
- date:其作用是从数据中解析date属性，用作Elasticsearch document的timestamp。
- metrics：其作用是获取logstash的metrics。
- codec.multiline：其作用是使多行数据合成一条记录。
- fingerprint：可以防止插入重复的数据。
- Logstash缺点：收集log效率低，并且耗资源。
- Filebeat:弥补了Logstash缺点，但自身插件较少，所以一般情况下将Logstash与filebeat结合使用。
为何使用Kafka进行日志传输？
使用Kafka进行日志传输的原因在于其有数据缓存的能力，并且它的数据可重复消费，Kafka本身具有高可用性，能够很好的防止数据丢失，它的throughput相对来说比较好并且使用广泛。实践经验表明，在产线上收集数据时不同的service尽量创建不同的topic,然后根据service的日志量设定topic partition的个数，按照Kafka partition的个数和消费该topic的logstash的个数配置consumer_threads，尽量明确logstash和对应消费的topic,进而配置消费的topic少用通配符。
进行集群规划时需要考虑一些问题，例如总数据量的大小，每天流入多少数据量，保存多少天数据；以及单节点的配置，每个节点多少个索引和shard，每个shard大小控制在多少等问题，根据总数据量和单节点配置，得出集群总体规模。
问题分析1
每日增加的数据量等同于每日新增的log量*备份个数，如果enable了_all字段，则在上面的基础上再翻一倍。这样一来若每天新增1T的log，每个shard有一个备份，再开一个enable_all的话，则Elasticsearch的集群的实际数据增加量与等于4T。如果每天需要存4T数据，假如数据保存30天，则需要的最低存储是120T，并且一般还会加20%的buffer，那么也就需要准备144T的存储空间。根据日志场景的特点可做hot-node与warm-node的划分，hot-node通常采用SSD磁盘来增加查询效率，而warm-node则采用普通机械磁盘来降低集成成本。
问题分析2
单节点上根据经验CPU与Memory的配比通常是1:4，Memory与Disk的配比是1:24，Elasticsearch heap的xmx设置通常不大于32g，Memory与shard的配比通常在1:20到1:25之间，并且每个shard的大小建议不要超过50g，这样集群才能保证健康的运行。
案例分析
产线上出现服务failover时，backup集群日志量会忽然增大，Kafka里的数据量也会突然增多，单位时间内logstash消费Kafka注入Elasticsearch的数据量也会增大。如果某些正在插入数据的primary shard集中在一个node上，该node会因为需要索引的数据量过大，同时响应多个logstash bulk请求等因素，导致该node的Elasticsearch服务过于繁忙。
若无法响应master节点发来的请求，master节点会因为等待该节点的响应而被block，导致其他节点认为master节点丢失，从而触发一系列非常反应，比如重选master。
若无法及时响应logstash的请求，logstash connect elasticsearch便会出现timeout，logstash会将这个Elasticsearch认成dead，同时不再消费Kafka。Kafka发现在同一个consumer group里面某个consumer消失了，便会触发整个consumer group做rebalance，从而影响别的logstash的消费，进而影响到整个集群的吞吐量。
典型羊群效应
要消除头羊带来的影响，可通过Elasticsearch API定位比较忙的节点，根据queue的大小以及rejected请求的不断增加的个数来判断哪个node是比较忙的，然后通过GET/_cat/shard找到该node上活跃的shard,最后再通过POST/_cluster/reroute API把shard移到load比较低的node上，缓解该node的压力。
Elasticsearch运维实践
运维Elasticsearch集群主要关注一下几个方面：
- 集群健康状态。
- 集群索引和搜索性能。
- 节点CPU、memory以及disk的使用情况。
集群健康状态分为三种，集群green代表健康，集群yellow主要是有replica shard未分配，但不影响集群正常使用，集群red主要是因为有primary shard未分配，会影响集群正常使用。主要原因是集群node disk使用率超过默认值85%，这样一来新的shard就无法分配。这种情况可以通过以下方式查看：
- 通过api GET/_cat/allocation查看node的磁盘使用率。
- 通过api GET/_cluster/settings查看
cluster.routing.allocation.enable是否被禁止。
- 通过api GET/¬_cluster/allocation/explain?pretty查看shard未分配到node的具体原因。
Elasticsearch优化经验
对于索引优化可以提前创建索引，避免索引稀疏，index中的document结构最好保持一致，如果document结构不一致，建议分index，用一个少量shard的index存放field格式不同的document。在加载大量数据使refresh_interval=-1，index.number_of_replicas=0，索引完成后再设回来。Laod和IO压力不大的情况下，用bulk比单条的PUT/DELETE操作索引效率更高。调整index buffer的大小，若不需要field的打分，则可以禁用norms；同样的若不需要sort或aggregate的field，则可以把doc_value属性禁用。
对于查询优化可以使用routing提升一维度数的查询速度；通过limit限制，避免返回太大量的搜索结果集；如果heap压力不大，可适当增加node query cache；增加shard备份可提高查询并发能力，但要注意node上的shard总量；最后是定期合并segment。
阿里云Elasticsearch服务
x-pack
Security提供了Elasticsearch数据的访问的权限管理，可以为不同的人创建不同的账号，对不同的账号赋予不同的权限，这样可以保证不同的团队在同一个ELK系统下数据访问的安全性。
阿里云Elasticsearch性能
Elasticsearch选用5.5.3的版本，每个测试集群有三个节点，分别对2核4G、4核16G和16核64G进行了测试，磁盘选用1T的SSD云盘。压测工具是是由阿里云提供的esrally和rest api，esrally官方数据geonames为3.3GB，单doc为311B，模拟某业务日志数据80GB,单doc为1432B。阿里云自身也提供过了云监控服务、报警服务、Elasticsearch日志的可视化以及节点扩容。
