10TB級日志的秒級搜索 目錄運維之痛探索新大陸 -ElasticSearch動手干吧煩惱中成長小有成就展望未來干貨分享已有日志系統(tǒng)，可是。3不是任何字段都可以搜索，速度也比較慢搜索結果太多的時候，一眼看出問題還是困難統(tǒng)計數據都是預先聚合好的，無法按需實時計算，新加一個維度也要再開發(fā)服務對象主要是PD能再彈性一點就好了！接入日志周期太長，等不及底層基于Apache Lucene實時索引, 實時分析分布式，高可用沖突管理(通過Version Control)，避免數據丟失支持全文搜索面向文檔 , Schema FreeRestful API 開源，免費 (Apache 2 Open Source 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 state data數據會被索引，并保存在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是哪些出現(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實時用戶數量OpenStack Error Log 數量錯誤碼分布典型用例 - VDI錯誤詳情查詢18搜索某個錯誤碼快速定位問題：1.故障時間2.Thin Client (簡稱 TC)型號3.TC_IP （方便工程師 ssh 遠程排障）4.TC_MAC5.這個用戶屬于哪一個組, Tenant_id6.根據用戶ID，聯(lián)系用戶，詢問詳情7.這臺 TC 連接的是哪一臺虛擬機查看log詳情典型用例 - Cloud工程師的評價19由于 Thin Client 數量多、分布位置廣、用戶換班隨意性大、用戶有時不愿意主動報障 等問題，收集 Thin Client 的 Error Log 本來是件相當麻煩的事，而且會有滯后性，來不及發(fā)現(xiàn)問題、來不及跟用戶溝通 有了 ELK 后再多的 Thin Client 也不怕，TC 的各種 log 在 Kibana 上完美呈現(xiàn)。面對成千上萬個 Thin Client，我們依然可以第一時間 發(fā)現(xiàn) Error，方便獲取 所有排障所需的重要信息，從圖表上 掌握用戶日常工作的行為習慣，獲取實時用戶數，在系統(tǒng)發(fā)布、升級時，起到重要的保障作用。Lifes good20診斷問題方便多了，請你們吃飯!無線開發(fā)老大Cloud開發(fā)老大我們是ES的重度用戶了，以后多支持啊!有大家的肯定，可以放心去推廣了我老大。背后的艱辛21java.lang.OutOfMemoryError: Java heap space gcold528444307 duration 5.7s, collections 1/5.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.ConnectTransportException: logstash-inet9303 connect_timeout30s甚至日志堆積亦或22ES索引吞吐量低，趕不上日志流入速度日志格式突然變了，logstash傻了! 異常退出觸發(fā)Logstash的Bug安全問題怎么辦？23ELK我專注搜索，不關心訪問權限控制歷練24深入ELK工作機制理解各項配置參數的含義逐步添加監(jiān)控理解資源消耗特征調優(yōu)，二次開發(fā)通過監(jiān)控工具對比效果半年后 - 小有成就 (2014/07)25日處理日志量:- 40億條-1TB +峰值處理日志量: - 7萬條/s日志生成到可被檢索時延:-秒級日志搜索和統(tǒng)計速度:- 秒級接入日志類型:-IIS 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 DescriptorsIndicesIndices 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 Filter (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官網建議:1. 增大Max File Descriptors - 64k或更多 2. 鎖定用戶進程地址空間，防止內存swap額外的參數調整:對于消息隊列Server，我們用的網卡不支持多隊列，軟中斷會全部落在一個cpu核心，流量過大的時候會遇到瓶頸，通過綁定網卡終端親緣性來解決。調優(yōu) - JVM341. JDK1.7.0_xx (關注官網release note，避免使用有bug的jdk版本)2. 用G1替代CMS GC，提高了throughput注意: 官網最新出品的Definitive Guide里認為G1 GC目前bug較多，不建議使用！3. -Xms和-Xmx設置成和heap size一樣4. Heap分配30GB:Heap size應小于物理內存一半64GB內存的機器和64bit JVM，heap size小于32GB可以啟用Java Ordinary Object Pointers壓縮，更省內存調優(yōu) - Discovery35discovery.zen.ping.timeout: 30sdiscovery.zen.fd.ping_timeout: 120sdiscovery.zen.fd.ping_interval: 30sdiscovery.zen.fd.ping_retries: 61. 調整zen discovery參數，防止因為網絡或者GC原因造成結點被誤判為down2. 合理設置discovery.zen.minimum_master_nodes防止split brain關于ES split brain參考: http:/ refresh & flush36index.refresh_interval: 30sindex.translog.flush_threshold_ops: 50000數據實時性與cpu消耗之間求平衡默認5000，適當增大降低磁盤IO請求注：ES1.3以后版本已經改為由translog size觸發(fā)flush，默認觸發(fā)值為200MB調優(yōu) Recovery & Restart37gateway.type: localgateway.recover_after_nodes: 12gateway.recover_after_time: 5mgateway.expected_nodes: 17在盡量多的nodes可用的時候才啟動recovery過程，減少需要從gateway恢復的數據塊indices.recovery.max_bytes_per_sec: 50mbrecovery速率可以根據硬件和網絡條件調整#重啟前 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，重啟完畢再開啟調優(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 - 數值型字段默認type為long, double設置靜態(tài)mapping - 根據數值范圍，采用int, short, byte 類型Why Field Data40Inverted IndexField Dataefficient forefficient forField 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 cacheAbout 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充分利用多核CPU:1. 增大redis input thread2. 增大ElasticSearch output worker thread3. 增大flush size4. 增大filter worker ( 啟動腳本通過-w選項指定)代碼級優(yōu)化：某日志采用固定分隔符，采用ruby filter插件，通過split函數做日志切分，對比grok filter插件，CPU消耗降低近50%減少ES meta data同步的資源消耗ES output plugin采用transport protocol集群管理 工具44SaltStack具有puppet的分布式配置管理功能也具有mcollective的命令編排功能開發(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. 索引維護任務的配置集群管理 更簡單點，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數量過多（10k）會造成過高的更新成本讀寫無法完全分離，大查詢可能會引起Node GC，影響數據寫入的實時性展望未來 10 x流量增長52ES Cluster AES Cluster BES Cluster XES Tribe NodeAPI Interface多集群互聯(lián)展望未來 優(yōu)化資源利用53冷數據 | 低硬件配置node 定期自動遷移熱數據 | 高硬件配置node提高熱數據檢索速度避免大范圍冷數據可能導致的GC影響到寫入性能提升硬件資源利用率