某行日誌平臺 Elasticsearch 運維基礎篇
Elasticsearch在大資料和AI等相關應用場景的使用被更多人關注,但相關資料較少、排查問題困難,運維難點難以突破。本文作者將結合某行日誌平臺Elasticsearch叢集時的實戰經驗,對Elasticsearch運維相關知識進行總結分享,希望能夠為提行提供參考和幫助,歡迎大家持續關注。
【作者】擱淺沉默 某金融行業技術研發專員
一、引言
筆者從業多年,亦解決過許多Elasticsearch相關方面的問題,由於早期國內大多數Elasticsearch的使用場景為日誌模組,相對整體系統來講,屬於較為側面的模組,因此早期關注度並不高,筆者也經歷過早期Elasticsearch資料較少、排查問題困難的階段,著實讓人頭大,現將自身對Elasticsearch的瞭解情況,結合之前規劃搭建某行日誌平臺Elasticsearch叢集時的實戰經驗,將Elasticsearch運維相關的知識進行簡單的總結,此為基礎篇,先介紹一下Elasticsearch的核心概念,以及這些基礎點可能會產生的影響,以便對讀者有一定幫助。
二、Elasticsearch核心概念
2.1 節點(Node)
在Elasticsearch中,節點是一個獨立的伺服器例項或程式,它是叢集的一部分,用於儲存資料並參與叢集的索引和搜尋功能。每個節點都可以執行在叢集中的任何一臺機器上,並透過與其他節點通訊來協同工作,共同組成一個Elasticsearch叢集。每個節點都有自己的名稱、角色和職責,例如資料節點、主節點或協調節點。節點可以配置為按叢集名稱加入特定叢集,預設情況下,每個節點都設定為加入一個名為“elasticsearch”的叢集。
2.1.1 節點角色介紹
Master Node:主節點負責管理叢集的整體狀態和執行一些關鍵的叢集級別的操作。主節點負責分配分片到資料節點、維護叢集的狀態資訊、決定哪些節點是叢集的一部分等。主節點本身不負責儲存實際的資料,這有助於降低主節點的負載。
Data Node:資料節點負責儲存實際的資料。它們管理索引的分片,並處理與資料相關的操作,如搜尋、索引和刪除。資料節點儲存索引的一部分,並透過將資料分佈在多個節點上來實現水平擴充套件。
Coordinating Node:協調節點是可選的節點型別,主要用於處理搜尋請求的協調工作。它們不儲存實際的資料,但是負責接收來自客戶端的搜尋請求,並將這些請求轉發給資料節點。協調節點有助於分散搜尋請求的負載,特別是在大規模叢集中。
Ingest Node:預處理節點,Ingest節點負責資料的預處理,如資料的轉換和附加處理。這允許在將資料索引到Elasticsearch之前對資料進行修改或過濾。Ingest節點通常用於日誌處理和資料管道中。
Machine Learning Node:如果在叢集中啟用了Elasticsearch的機器學習功能,那麼可能存在專門的機器學習節點,用於執行與機器學習相關的任務,如異常檢測或趨勢分析。
Remote-eligible Node:遠端合格節點,擁有遠端叢集客戶端角色,可以充當遠端客戶端,預設情況下,叢集內任意節點都可以作為跨叢集的客戶端連線到遠端叢集。
Transform節點:用於執行資料轉換操作,例如從一個索引中提取資料並將其轉換為另一個索引,以便在資料倉儲和分析方面進行使用。
2.2 索引(Index)
在Elasticsearch中,索引是一個邏輯儲存,用來儲存管理相關資料,可以類比為關係型資料庫中的“表”的概念,資料以JSON格式儲存在索引的基本單元-文件(Document)。
2.3 副本(Replica)
在Elasticsearch中,"副本"(Replica)是指索引的一個複製。每個索引可以被配置為具有零個或多個副本。副本可以提高叢集的可用性和容錯性,以及提高搜尋效能。
每個索引被劃分為一個或多個主分片。主分片負責儲存索引的一部分資料,以及處理搜尋和寫入請求。為了提高可用性和容錯性,每個主分片可以有零個或多個副本。
每個索引的副本數量是可以配置的。在建立索引時,可以指定副本的數量。副本數量的選擇取決於對可用性和效能的需求。
2.4 分片(Shard)
在Elasticsearch中,一條索引的資料往往會被分為多個分片進行儲存,每個分片是一個獨立的儲存單元,底層為一個Lucene索引,可以在叢集中的不同節點上分佈,以提供高可用性和負載均衡。
2.4.1 分片的目的
設想,一條索引的資料量很大,達到了TB級別或者幾百GB,此時,就需要極大的儲存空間來儲存這一條索引,也不利於資料檢索,分片的主要目的就是允許索引水平分割和分佈儲存。每個分片都是一個獨立的、可被分配到不同節點上的工作單元,從而實現資料和負載的分佈。
2.4.2 分片數的設定
建立索引時,可以指定主分片的數量。這個數量在索引建立後不能被更改。合理設定主分片的數量對於叢集的效能和伸縮性至關重要。通常,每個主分片的大小應該適中,以便在叢集中的各個節點上均勻分佈負載,也有利於資料的快速查詢。
2.4.3 主分片
每個索引都可以被分為一個或多個主分片。主分片儲存索引的一部分資料,並負責處理搜尋和查詢操作,主分片的數量設定在索引建立時便被定義,無法進行動態修改,故而在進行主分片數量設定時,需按照實際應用場景謹慎評估。
2.5 對映(Mapping)
在Elasticsearch中,Mapping是用於定義索引中文件結構和欄位屬性的概念。可以理解為關係型資料庫中的Schema,可以近似的理解為“表結構”,Mapping描述了文件中的每個欄位的資料型別、分詞器(如果適用)、是否索引等資訊,索引中的每個文件都遵循其指定的Mapping規範。
此外,Mapping還有一個動態Mapping的概念,當索引中的文件被插入時,Elasticsearch可以根據文件的內容自動建立Mapping,這稱為動態Mapping。動態Mapping允許Elasticsearch自動適應新欄位和文件結構。
三、Elasticsearch注意事項
1. 副本的注意事項
由於寫入請求首先傳送到主分片,一旦主分片成功處理寫入請求,資料會被複制到所有副本。因此,在寫入請求的過程中,副本數量可以對效能產生一些影響。增加副本數量會導致寫入請求需要複製更多的資料,會增加寫入的總時間。在高寫入的場景下,副本數量的增加會影響寫入效能。
每個副本都佔用獨立的儲存空間,因此增加副本數量會增加整體的儲存需求。
在叢集中的節點之間複製副本可能會產生額外的網路開銷,特別是在分散式環境中,節點之間的網路頻寬可能成為效能瓶頸。
當執行搜尋請求時,查詢可以分發到主分片和其副本上,允許並行處理。在高併發的搜尋環境中,副本的存在可以提高搜尋效能,但同時也需要更多的系統資源。
調整副本數量可能會觸發叢集的Rebalance分片的操作,這可能導致效能開銷,需要謹慎地調整這些配置。
2. 分片設定的注意事項
分片的數量設定得過多時,過多的分片可能有如下影響:
CPU,記憶體資源消耗過多。
分片間的通訊開銷會隨著分片數量的增加而增加,可能導致網路頻寬成為瓶頸,進而影響整體效能。
當執行查詢時,Elasticsearch需要在所有分片上執行查詢,並將結果合併,分片數量過多時,會導致查詢效能降低。
分片其實數語碎片化的儲存,過多的碎片化儲存會導致IO效能下降。
節點掛掉時,Elasticsearch 需要Rebalance分片以確保每個節點上的負載均衡,故而分片過多時,叢集進行Rebalance時開銷會很大。
分片的數量設定得過少時,可能會存在如下影響:
叢集中同時處理查詢和索引操作的並行性受到限制。
可能導致某些節點的資源未能充分利用,降低了整個叢集的吞吐量和效能。
可能限制了叢集的伸縮性,使得在應對不斷增長的資料量和負載時難以實現水平擴充套件。
可能導致查詢在單個分片上執行,限制了查詢操作的並行性。這可能影響查詢效能,尤其是在大規模資料集上執行復雜查詢時。
如果設定了副本,過少的分片可能導致某些節點上的副本數量有限,從而增加了資料的單點故障風險。在某個節點掛掉時,副本數量不足可能影響叢集的可用性。
根據筆者工作中實踐的經驗,單個資料節點上的分片數量在1000左右為佳,3000左右為極限,超過3000後,單個資料節點的CPU以及記憶體使用量會維持在70%-90%之間,甚至有達到100%的情況,極度容易觸發記憶體CPU告警以及Elasticsearch叢集資料節點的Out Of Memory異常。
3. 對映的注意事項
當使用動態 Mapping 時,Elasticsearch 需要解析新插入文件的結構,並自動建立或更新 Mapping。如果資料集中有大量不同的欄位,動態Mapping的開銷可能增大,可能影響索引速度和系統資源的利用效率。
對於文字欄位,分詞器的選擇對索引和搜尋效能有影響。複雜的分析器可能會導致索引速度減緩,但可以提供更靈活和準確的搜尋,需要根據實際場景權衡索引速度和搜尋質量之間的需求來選擇適合的分詞器。
索引中欄位的數量和型別會直接影響效能,過多的欄位可能導致索引和搜尋的複雜性增加,而欄位型別的選擇也會影響儲存和檢索的效率,合理設計Mapping結構可以降低這些影響,這點在實際使用場景中非常重要,可以理解為關係型資料庫中的“資料表結構的設計部分”。
當Mapping 發生變更時,Elasticsearch可能需要重新建立索引(Reindex)已有的資料,進而導致一定的效能開銷,特別是在處理大量資料時。更改Mapping時需要謹慎,可能需要考慮升級策略,以減輕對叢集的影響。
複雜的Mapping結構和冗餘的欄位可能會增加儲存和檢索的複雜性,影響效能,在設計Mapping時,需考慮到資料的冗餘性和複雜性可能會帶來的效能影響。
四、結語
本次針對Elasticsearch基本概念進行了相關介紹以及構建叢集時,需注意的基本事項。《老子》有云:“合抱之木,生於毫末;九層之臺,起於累土”,筆者經過多年的實踐發現,往往最基礎的東西,可以很有效的幫助筆者發現問題,解決問題,故而此篇文章從最基礎的概念進行介紹,進而延伸到這些基礎知識點可能影響到的場景,一家之言,僅供參考。
來自 “ twt社群 ”, 原文作者:twt企業IT社群;原文連結:https://mp.weixin.qq.com/s/A-vGqejsvhHjQPMsh_eIlw,如有侵權,請聯絡管理員刪除。
相關文章
- ElasticSearch實戰-日誌監控平臺Elasticsearch
- Elasticsearch+kibana+logstash 搭建日誌收集分析平臺Elasticsearch
- 日誌分析平臺ELK之搜尋引擎Elasticsearch叢集Elasticsearch
- ELK(ElasticSearch, Logstash, Kibana)搭建實時日誌分析平臺Elasticsearch
- Elasticsearch、Logstash、Kibana搭建統一日誌分析平臺Elasticsearch
- linux運維基礎2Linux運維
- 運維平臺之應用日誌解決方案--ELK運維應用日誌
- Devops 開發運維基礎篇之Jenkins部署與使用dev運維Jenkins
- 2023最新ELK日誌平臺(elasticsearch+logstash+kibana)搭建Elasticsearch
- Lumen日誌接入 ElasticsearchElasticsearch
- 搭建ELK日誌平臺(單機)
- 開放平臺日誌推送---kafkaKafka
- 智慧運維基礎-運維知識庫之ETL運維
- Centos7下使用ELK(Elasticsearch + Logstash + Kibana)搭建日誌集中分析平臺CentOSElasticsearch
- elasticsearch日誌刪除命令Elasticsearch
- Elasticsearch 的事務日誌Elasticsearch
- 日誌分析平臺ELK之日誌收集器filebeat
- [日誌分析篇]-利用ELK分析jumpserver日誌-日誌拆分篇Server
- BookStack:一個開源的維基平臺
- 手把手教你搭建一套ELK日誌搜尋運維平臺運維
- Redis基礎篇(三)持久化:AOF日誌Redis持久化
- 日誌分析平臺ELK之日誌收集器logstash
- ELK+FileBeat+Kafka搭建日誌管理平臺Kafka
- 01-linu核心基礎-02運維基礎重要概念運維
- 日誌開篇
- 餓了麼運維基礎設施進化史運維
- 使用ELK構建微服務的日誌平臺微服務
- 使用Fluentd + Elasticsearch收集訪問日誌Elasticsearch
- 【ElasticSearch】給ElasticSearch資料庫配置慢查詢日誌Elasticsearch資料庫
- 日誌篇:模組日誌總體介紹
- 寫給自己看的Linux運維基礎(三) - MonoLinux運維Mono
- 寫給自己看的Linux運維基礎(一) - 系統基礎Linux運維
- [平臺建設] 大資料平臺如何實現任務日誌採集大資料
- ELK構建MySQL慢日誌收集平臺詳解MySql
- 學習Linux運維技術的都有哪些人?運維基礎Linux運維
- Laravel 使用 Elasticsearch 作為日誌儲存LaravelElasticsearch
- ELK 日誌分析系統 ----------- 部署ElasticSearch群集Elasticsearch
- AIX基礎日誌AI