阿裡巴巴進階工程師趙漢青主要從五個方面對Elasticsearch在日志分析場景的應用與運維實踐的問題進行詳細講解，分别對Elasticsearch及相關産品介紹、基于ELK+Kafka的日志分析系統、Elasticsearch運維實踐、Elasticsearch優化經驗以及阿裡雲Elasticsearch服務幾個方面進行了詳細的介紹。
數十款阿裡雲産品限時折扣中，
趕快點選這裡 ，領券開始雲上實踐吧！ 更多Elasticsearch相關資訊請點選 直播視訊回顧 PPT下載下傳請點選 以下是精彩視訊内容整理：Elasticsearch及相關産品介紹
Elasticsearch是當下非常熱門的分布式實時分析搜尋引擎，其主要有查詢近實時、記憶體消耗小搜尋速度快、可擴充性強以及高可用等特點。Elasticsearch适用于存儲文本資料，存儲文本資料結構是用到了FST，主要是對詞典中單詞字首和字尾的重複利用并壓縮存儲空間，壓縮比率一般在3-20倍之間。查詢複雜度一般是O（len(str)）,并且範圍搜尋與字首搜尋比傳統的hashmap有明顯優勢。
對于數值型結構采用BKDTree（Block k-d tree）的存儲結構，對于數值型資料來說，K=1時為二叉搜尋樹，查詢複雜度是log(N),若K=2,則确定切分次元，切分點選這個次元中間的點。
對于Elasticsearch可擴充性主要是通過索引分片機制來實作的，index即為索引，每個index下面又分為n個shard,真正的資料以doc的形式存儲在每個shard中。Elasticsearch的高可用主要是通過shard備援備份、跨可用區域部署以及資料快照等方式來實作的，并能夠應對叢集節點故障和資料損壞。
除對于Elasticsearch以外還有一些非常優秀的産品，例如Kibana,其注重的是資料可視化以及與Elasticsearch的互動。Logstash偏向與資料收集、過濾和轉換。Beats是一系列比Logstash更靈巧的工具，例如Filebeat、Metricbeat、Packetbeat、Winlogbeat等。
基于ELK+Kafka的日志分析系統
産線日志通過kafka傳到ELK叢集中，在産線資料收集時推薦使用filebeat與logstash。在ELK叢集中主要有三種node,第一個是data node,其下面部署了logstash與Elasticsearch，起作用是消費kafka中的認知資料，将其存儲到Elasticsearch設計中。Web node部署了kibana和Elasticsearch，主要是通過kibana通路Elasticsearch的資料，master node主要是安裝了Elasticsearch，一般需要奇數個master node。
Logstash的優點
主要的特點是提供了大量的用于資料過濾、轉換的插件，比較常用的有以下幾種：
- drop:其作用是丢掉不需要的資料。
- grok:其作用是正規比對抓取資料中想要的資料串。
- date:其作用是從資料中解析date屬性，用作Elasticsearch document的timestamp。
- metrics：其作用是擷取logstash的metrics。
- codec.multiline：其作用是使多行資料合成一條記錄。
- fingerprint：可以防止插入重複的資料。
- Logstash缺點：收集log效率低，并且耗資源。
- Filebeat:彌補了Logstash缺點，但自身插件較少，是以一般情況下将Logstash與filebeat結合使用。
為何使用Kafka進行日志傳輸？
使用Kafka進行日志傳輸的原因在于其有資料緩存的能力，并且它的資料可重複消費，Kafka本身具有高可用性，能夠很好的防止資料丢失，它的throughput相對來說比較好并且使用廣泛。實踐經驗表明，在産線上收集資料時不同的service盡量建立不同的topic,然後根據service的日志量設定topic partition的個數，按照Kafka partition的個數和消費該topic的logstash的個數配置consumer_threads，盡量明确logstash和對應消費的topic,進而配置消費的topic少用通配符。
進行叢集規劃時需要考慮一些問題，例如總資料量的大小，每天流入多少資料量，儲存多少天資料；以及單節點的配置，每個節點多少個索引和shard，每個shard大小控制在多少等問題，根據總資料量和單節點配置，得出叢集總體規模。
問題分析1
每日增加的資料量等同于每日新增的log量*備份個數，如果enable了_all字段，則在上面的基礎上再翻一倍。這樣一來若每天新增1T的log，每個shard有一個備份，再開一個enable_all的話，則Elasticsearch的叢集的實際資料增加量與等于4T。如果每天需要存4T資料，假如資料儲存30天，則需要的最低存儲是120T，并且一般還會加20%的buffer，那麼也就需要準備144T的存儲空間。根據日志場景的特點可做hot-node與warm-node的劃分，hot-node通常采用SSD磁盤來增加查詢效率，而warm-node則采用普通機械磁盤來降低內建成本。
問題分析2
單節點上根據經驗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節點發來的請求，master節點會因為等待該節點的響應而被block，導緻其他節點認為master節點丢失，進而觸發一系列非常反應，比如重選master。
若無法及時響應logstash的請求，logstash connect elasticsearch便會出現timeout，logstash會将這個Elasticsearch認成dead，同時不再消費Kafka。Kafka發現在同一個consumer group裡面某個consumer消失了，便會觸發整個consumer group做rebalance，進而影響别的logstash的消費，進而影響到整個叢集的吞吐量。
典型羊群效應
要消除頭羊帶來的影響，可通過Elasticsearch API定位比較忙的節點，根據queue的大小以及rejected請求的不斷增加的個數來判斷哪個node是比較忙的，然後通過GET/_cat/shard找到該node上活躍的shard,最後再通過POST/_cluster/reroute API把shard移到load比較低的node上，緩解該node的壓力。
Elasticsearch運維實踐
運維Elasticsearch叢集主要關注一下幾個方面：
- 叢集健康狀态。
- 叢集索引和搜尋性能。
-
節點CPU、memory以及disk的使用情況。
叢集健康狀态分為三種，叢集green代表健康，叢集yellow主要是有replica shard未配置設定，但不影響叢集正常使用，叢集red主要是因為有primary shard未配置設定，會影響叢集正常使用。主要原因是叢集node disk使用率超過預設值85%，這樣一來新的shard就無法配置設定。這種情況可以通過以下方式檢視：
- 通過api GET/_cat/allocation檢視node的磁盤使用率。
-
通過api GET/_cluster/settings檢視
cluster.routing.allocation.enable是否被禁止。
- 通過api GET/¬_cluster/allocation/explain?pretty檢視shard未配置設定到node的具體原因。
Elasticsearch優化經驗
對于索引優化可以提前建立索引，避免索引稀疏，index中的document結構最好保持一緻，如果document結構不一緻，建議分index，用一個少量shard的index存放field格式不同的document。在加載大量資料使refresh_interval=-1，index.number_of_replicas=0，索引完成後再設回來。Laod和IO壓力不大的情況下，用bulk比單條的PUT/DELETE操作索引效率更高。調整index buffer的大小，若不需要field的打分，則可以禁用norms；同樣的若不需要sort或aggregate的field，則可以把doc_value屬性禁用。
對于查詢優化可以使用routing提升一次元數的查詢速度；通過limit限制，避免傳回太大量的搜尋結果集；如果heap壓力不大，可适當增加node query cache；增加shard備份可提高查詢并發能力，但要注意node上的shard總量；最後是定期合并segment。
阿裡雲Elasticsearch服務
x-pack
Security提供了Elasticsearch資料的通路的權限管理，可以為不同的人建立不同的賬号，對不同的賬号賦予不同的權限，這樣可以保證不同的團隊在同一個ELK系統下資料通路的安全性。
阿裡雲Elasticsearch性能
Elasticsearch選用5.5.3的版本，每個測試叢集有三個節點，分别對2核4G、4核16G和16核64G進行了測試，磁盤選用1T的SSD雲盤。壓測工具是是由阿裡雲提供的esrally和rest api，esrally官方資料geonames為3.3GB，單doc為311B，模拟某業務日志資料80GB,單doc為1432B。阿裡雲自身也提供過了雲監控服務、報警服務、Elasticsearch日志的可視化以及節點擴容。
大家如果有任何需求與咨詢可以點選連結送出：
https://market.tianchi.aliyun.com/outsource/offer/publish.htm?type=PROJECT