主要講述了：

• 基于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 date_Elasticsearch在日志分析领域应用和运维实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。