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

• 基于ELK + Kafka 的日志分析系统

• Elasticsearch 优化经验

• Elasticsearch 运维实践

ElasticSearch介绍

• 查询近实时

• 内存消耗小，搜索速度快

• 可扩展性强

• 高可用

数据结构

• FST(Finite State Transducer)

• BDK Tree

扩展性

高可用

ElasticSearch全家桶

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

Logstash优点

提供了大量的用于数据过滤，转换的插件 drop: 丢掉不需要的数据 grok : 正则匹配抓取数据 date : 从数据中解析date属性，用作 Elasticsearch document 的 timestamp metrics: 获取 logstash 的 metrics codec.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 个备份， enable_all ，则 Elasticsearch 集群的实际数据增加量约等于 4T 。 

如果每天需要存 4T 数据，假如保存 30 天的数据，需要的最低存储是 120T ，一般还会加 20% 的 buffer 。 

至少 需要准备 144T 的存储空间。根据日志场景的特点，可做 hot-node, warm - node 划分。 

hot-node 通常用 SSD 磁盘， warm-node 采用普通机械盘。

2. 单节点配置：每个节点多少索引，多少 shard ，每个 shard 大小控制在多少。 

根据总数据量和单节点配置，得出集群总体规模。

单节点，根据经验通常 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 节点发来的请求（比如 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/thread_pool / 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集群运维实践

我们主要关注：

• 集群健康状态 2 . 集群索引和搜索性能

• 节点 cpu , memory, disk 使用情况

ElasticSearch优化经验

索引优化

• 提前创建索引

• 避免索引稀疏，index 中 document 结构最好保持一致，如果 document 结构不一致，建议分 index ，用一个有少量 shard 的 index 存放 field 格式不同的 document 。3 . 在加载大量数据时可设置 refresh_interval =-1 ， index.number_of_replicas =0 ，索引完成后再设回 来。4 . load 和 IO 压力不大的情况，用 bulk 比单条的 PUT/DELETE 操作索引效率更高 。5 . 调整 index buffer( indices.memory.index_buffer_size ) 。

• 不需要 score 的 field ，禁用 norms；不需要 sort 或 aggregate 的 field ，禁用 doc_value 。

查询优化

• 使用 routing 提升某一维度数据的查询速度。

• 避免返回太大量的搜索结果集，用 limit 限制。

• 如果 heap 压力不大，可适当增加 node query cache( indices.queries.cache.size ) 。

• 增加 shard 备份可提高查询并发能力，但要注意 node 上的 shard 总量。

• 定期合并 segment 。

阿里云ElasticSearch服务

文章不错？点个【在看】吧！ 👇