《講座課件 10TB級日志的秒級搜索PPT》由會員分享，可在線閱讀，更多相關《講座課件 10TB級日志的秒級搜索PPT（53頁珍藏版）》請在裝配圖網(wǎng)上搜索。

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

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

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

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

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

6、log 在 Kibana 上完美呈現(xiàn)。面對成千上萬個 Thin Client，我們依然可以第一時間 發(fā)現(xiàn) Error，方便獲取 所有排障所需的重要信息，從圖表上 掌握用戶日常工作的行為習慣，獲取實時用戶數(shù)，在系統(tǒng)發(fā)布、升級時，起到重要的保障作用。Lifes good20診斷問題方便多了，請你們吃飯!無線開發(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甚至結點長時間無響應脫離集群連鎖反應集群徹底崩潰org.elasticsearch.transport.ConnectTr

8、ansportException: logstash-inet9303 connect_timeout30s甚至日志堆積亦或22ES索引吞吐量低，趕不上日志流入速度日志格式突然變了，logstash傻了! 異常退出觸發(fā)Logstash的Bug安全問題怎么辦？23ELK我專注搜索，不關心訪問權限控制歷練24深入ELK工作機制理解各項配置參數(shù)的含義逐步添加監(jiān)控理解資源消耗特征調優(yōu)，二次開發(fā)通過監(jiān)控工具對比效果半年后 - 小有成就 (2014/07)25日處理日志量:- 40億條-1TB +峰值處理日志量: - 7萬條/s日志生成到可被檢索時延:-秒級日志搜索和統(tǒng)計速度:- 秒級接入日志類型:-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服務質量26ES集群資源消耗27硬件配置:8Core * 64GB * 3TB x 12 Raid10改進后架構28干貨分享29調優(yōu)監(jiān)控權限控制二次開發(fā)集群管理監(jiān)控 工具30Ganglia + Nagios監(jiān)控 關鍵指標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吞吐量下降嚴重Heap用量突然升高Open Context一直增高頻繁的oldGC收到Redis隊列積壓報警翻查問題期間訪問日志，發(fā)現(xiàn)有大量不正確的scan & scroll調用問題診斷實例:監(jiān)視集群資源異?？焖俣ㄎ挥袉栴}的restful調用調優(yōu) OS33官網(wǎng)建議:1. 增大Max File Descriptors - 64k或更多 2. 鎖定用戶進程地址空間，防止內存swap額外的參數(shù)調整:對于消息隊列Server，我們用的網(wǎng)卡不支持多隊列，軟中斷會全

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

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

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

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

16、優(yōu) 索引日常維護38維護內容:1. 定期刪除不用的舊索引2. Disable冷索引的bloom filter3. Optimize冷索引 (實質是Force Merge)收益？1. 減少集群的meta data2. 釋放heap3. 減少Used File Descriptors調優(yōu) 減少Facet內存消耗39動態(tài)mapping - 數(shù)值型字段默認type為long, double設置靜態(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調優(yōu) Logstash Indexer43充分利用多核CP

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

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

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