《講座課件 10TB級(jí)日志的秒級(jí)搜索PPT》由會(huì)員分享，可在線閱讀，更多相關(guān)《講座課件 10TB級(jí)日志的秒級(jí)搜索PPT（53頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、10TB級(jí)日志的秒級(jí)搜索 目錄運(yùn)維之痛探索新大陸 -ElasticSearch動(dòng)手干吧煩惱中成長(zhǎng)小有成就展望未來干貨分享已有日志系統(tǒng)，可是。3不是任何字段都可以搜索，速度也比較慢搜索結(jié)果太多的時(shí)候，一眼看出問題還是困難統(tǒng)計(jì)數(shù)據(jù)都是預(yù)先聚合好的，無法按需實(shí)時(shí)計(jì)算，新加一個(gè)維度也要再開發(fā)服務(wù)對(duì)象主要是PD能再彈性一點(diǎn)就好了！接入日志周期太長(zhǎng)，等不及底層基于Apache Lucene實(shí)時(shí)索引, 實(shí)時(shí)分析分布式，高可用沖突管理(通過Version Control)，避免數(shù)據(jù)丟失支持全文搜索面向文檔 , Schema FreeRestful API 開源，免費(fèi) (Apache 2 Open Source

2、 License)4ElasticSearch特性典型的ELK日志解決方案5LogStash ShipperLogStash IndexerLogStash Shipper.LogStash Indexer.Kibana開始實(shí)踐67InputsFiltersOutputsEvent PipelineWritten in Jruby什么是Logstash?8豐富的Logstash插件ES Cluster示意圖9A Cluster with 1 index, 2 shards, 3 replicascluster由多個(gè)node組成會(huì)有一個(gè)node被選舉成master，負(fù)責(zé)維護(hù)cluster sta

3、te data數(shù)據(jù)會(huì)被索引，并保存在index里（類比RDBMS里的table)一個(gè)index可以切成多個(gè)shard，每個(gè)shard可以有多個(gè)replicashard均勻分布在所有可用的data node每個(gè)Shard實(shí)際上就是一個(gè)Lucene Index10類比RDBMS11CRUD12 Full Query DSL based on JSONQuery適用于全文搜索，或者搜索結(jié)果依賴于relevance score的場(chǎng)景Filter不進(jìn)行scoring，結(jié)果自動(dòng)cache，速度更快Query & Filterv用戶希望系統(tǒng)能回答類似以下問題：訪問量最高的 Uagent,Client IP是

4、哪些出現(xiàn)5xx , 4xx最高的URL是哪些服務(wù)器平均響應(yīng)時(shí)間的變化情況Etc.v對(duì)搜索結(jié)果集做匯總可以通過Facet來實(shí)現(xiàn)!注：ES 1.0版后開始用Aggregation取代Facet!13Facet14統(tǒng)計(jì)pprobel日志里count排名前7的Status_codeFacet實(shí)例15Facet實(shí)例典型用例 HTTP異常診斷16點(diǎn)擊500錯(cuò)誤的直方圖，過濾出所有500錯(cuò)誤的記錄來自某個(gè)IP的大量訪問造成收到監(jiān)控系統(tǒng)報(bào)警 500狀態(tài)值異常典型用例 - VDI 狀態(tài)監(jiān)控17實(shí)時(shí)用戶數(shù)量OpenStack Error Log 數(shù)量錯(cuò)誤碼分布典型用例 - VDI錯(cuò)誤詳情查詢18搜索某個(gè)錯(cuò)誤碼快速

5、定位問題：1.故障時(shí)間2.Thin Client (簡(jiǎn)稱 TC)型號(hào)3.TC_IP （方便工程師 ssh 遠(yuǎn)程排障）4.TC_MAC5.這個(gè)用戶屬于哪一個(gè)組, Tenant_id6.根據(jù)用戶ID，聯(lián)系用戶，詢問詳情7.這臺(tái) TC 連接的是哪一臺(tái)虛擬機(jī)查看log詳情典型用例 - Cloud工程師的評(píng)價(jià)19由于 Thin Client 數(shù)量多、分布位置廣、用戶換班隨意性大、用戶有時(shí)不愿意主動(dòng)報(bào)障 等問題，收集 Thin Client 的 Error Log 本來是件相當(dāng)麻煩的事，而且會(huì)有滯后性，來不及發(fā)現(xiàn)問題、來不及跟用戶溝通 有了 ELK 后再多的 Thin Client 也不怕，TC 的各種

6、log 在 Kibana 上完美呈現(xiàn)。面對(duì)成千上萬個(gè) Thin Client，我們依然可以第一時(shí)間 發(fā)現(xiàn) Error，方便獲取 所有排障所需的重要信息，從圖表上 掌握用戶日常工作的行為習(xí)慣，獲取實(shí)時(shí)用戶數(shù)，在系統(tǒng)發(fā)布、升級(jí)時(shí)，起到重要的保障作用。Lifes good20診斷問題方便多了，請(qǐng)你們吃飯!無線開發(fā)老大Cloud開發(fā)老大我們是ES的重度用戶了，以后多支持啊!有大家的肯定，可以放心去推廣了我老大。背后的艱辛21java.lang.OutOfMemoryError: Java heap space gcold528444307 duration 5.7s, collections 1/5.

7、9s, total 5.7s/34.1m, memory 28.5gb-28.6gb/30gbtoo many open files上壓力了，用戶多了，各種異常 failed to create695942 org.elasticsearch.cluster.metadata.ProcessClusterEventTimeoutException: failed to process cluster event (acquire index lock) within 30s甚至結(jié)點(diǎn)長(zhǎng)時(shí)間無響應(yīng)脫離集群連鎖反應(yīng)集群徹底崩潰org.elasticsearch.transport.ConnectTr

8、ansportException: logstash-inet9303 connect_timeout30s甚至日志堆積亦或22ES索引吞吐量低，趕不上日志流入速度日志格式突然變了，logstash傻了! 異常退出觸發(fā)Logstash的Bug安全問題怎么辦？23ELK我專注搜索，不關(guān)心訪問權(quán)限控制歷練24深入ELK工作機(jī)制理解各項(xiàng)配置參數(shù)的含義逐步添加監(jiān)控理解資源消耗特征調(diào)優(yōu)，二次開發(fā)通過監(jiān)控工具對(duì)比效果半年后 - 小有成就 (2014/07)25日處理日志量:- 40億條-1TB +峰值處理日志量: - 7萬條/s日志生成到可被檢索時(shí)延:-秒級(jí)日志搜索和統(tǒng)計(jì)速度:- 秒級(jí)接入日志類型:-II

9、S log-Mobile trace log-OpenStack log-VDI log-AX log-Tomcat log-Nginx log-Windows Event log-AD log-Mail log-Exchange log-CTI log-Etc. and more to come服務(wù)質(zhì)量26ES集群資源消耗27硬件配置:8Core * 64GB * 3TB x 12 Raid10改進(jìn)后架構(gòu)28干貨分享29調(diào)優(yōu)監(jiān)控權(quán)限控制二次開發(fā)集群管理監(jiān)控 工具30Ganglia + Nagios監(jiān)控 關(guān)鍵指標(biāo)31OSOS CPU, Memory, Disk Open File Descri

10、ptorsIndicesIndices Flush (rate, time) Refresh (rate, time) Index (rate,time) Query (rate, time) Fetch (rate, time) Merge rate Open contextJVMJVM Heap Used Old GC (rate , time) Young GC (rate, time)Thread PoolsThread Pools Bulk (Active/Queue) Refresh (Active/Queue) Search (Active/Queue)CacheCache Fi

11、lter (size, evictions) Field (size, evictions)監(jiān)控 restful API訪問記錄32Index吞吐量下降嚴(yán)重Heap用量突然升高Open Context一直增高頻繁的oldGC收到Redis隊(duì)列積壓報(bào)警翻查問題期間訪問日志，發(fā)現(xiàn)有大量不正確的scan & scroll調(diào)用問題診斷實(shí)例:監(jiān)視集群資源異?？焖俣ㄎ挥袉栴}的restful調(diào)用調(diào)優(yōu) OS33官網(wǎng)建議:1. 增大Max File Descriptors - 64k或更多 2. 鎖定用戶進(jìn)程地址空間，防止內(nèi)存swap額外的參數(shù)調(diào)整:對(duì)于消息隊(duì)列Server，我們用的網(wǎng)卡不支持多隊(duì)列，軟中斷會(huì)全

12、部落在一個(gè)cpu核心，流量過大的時(shí)候會(huì)遇到瓶頸，通過綁定網(wǎng)卡終端親緣性來解決。調(diào)優(yōu) - JVM341. JDK1.7.0_xx (關(guān)注官網(wǎng)release note，避免使用有bug的jdk版本)2. 用G1替代CMS GC，提高了throughput注意: 官網(wǎng)最新出品的Definitive Guide里認(rèn)為G1 GC目前bug較多，不建議使用！3. -Xms和-Xmx設(shè)置成和heap size一樣4. Heap分配30GB:Heap size應(yīng)小于物理內(nèi)存一半64GB內(nèi)存的機(jī)器和64bit JVM，heap size小于32GB可以啟用Java Ordinary Object Pointer

13、s壓縮，更省內(nèi)存調(diào)優(yōu) - Discovery35discovery.zen.ping.timeout: 30sdiscovery.zen.fd.ping_timeout: 120sdiscovery.zen.fd.ping_interval: 30sdiscovery.zen.fd.ping_retries: 61. 調(diào)整zen discovery參數(shù)，防止因?yàn)榫W(wǎng)絡(luò)或者GC原因造成結(jié)點(diǎn)被誤判為down2. 合理設(shè)置discovery.zen.minimum_master_nodes防止split brain關(guān)于ES split brain參考: http:/ refresh & flush36

14、index.refresh_interval: 30sindex.translog.flush_threshold_ops: 50000數(shù)據(jù)實(shí)時(shí)性與cpu消耗之間求平衡默認(rèn)5000，適當(dāng)增大降低磁盤IO請(qǐng)求注：ES1.3以后版本已經(jīng)改為由translog size觸發(fā)flush，默認(rèn)觸發(fā)值為200MB調(diào)優(yōu) Recovery & Restart37gateway.type: localgateway.recover_after_nodes: 12gateway.recover_after_time: 5mgateway.expected_nodes: 17在盡量多的nodes可用的時(shí)候才啟動(dòng)re

15、covery過程，減少需要從gateway恢復(fù)的數(shù)據(jù)塊indices.recovery.max_bytes_per_sec: 50mbrecovery速率可以根據(jù)硬件和網(wǎng)絡(luò)條件調(diào)整#重啟前 PUT /_cluster/settings -d transient:cluster.routing.allocation.enable: none#重啟后PUT localhost:9200/_cluster/settings -d transient:cluster.routing.allocation.enable: “all重啟node前，暫時(shí)關(guān)閉shard allocation，重啟完畢再開啟調(diào)

16、優(yōu) 索引日常維護(hù)38維護(hù)內(nèi)容:1. 定期刪除不用的舊索引2. Disable冷索引的bloom filter3. Optimize冷索引 (實(shí)質(zhì)是Force Merge)收益？1. 減少集群的meta data2. 釋放heap3. 減少Used File Descriptors調(diào)優(yōu) 減少Facet內(nèi)存消耗39動(dòng)態(tài)mapping - 數(shù)值型字段默認(rèn)type為long, double設(shè)置靜態(tài)mapping - 根據(jù)數(shù)值范圍，采用int, short, byte 類型Why Field Data40Inverted IndexField Dataefficient forefficient for

17、Field Data- In Memory vs On Disk41In Memory:Built at search time (could be very expensive) Loaded into field cache (bounded by cache size)Culprit for costly GC or OOM exceptionDefault setting-On Disk:Built at Index timeNot loaded into field cacheLess stress on heapBenefit from large OS page cacheAbo

18、ut 10- 25% slower than in-mem filed dataSpent more disk spaceWe are currently switching to On disk field data!On Disk Field Data42Enabled by setting doc_value to true Enabled per-field in the field mappingEffective for new index onlyCurrently not work with analyzed field調(diào)優(yōu) Logstash Indexer43充分利用多核CP

19、U:1. 增大redis input thread2. 增大ElasticSearch output worker thread3. 增大flush size4. 增大filter worker ( 啟動(dòng)腳本通過-w選項(xiàng)指定)代碼級(jí)優(yōu)化：某日志采用固定分隔符，采用ruby filter插件，通過split函數(shù)做日志切分，對(duì)比grok filter插件，CPU消耗降低近50%減少ES meta data同步的資源消耗ES output plugin采用transport protocol集群管理 工具44SaltStack具有puppet的分布式配置管理功能也具有mcollective的命令編排

20、功能開發(fā)語言是Python我們團(tuán)隊(duì)的主力開發(fā)語言集群管理 Logstash45Logstash:UpdateConf內(nèi)部GIT庫每個(gè)logstash實(shí)例的配置文件變動(dòng)提交獲取最新版本代碼及配置Logstash集群分發(fā)新版代碼及配置Logstash:ServiceCheckStartStopRestartDiff實(shí)例管理Powered by Salt集群管理 ES Cluster46實(shí)現(xiàn)方式與Logstash的管理類似，簡(jiǎn)化了如下工作:1. ES node的配置2. 版本升級(jí)3. Cluster full restart & node rolling restart4. 索引維護(hù)任務(wù)的配置集群管

21、理 更簡(jiǎn)單點(diǎn)，GUI47權(quán)限控制48Kibana二次開發(fā)，用戶需登錄Ctrip SSO方可訪問系統(tǒng)Nginx Reverse Proxy控制第三方對(duì)API的調(diào)用二次開發(fā) Kibana349https:/ Aggregation API50范例:IIS log中各個(gè)domain的響應(yīng)時(shí)間統(tǒng)計(jì)主要局限性51Cluster State Data無法scale out集群狀態(tài)變化時(shí)，信息實(shí)時(shí)更新至所有nodeIndex，shard數(shù)量過多（10k）會(huì)造成過高的更新成本讀寫無法完全分離，大查詢可能會(huì)引起Node GC，影響數(shù)據(jù)寫入的實(shí)時(shí)性展望未來 10 x流量增長(zhǎng)52ES Cluster AES Cluster BES Cluster XES Tribe NodeAPI Interface多集群互聯(lián)展望未來 優(yōu)化資源利用53冷數(shù)據(jù) | 低硬件配置node 定期自動(dòng)遷移熱數(shù)據(jù) | 高硬件配置node提高熱數(shù)據(jù)檢索速度避免大范圍冷數(shù)據(jù)可能導(dǎo)致的GC影響到寫入性能提升硬件資源利用率