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萬人關注的大數據成神之路，肯定真的不來了解一下嗎？

歡迎您關注《大數據成神之路》

備註:全部內容首發公衆號，這裏不保證明時性和完整性，你們掃描文末二維碼關注哦~