Elasticsearch在日誌分析領域應用和運維實踐

2019 年 10 月 31 日
筆記

By 大數據技術與架構

場景描述：Elasticsearch及相關產品，介紹基於ELK + Kafka 的日誌分析系統，Elasticsearch優化經驗，阿里雲 Elasticsearch服務以及Elasticsearch 運維實踐。

關鍵詞：ELK 運維優化

本次分享是由來自阿里巴巴的高級工程師趙漢青帶來的。主要講述了：

基於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 的 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 使用情況

集群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優化經驗

索引優化

提前創建索引
避免索引稀疏，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服務

阿里雲提供的ElasticSearch服務包含了監控、報警、日誌可視化、一鍵擴容等特點

Elasticsearch在日誌分析領域應用和運維實踐