典型問題之一：Elasticsearch集群的磁盤被打爆
造成磁盤被打爆有以下幾種原因：
- 索引泛濫，索引接入無流程管控；
- 索引無生命周期管理；
- 索引分片數量不合理，單分片過大；
- 日志類索引未按天等細粒度划分，單索引過大；
- 多集群復用同一服務器節點；
- 磁盤容量大小不一。
這些問題比較基礎，其實也反映出早期在使用Elasticsearch時沒有很好的規划。針對上面的各種問題，總結了如下幾點實踐經驗：
- 集群管控收斂賬號權限，限制每個賬號操作索引的范圍。避免各個部門或業務隨意復用集群，比如不通過系統申請直接將其它各種日志或業務數據直接Load進Elasticsearch，造成索引泛濫無法治理；
- 索引生命周期管理。不管線上數據還是離線數據，應該有個消亡的過程。比如梳理過程甚至發現3年前的數據還存在，這極大的浪費了磁盤空間；
- 合理的分片數量規划。分片數量的規划其實和我們的數據量有很密切的關系的。比如節點的個數是多少、磁盤的空間是多少，我們建議盡量控制單個分片數量在100G以內，避免單分片過大在均衡時將磁盤打爆；
- 日志類的索引，避免單個過大，按照天划分是比較好的解決方案。如果按照天划分索引仍然很大，這個時候就需要按小時更小粒度的划分規則；
- 不同集群復用相同的服務器分區。由於Elasticsearch有自己的警戒水位線，之間會互相影響，很容易導致磁盤空間觸發達到上限問題。
典型問題之二：Elasticsearch集群寫入變慢
Elasticsearch集群寫入變慢需要考慮以下幾個問題：
- 索引梳理，是否所有信息都要寫入？
- 分片數量是否合理？
- 業務需求是否需要多副本？
- Refresh時間是否可以更大？
- Logstash處理吞吐是否達到瓶頸？
- Translog刷新策略是否要優化？
- 磁盤硬件IO是否太差？
針對上面這幾個問題我們的實踐經驗是：
- 減少不必要的寫入。例如減少沒有必要的大文本類的寫入，因為這些大文本會耗更多的IO；
- 合理設置分片數量。分片數量不是越多越好，分片越多會導致寫入變慢；
- 多副本會極大的影響寫入吞吐。在Elasticsearch的寫入機制里，Primary要等待所有Replica寫完之后才能返回給客戶端；
- 對於日志類的索引沒有必要秒級刷新。大家可能都使用了默認配置刷新時間，其實調整為5秒、10秒也是可以接受的。目前很多日志類的我們設置為60秒；
- Logstash有吞吐瓶頸。之前測評在某一場景下，它的吞吐量也就1-2萬左右。業內還有一些開源的工具替代Logstash，包括一些自研的程序，可以極大的提高寫入的吞吐；
- 明確服務器用的是SSD還是普通的SATA機械盤。ssd的讀寫速度會比普通的SATA機械盤快。目前針對一些業務數據我們采用冷熱分離策略，新數據庫寫入SSD磁盤，早期的數據會自動均衡到SATA機械盤。
開發規范
針對這些影響業務穩定性的問題，我們內部制定了相應的規范約束：
日志類應用：
- 提供容量與吞吐量預估；注：在新業務接入時，我們要求業務方提供當前業務的容量和吞吐量的預估值 ( 例如：每天的增量數據有多少條、保留的時間是多少 )
- 提供靜態mapping結構；注：包括對日志類的業務，我們也強烈建議使用靜態mapping
- 統一接入大數據部門Kafka集群，並提供topic和ClientId；
- 提供Logstash filter過濾規則配置；
- 索引配置，默認5分片1副本 ( 可調整 )；
- 數據保留策略，建議不超過30天；
- 索引按天划分，命名規則建議為：前綴+日期時間戳，如xxx-2020-02-01；注：這里還是強烈建議日志類索引按照天划分
- 禁止私自接入新索引，接入賬號權限限制匹配特定索引前綴。
非日志類應用：
這類多是數據檢索類的服務。
- 提供容量與吞吐量預估；
- 提供業務類型評估，線上一級核心業務優先接入公司主搜服務；
注：因為這會涉及公司的商業搜索策略
- 重要業務獨享集群，非核心業務復用公共集群；注：重要的業務要保證業務的可靠性、穩定性。
- 提供靜態mapping結構；
- 索引配置，默認5分片2副本；注：根據實際業務進行動態調整
- 禁止私自接入新索引，接入賬號權限限制匹配特定索引前綴。
Elasticsearch服務架構
在整合所有Elasticsearch之后，我們統一了Elasticsearch的服務架構：
該架構有以下幾個特點：
- Elasticsearch的每一個節點角色都是獨立的。我們的Master節點和Data節點不會復用，對於大規模集群也會額外增加client節點；
- Elasticsearch的版本統一升級到6.8以上。因為Elasticsearch在6.8版本開始提供基於角色的安全認證，這對我們的索引治理和管控來說是非常重要的，而之前我們有不少Elasticsearch是在裸奔，沒有任何的安全限制；
- 公共的IK插件。現在的分詞插件目前還是使用的默認的IK插件；
- 冷熱數據分離。我們根據索引的業務場景，配置不同類型的數據節點，配合我們的索引管理策略，在低負載的時候 ( 晚上或某個時間點 )，自動調整索引的配置，讓它進行自動遷移。
二、典型應用實踐
1、ELKB簡介
在介紹我們典型的應用實踐之前，我們先再介紹ELKB。
ELKB是一套日志管理方案，它是Elasticsearch、Logstash、Kibana、Beats服務的簡稱。Elasticsearch用於存儲數據，並提供搜索和分析；Logstash用於數據收集及轉換管道，可擴展的插件；Kibana用於對存儲在Elasticsearch中的數據進行可視化展示；Beats用於多類型數據采集器。
ELKB的架構分為三層：數據提取層、數據的存儲層、數據展示層。ELKB將數據的提取、存儲、展示做成套件，這是它比較優勢的地方。
2、應用實踐之一：58實時日志平台
早期階段：
58內部有好多套技術方案實踐，該架構是5年前系統運維部同學維護的一套日志收集平台，有兩條業務線在使用。這個版本當時比較低，它通過Logstash抓取日志，但是Logstash這塊非常消耗資源，經常出現一些穩定性的問題。
現在階段：
目前我們在公司主流的日志平台主要是這種：
工作流程：
- 收集：日志收集使用大數據部門的Flume進行抓取；
- 存儲：數據收集完后會存儲到公司統一的Kafka集群；
- 展示：我們做了日志管理平台-飛流。另外因為Kafka存儲的數據時間有限制，我們將Kafka的數據寫入到線下的KV存儲系統或者一些檢索系統中。監控報警系統可以提供一定的監控。
改進階段：
接着也就演變到了下面這種新的日志平台：
- 收集：在數據抓取層除了使用Flume之外，我們增加了Filebeat等套件；
- 緩存：抓取的數據仍通過公司的Kafka集群進行緩存；
- 過濾轉換訂閱消費：通過Kafka之后的下游消費我們使用Logstash，因為Logstash的單節點的吞吐量有性能瓶頸，我們通過部署多套，並讓多個Logstash節點進行消費。另外一種就是hangout。hangout是攜程一個開源的類似Logstash的Kafka消費組件，它在部分場景下的吞吐量不錯；
- 存儲檢索：使用Elasticsearch；
- 展示：我們還自研了一些應用程序，通過Kibana直接給數據分析師、用研員提供服務。另外部分業務也依靠Elasticsearch做趨勢或者預警方面的功能監控報警平台，以及一些日志管理系統，用於滿足自己的業務需求。
應用實踐之二：MySQL實時慢日志
早期業內大家做MySQL的慢日志系統大都是獲取上一整天的慢日志，進行統一分析，然后生成上一天的慢日志報表。這種方式有一定的滯后性，如果業務調整SQL或者新發布了一個功能想看實時的性能狀況，這種需求是滿足不了的。開發人員需要看到數據庫實時的慢日志，以方便更快的進行性能診斷。我們使用ELKB技術棧來實現：
- 收集：采集層使用公司的agent來管理每個 MySQL 服務器節點上的Filebeat，比如實現對每個MySQL節點配置Filebeat，並進行初始化、啟停等管控；
- 緩存：數據收集完成后，上報匯總到公司的Kafka集群；
- 過濾：配置Logstash過濾分析節點，因為MySQL慢日志格式還是比較復雜，這里面要做一些分析過濾、切割轉換等相關操作；
- 存儲：最終統一存入到Elasticsearch中；
- 展示：目前我們支持在58雲DB平台【內部的私有雲數據庫平台】上直接查看。我們也可以通過Kibana提供的統計工具進行趨勢分析、運維報警等；
目前給開發人員提供的用戶端，通過頁面可以實時看到自己的MySQL，從收集到MySQL到展示，目前可以做到5秒以內展示。
4、總結
上面介紹的是58同城內部兩個主要的應用實踐，目前數據庫團隊已經收斂了整個公司30+套各種業務的Elasticsearch集群、300多個節點，服務器接近200台，我們的管理維護還有不少的工作要做。
三、平台化建設
從去年開始，我們啟動了Elasticsearch平台化建設，一是面向用戶端提高開發接入Elasticsearch的效率，另外就是面向DBA管理端，可以對Elasticsearch集群進行高效運維及索引治理等。
58雲DB平台Elasticsearch功能架構圖如下：
1、用戶端
針對用戶端，我們把Elasticsearch開放給開發人員、數據運營、數據分析師等，使他們能夠對Elasticsearch的數據進行基本的查詢，包括數據統計、分析報表、 查看Elasticsearch的狀態等。
- 集群負責人可以從管理界面上看到自己名下的集群列表、Kibana地址、集群容量、操作申請等。
- 這個界面是索引申請界面。所有接入者通過標准化的方式、規范化的流程來完成需求提交。每一個索引的接入必須包括數據的保留策略、mapping、數據寫入方式等。
2、管理端
在管理端，我們實現了一鍵部署Elasticsearch集群。由於Elasticsearch是分布式的，部署的線路是比較長的，它需要多節點、不同的角色，包括監控、Logstash、Filebeat等相關的管理都是支持的。
- 從管理界面上可以看到哪個ip地址上運行着哪個集群、它的角色是什么。
- 一鍵自動化部署。
3、索引治理
索引治理后續會做一些索引的生命周期管理，現在的管理我們最多的還是依賴腳本，后面索引的工作，我們希望都放到平台上來，都要有相關的操作記錄。
- 索引的監控
對於服務端目前使用的是 Zabbix+ Grafana的方式。我們開發了一套程序。將所有集群的監控指標打入到其中一套Elasticsearch集群中去，然后Grafana基於Elasticsearch做了圖表的展示，再通過Zabbix進行一些系統的報警。
用戶端，可以通過Kibana可以看到索引index的速度、延遲等信息。
四、后續規划
1、版本升級
Elasticsearch 7.X，在Elasticsearch 7.X版本在性能優化上做了很多東西，包括：查詢的相關性、對內存的管控方面。但是它同樣存在一個問題，Elasticsearch版本不向下兼容，比如6.x版本升級到7.x版本，它的變化會比較大。
2、集群智能診斷
集群功能越來越多，目前集群出了問題還是依賴運維人員手動發現。我們希望通過規則或者自動分析等手段，實現故障的自動化處理。
3、私有雲探索
接到Elasticsearch業務需求，我們首先要分析它的業務模型：是搜索的還是日志流水的？不同的用途對硬件的消耗差別是很大的，而服務器並不是高度的契合業務配置。在這個方面是有非常多的資源浪費，我們希望通過雲模式，能夠減少資源浪費，提高資源的利用率。
五、問答環節
1. Elasticsearch數據如何與hadoop大數據平台數據倉庫同步？
答：Hadoop或hive數據可以通過官方的相關組件，也可以通過自己寫程序進行同步。
2. Elasticsearch日志應用中，怎么定義日志格式，有些后台日志情況復雜，比如except崩潰的，怎么處理這種后台日志問題？
答：關於日志格式可以看下Filebeat，Filebeat在收集日志的時候有多行合並功能，從Kafka到Logstash可以定義自己的過濾規則，這樣可以很容易的把問題解決掉。
3. MySQL數據如何導入到Elasticsearch，並保持實時同步？
這是一個比價大的主題，從MySQL到Elasticsearch這里考慮的規則還是比較多的。如：單表導入到單索引、多表導入到一個Elasticsearch索引、單表導入多個索引，這些都是不一樣的。業內做MySQL到Elasticsearch的同步的方案比較多，主流的有如下幾種：
簡單粗暴的由業務層雙寫，即寫完MySQL之后直接寫Elasticsearch，當然這樣雙寫可能無法保證數據的一致性，有些公司對異常有補償機制：如果寫入ES失敗，先把寫失敗的數據記錄下來，通過獨立后端程序進行異常的數據修復。
一些開源的工具。比如阿里開源的多數據源dataX，它的設計原理是直接到MySQL中查詢數據，它高度依賴一條記錄的過期時間，大於過期時間就將數據取出來寫到Elasticsearch中去，這個實時性依賴於程序多久刷新一次，但是如果數據刪除了，是無法感知到的。
直接解析MySQL的binlog。阿里也有這樣的開源工具canal。它的實現原理就是模擬一個MySQL的從庫，它訂閱所有主庫的變更，當MySQL數據變化時，它將解析的變更可以放到Kafka中去，Kafka下游可以消費后寫入Elasticsearch，也可以不經過Kafka直接解析出來寫入Elasticsearch。但canal也有個問題。它單節點處理能力受限。當MySQL主庫寫入稍微多一些的情況下，這時候canal解析速度跟不上，導致大量延遲，如果主庫的持續的寫入量大，canal會一直延遲，而且延遲越來越大，同時會出現很多問題。
4. Elasticsearch如何實現高效的二級索引？
答：類似於MySQL的回表查詢模式，先將所有待查詢的數據同步到Elasticsearch中，同步時帶上相關的記錄id，在Elasticsearch完成查詢后，再用這些id去相關的MySQL或HBASE進行查詢返回完整數據。