Elasticsearch在日志分析领域应用和运维实践

本次分享是由来自阿里巴巴的高级工程师赵汉青 带来的。主要讲述了：

• 基于ELK + Kafka 的日志分析系统
• Elasticsearch 优化经验
• Elasticsearch 运维实践

ElasticSearch介绍

分布式实时分析搜索引擎，优势包括：

• 查询近实时
• 内存消耗小，搜索速度快
• 可扩展性强
• 高可用

数据结构

• FST(Finite State Transducer)

这种数据结构适用于文本查询。经过对词典中单词前缀和后缀的重复利用，压缩存储空间，压缩比率通常在 3~20 倍之间。O( len ( str )) 的查询时间复杂度。范围搜索，前缀搜索比传统的 hashmap 有明显优点。

• BDK Tree

适用于数值型，地理信息（ geo ）等多维度数据类型。当K=1, 二叉搜索树，查询复杂度 log(N)

K=2, 肯定切分维度，切分点选这个维度的中间点

扩展性

经过索引分片机制，实现集群的横向扩展

高可用

经过shard冗余备份，跨可用区部署，数据快照 (snapshot) 。 应对集群节点故障，数据损坏。

ElasticSearch全家桶

Kibana : 数据可视化，与 elasticsearch 交互。Elasticsearch: 存储，索引，搜索。Logstash: 数据收集，过滤，转换。Beats: 比 logstash 更轻巧 , 更多样化 : Filebeat, Metricbeat, Packetbeat, Winlogbeat …

基于ELK和Kafka的日志分析系统

Logstash优势

提供了大量的用于数据过滤，转换的插件drop: 丢掉不须要的数据grok : 正则匹配抓取数据date : 从数据中解析date属性，用做 Elasticsearch document 的 timestampmetrics: 获取 logstash 的 metricscodec.multiline ：多行数据合成一条记录fingerprint : 防止插入重复的数据

Logstash 缺点：收集 log 效率低，耗资源。Filebeat: 弥补的缺点，但自身插件较少。

使用Kafka进行日志传输

Kafka 有数据缓存能力。Kafka 数据可重复消费。Kafka 自己高可用，防止数据丢失。Kafka 的 throughput 更好。Kafka 使用普遍。

实践经验：不一样的 service ，建立不一样的 topic 。根据 service 的日志量，设定 topic partition 个数。按照 kafka partition 的个数和消费该 topic 的 logstash 的个数，配置 consumer_threads。尽可能明确 logstash 和对应消费的 topic ( s) ，配置消费的 topic 少用通配符。

集群规划的基本问题：

1. 总数据量大小：天天流入多少数据，保存多少天数据。

每日增长的数据量：每日新增的 log 量 * 备份个数 。若是 enable 了 all 字段，则在上面的基础上再翻一倍。 好比天天新增 1T 的 log ，每一个 shard 有 1 个备份， enableall ，则 Elasticsearch 集群的实际数据增长量约等于 4T 。若是天天须要存 4T 数据，假如保存 30 天的数据，须要的最低存储是 120T ，通常还会加 20% 的 buffer 。至少 须要准备 144T 的存储空间。 根据日志场景的特色，可作 hot-node, warm - node 划分。hot-node 一般用 SSD 磁盘， warm-node 采用普通机械盘。

1. 单节点配置：每一个节点多少索引，多少 shard ，每一个 shard 大小控制在多少。
   根据总数据量和单节点配置，得出集群整体规模。
   单节点，根据经验一般 CPU :Memory的配比是1:4。
   Memory : Disk 的配比为 1 : 24 。
   Elasticsearch heap 的 xmx 设置一般不大于 32g 。
   Memory 和 shard 的配比在 1 : 20 ~ 1:25 之间。
   每一个shard的大小不超过 5 0g 。

实践案例分析

产线上出现服务 failover ， backup 集群日志量会突然增大， kafka 里的数据量也忽然增多，单位时间内 logstash 消费 kafka 注 入 Elasticsearch 的数据量也会增大，若是某些正在插入数据的 primary shard 集中在一个 node 上，该 node 会由于须要索引的数据量过大、同时响应多个 logstash bulk 请求等因素，致使该 node 的 Elasticsearch 服务过于繁忙 。

若没法响应 master 节点发来的请求（好比 cluster health heartbeat ）， master 节点会由于等待该节点的响应而被 block ，致使别的节点认为 master 节点丢失，从而触发一系列很是反应，好比重选master 。

若没法及时响应 logstash 请求， logstash connect elasticsearch 便会出现 timeout ， logstash 会认得这个 Elasticsearch 为 dead ，同时再也不消费 kafka 。 Kafka 发如今同一个 consumer group 里面某个 consumer 消失了，便会触发整个 consumer group 作 rebalance ，从而影响别的 logstash 的消费，影响整个集群的吞吐量。

典型 羊群效应 ，须要消除头羊带 来的影响。可经过 elasticsearch API: GET/cat/threadpool / bulk?v&h =name , host,active,queue,rejected,completed 定位哪一个节点比较忙：queue 比较大， rejected 不断增长。 而后经过 GET /cat/shards 找到该 node 上活跃的 shard 。最后再经过 POST /cluster/reroute API 把 shard 移到 load 比较低的 node 上，缓解该 node 的压力。

ElasticSearch集群运维实践

咱们主要关注：

1. 集群健康状态
   2 . 集群索引和搜索性能
2. 节点 cpu , memory, disk 使用状况

集群green ，正常。集群yellow，主要是有 replica shard 未分配。集群 red ，是由于有 primary shard 未分配。

主要缘由：集群 node disk 使用率超过 watermark （ 默认 85% ）。 可经过 api GET/cat/ allocation 查看 node 的磁盘使用率。 可经过 api GET/cluster/ settings 查看 cluster.routing.allocation.enable 是否被禁止。 可经过 api GET /_cluster/allocation/explain? pretty 查看 shard 未分配到 node 的具体缘由。

监控工具推荐使用：cerebro（ https://github.com/lmenezes/cerebro ）

ElasticSearch优化经验

索引优化

1. 提早建立索引
2. 避免索引稀疏，index 中 document 结构最好保持一致，若是 document 结构不一致，建议分 index ，用一个有少许 shard 的 index 存放 field 格式不一样的 document 。
   3 . 在加载大量数据时可设置 refreshinterval =-1 ， index.numberof_replicas =0 ，索引完成后再设回 来。
   4 . load 和 IO 压力不大的状况，用 bulk 比单条的 PUT/DELETE 操做索引效率更高 。
   5 . 调整 index buffer( indices.memory.indexbuffersize ) 。
3. 不须要 score 的 field ，禁用 norms；不须要 sort 或 aggregate 的 field ，禁用 doc_value 。

查询优化

使用 routing 提高某一维度数据的查询速度。避免返回太大量的搜索结果集，用 limit 限制。若是 heap 压力不大，可适当增长 node query cache( indices.queries.cache.size ) 。增长 shard 备份可提升查询并发能力，但要注意 node 上的 shard 总量。按期合并 segment 。

阿里云ElasticSearch服务

阿里云提供的ElasticSearch服务包含了监控、报警、日志可视化、一键扩容等特色

声明：本号全部文章除特殊注明，都为原创，公众号读者拥有优先阅读权，未经做者本人容许不得转载，不然追究侵权责任。

关注个人公众号，后台回复【JAVAPDF】获取200页面试题！5万人关注的大数据成神之路，不来了解一下吗？5万人关注的大数据成神之路，真的不来了解一下吗？5万人关注的大数据成神之路，肯定真的不来了解一下吗？

欢迎您关注《大数据成神之路》

备注:全部内容首发公众号，这里不保证明时性和完整性，你们扫描文末二维码关注哦~