有哪些基於ELK的億級實時日誌分析平台實踐的案例？

01-28

謝謝zhouzhou的邀請，近期貓友會旗下的大數據付費群正好進行了相關內容的分享，下面是嘉賓回答的內容，希望對你能有所幫助。

大家好，我是黃歆，目前擔任鬥魚數據平台部基礎架構組Leader，主要負責鬥魚數據平台部基礎環境建設（Hadoop、ELK、容器集群等）及基礎服務開發（發布系統、監控告警、任務調度等）。首先自我介紹一下，我2010年畢業後進入傳統行業從事JavaWeb方向近4年時間，隨後轉入互聯網行業進入一號店。2015年3月份加入鬥魚，開始從事基礎環境、基礎服務相關工作。

今天跟大家分享的主題是《基於ELK的億級實時日誌分析平台實踐》，主要跟大家分享一些鬥魚在ELK上的實踐、架構演變以及一些采坑、調優的經歷。此次分享我分成3個部分，分別是：

1. ELK是什麼，為什麼要使用ELK；

2. 鬥魚ELK日誌分析平台實踐；

3. 高並發環境下的ELK相關優化；

在講解ELK之前我先來闡述一下日誌在互聯網應用中的重要性。在互聯網行業里日誌數據非常重要，形式也多種多樣。通過日誌我們可以計算請求量、流量來源分析、了解用戶行為、鑒別作弊用戶（如：是否是機器人）等等。

在計算PV、UV的場景下，根據業務需求我們通常以離線方式（MR / HIVE）隔天進行報表相關數據生產。但是對於故障排查肯定是希望能夠快速的進行日誌查詢、定位、解決問題，對於實時性要求非常高。

舉個例子，對於一個大流量的Web應用通常以Stateless方式設計，這樣可以更方便的進行水平擴容。但是隨著應用實例數量越來越多，我們查詢日誌就越來越困難。在沒有日誌系統的情況下，首先我們需要定位到請求的伺服器地址，如果每台伺服器都部署了多個應用實例，我們則需要去每個應用實例的日誌目錄下去找日誌文件。每個服務可能還會設置日誌滾動策略（如：每200M一個文件），還有日誌壓縮歸檔策略。

我們查詢一條出錯信息就要在茫茫多的日誌文件里去找到它，於是使出我們的十八般武藝head less tail grep wc awk count cut，但是如果需要統計最近3天的某個介面的異常次數。。。。

除了上面出現的狀況我們還需要考慮：日誌量太大如何歸檔、文本搜索太慢怎麼辦、如何多維度查詢，ELK就是幫我們來解決這些問題的。

1. ELK是什麼，為什麼要使用ELK

ELK 是elastic公司提供的一套完整的日誌收集、展示解決方案，是三個產品的首字母縮寫，分別是ElasticSearch、Logstash 和 Kibana。

ElasticSearch簡稱ES，它是一個實時的分散式搜索和分析引擎，它可以用於全文搜索，結構化搜索以及分析。它是一個建立在全文搜索引擎 Apache Lucene 基礎上的搜索引擎，使用 Java 語言編寫。

Logstash是一個具有實時傳輸能力的數據收集引擎，用來進行數據收集（如：讀取文本文件）、解析，並將數據發送給ES。

Kibana為 Elasticsearch 提供了分析和可視化的 Web 平台。它可以在 Elasticsearch 的索引中查找，交互數據，並生成各種維度表格、圖形。

2. 鬥魚ELK日誌分析平台實踐；

最初我們引入ELK的原因是實現一個小需求，實時統計伺服器500錯誤數量，在使用過程中發現ELK的功能確實非常強大，隨後接入其它業務部門應用日誌，解決日誌查詢慢的痛點，加速錯誤定位。於2016年底接入全站所有伺服器日誌，並完成了ES 5.0的升級。

隨著對ELK技術棧的不斷深入，我們將監控報警系統的數據存儲層由HBase替換成ES。監控報警系統的數據存儲層主要數據類型是時間序列數據，如某一時刻的應用CPU使用率。通常在做數據展示時我們會將數據先以某一時間粒度（如：5分鐘）進行後端聚合匯總再交給前端進行渲染，並且這個時間粒度會隨著用戶選擇的時間區間而變化，針對此類需求我們依靠ES提供的強大數據聚合特性極大減少了開發成本。

最初我們並沒有使用ELK全套技術棧，我們使用了Flume（一個Java編寫的日誌採集、聚合和傳輸系統類似上述的Logstash）作為日誌收集Agent。Flume使用 tail -f 的方式實時收集日誌文件中追加的文本內容。通過Flume配置文件中定義的正則表達式對日誌文本進行欄位分割，隨後寫入ElasticSearch，整體架構如下圖：

在使用過程中發現Flume偶爾會OOM，原因是使用了Flume的Memory Channel。使用此方式時，Flume會將 tail -f 讀取到的數據寫入內存，隨後輸出到ES。但是一旦數據輸出速度小於數據讀取速度時內存中積壓的數據就會越來越多，從而產生OOM。

於是我們將Flume中的Memory Channel替換成File Channel，該方式在數據讀取之後，將數據寫入Flume中的本地文件存儲再讀取（個人覺得不是很優雅）。

使用過程中還發現在日誌收集過程中Flume搶佔了大量CPU資源用於日誌解析（通過正則），導致伺服器中其他應用資源不足。於是我們搭建了一個Flume日誌聚合層，將日誌解析工作放在聚合層中完成，Agent只做數據收集、推送。隨後架構變成下面這個樣子。

聚合層中的Flume實例為無狀態節點，如果性能不足可以增加聚合層中的Flume實例數量，但是要在Agent端配置文件中添加新Flume聚合層實例的IP埠信息，並重新啟動。

穩定一段時間後，問題又來了。tail -f 方式收集日誌在Flume Agent重啟時會丟失重啟時間段的數據。嘗試使用Flume提供的 Spooling Directory Source 也並不能完美的解決問題（需要修改所有日誌文件存儲方式，每分鐘去切割文件，如果跟其他業務團隊這樣說，估計會被打死）。並且我們當時正在準備進行ES的1.x to 2.x版本的升級，但是Flume並不支持數據寫入ES 2.x版本，於是我們果斷放棄了Flume投入Logstash的懷抱。

Logstash相對於Flume提供了更加豐富的日誌處理器，並且支持最新ES版本（畢竟是親兒子）。Logstash在進行文本數據收集時並沒有使用 tail -f 這種簡單粗暴的方式，而是在本地文件中記錄了日誌文件被讀取到的位置，完美解決了上面說的升級重啟時丟失數據的問題。

將Flume聚合層替成了Kafka消息隊列，我們的監控系統通過Kafka提供的API實時獲取Kafka中的隊列Metrics，並設置閾值進行報警，這種集中式的隊列監控也是Flume聚合層無法做到的。

在這種標準的ELK架構下，日誌收集已經非常穩定，但是還有2點不足：

1. Logstash體積太大，依賴Java環境，其他部門的運維同學每次都要先部署一套JDK，不開心；

2. Logstash日誌解析資源佔用偏高；

為了減少Agent體積，方便運維同學部署，我們將Logstash替換成了FileBeat（也是elastic公司的產品）、Rsyslog（用來收集系統日誌），而且這2個組件無需依賴Java環境就能運行，安裝包10M不到。並且Agent內存佔用也得到了極大改善。

針對第二個日誌解析資源佔用偏高的問題。Logstash的核心代碼是用ruby語言開發，雖然是運行在jruby上，但是由於中間涉及到數據結構的轉化，性能是跟用原生的java語言運行在jvm上肯定是有所差距的，於是我們在部分場景使用Hangout替換了Logstash。

最後針對日誌存不規範的情況，一個日誌文件中日誌有多種結構，可能正則表達式（或者GROK）不是很好寫，即便是寫出來之後性能也達不到要求。針對這種日誌不規範的這種情況我們自己寫了一些基於規則判斷的解析器代替正則表達式去完成解析工作，性能獲得極大提升，日誌解析時的CPU佔用率降低了一個數量級。

說到這裡，一個能應對高並發的ELK架構終於成型了，上圖。

從上圖中可以看到，這裡部署了多套ES集群（A、B、C）。這樣做是為了避免所有業務放在一個大集群中相互影響。如此一來每個業務（或者某些業務）都有獨立的集群，更加方便運維。

Kibana與多個ES集群之間通過Tribe Node進行交互，Tribe Node作為集群聯邦節點負責將請求路由到正確的後端ES集群上，做到後端ES集群拓撲變化時對使用方透明。

目前整個鬥魚負責日誌這一塊的ELK集群總共包含50+物理伺服器、700T數據、日增數據量為15T。

3. 高並發環境下的ELK相關優化；

首先來介紹索引的。在最初我們以天為單位，使用ES中的Index templates方式自動創建索引。但是一旦ES節點出現故障，由於分片中的數據量非常大，分片恢復速度十分緩慢，於是我們將索引改為按小時劃分。按小時劃分後每個索引中的數據自然少了許多，當ES故障時可以更快的恢復當前索引，不阻塞後續的數據寫入。

針對索引的優化我們關閉了_all及其他不必要的field以降低索引大小切關閉欄位分詞。這樣設置以後查詢只能通過某個具體的Key去查詢（類似level:ERROR），在日誌場景下完全夠用。可以將日誌列印成JSON格式，減少日誌解析工作量。通過索引模板設置按照某一規則解析Field的類型，如：將xxxCount、xxxSize的Field自動解析成數字類型，其它欄位解析成text等等。

關於索引分片，在伺服器壓力不大的前提下，索引的分片數量盡量少，只要能滿足業務正常執行，越多的分片在查詢時需要合併的次數也就越多。通常每個分片只設置1個副本，副本分片在ES中默認配置下是以同步方式寫入的，每次寫入數據時當所有副本寫入完成以後才返回結果，也就是說副本越多寫入壓力越大且耗時越長，所以設置1個副本保證最基本的容災即可。

如果使用副本非同步同步，ES主分片寫入完成後不會等待副本分片寫入完畢，直接返回結果給客戶端。在高並發環境下日誌生產的速度很快，在日誌解析器速度夠快的情況下會直接對ES發起第二批寫入請求，這樣循環下來會導致ES副本在高峰期永遠同步不完，失去容災的意義，所以不推薦使用。

當索引穩定無數據寫入時，對索引進行ForceMerge。ForceMerge操作會合併分片中的segment，簡單點解釋就是可以把多個小文件中的數據合併到一個大文件中再進行索引排序，可明顯提升查詢性能。ForceMerge對伺服器資源消耗比較高，並且執行時間很長（基於索引的大小），建議在集群壓力最小的時候（比如凌晨，通過定時任務）執行。

下面再來談一下ES節點的部署方式。最重要的一點就是節點角色獨立，在一個小型ES集群里每個節點通常既作為Master又負責數據處理，但是在一個大型集群中節點角色混合會發生不穩定的情況。比如當數據壓力過大時導致頻繁GC、甚至節點掉線。無論GC導致的停頓還是節點掉線均會影響該節點上Master角色所提供的服務，如果該Master是當前活動的主節點的話，掉線就又會產生重新選主的行為，代價還是蠻大的。

我們伺服器的配置為2CPU32核 / 128G RAM / 16 * 6T SATA。每個集群上Master部署奇數個（3~7個），同時設置discovery.zen.minimum_master_nodes=master總數/2+1 避免集群腦裂，內存不宜過多，控制GC導致的停頓時間。

每個Data節點分配30G內存，最多不超過31.xxG內存，不同JDK版本的這個邊界值不一樣，少於該邊界值時JVM會採用內存對象指針壓縮技術提高內存利用率（至於如何確定這個邊界值，我會在最後給出鏈接）。那麼對於128GB內存的伺服器我們該如何分配內存呢？我們將每台伺服器部署了2個Data節點實例，加起來佔用大約一半內存，剩餘的內存留給操作系統緩存，在搜索時Lucence會查找Segment文件，這時如果命中操作系統緩存會大幅度提升搜索速度。

在伺服器啟動多個Data節點實例的情況下要注意一個問題，一旦伺服器宕機有可能導致主從分片均不可用（主從分片被分配在同一台伺服器的不同實例上了）。針對這種情況需要開啟 cluster.routing.allocation.same_shard.host 選項，禁止主從分片被分到同一台伺服器上，保證伺服器宕機時有副本分片可用。

還有，注意給每個ES節點分配不同的磁碟，避免節點之間的IO競爭。

關於ES相關的優化其實還有很多，網上一搜一大把這裡就不一一列舉。調優的過程中最基礎的還是對物理伺服器以及集群做持續監控，通過ES提供的CAT API我們可以很方便的獲取集群中的各項指標，如查詢負載、查詢延遲、索引隊列長度、請求拒絕次數等等，我們可以將這些指標數據通過腳本定時讀取然後回寫到ES中，在KIBANA上建立這些數據的可視化圖形，這樣一個簡單的監控系統就出來了。

伺服器級別的監控能最快落地的方式就是搭一個Zabbix，主要了解CPU、內存、IO等硬體資源使用情況，方便定位問題，找出性能瓶頸。

在來說一下ES的安全問題。在2017年年初的時候暴露在互聯網上的ElasticSearch集群在全球範圍遭到大量劫持，黑客在ES中留下了一條與贖金要求相關的索引定義，具體如下所示：

文本內容寫道，如果希望恢複數據需要向黑客的賬戶中支付比特幣，如何避免這種悲劇發生呢？

1、最關鍵的一點就是不要將ES暴露在互聯網中，這一點應該是針對所有伺服器應用。除非直接與用戶交互，所有應用都不應該暴露在互聯網中，Web應用應該通過Nginx反向代理並且僅暴露需要交互介面，防止黑客調用那些私有介面以及使用Web容器漏洞。

如果伺服器配置了外網IP，可以在外網交換機上封鎖不需要的埠。如果不方便這麼做，則開啟伺服器上的iptables（記得高並發情況下增大iptables跟蹤表大小，這裡就不展開了），只允許部分埠的入站請求。還可以將所有服務設置成只監聽本地區域網請求（ES中可以設置network.bind_host=192.168.x.x）。

2. 關閉不必要的ES HTTP埠。用戶能連接到ES的HTTP埠，就可以通過REST API去對集群進行操作。僅開啟Client節點上的HTTP埠，並通過反向代理方式暴露給用戶，配置反向代理屏蔽那些有風險的API介面並開啟訪問日誌，做到操作能夠被審計。

3. 及時更新ElasticSearch版本，ElasticSearch完全遵循語義化版本號（x.y.z），小版本的升級基本不會出現兼容性問題。

主版本號（x）：當你做了不兼容的 API 修改；

次版本號（y）：當你做了向下兼容的功能性新增；

修正版本號（z）：當你做了向下兼容的問題修正；

4. 修改默認的ElasticSearch集群名稱，避免出現集群中出現陌生節點；

5. 禁用通配符刪除索引（小手一抖，數據帶走）；

6. 使用非Root用戶啟動ES；

問答：

1、鬥魚有用到RabbitMQ或者Kafka之類的消息隊列嗎？消息隊列適合哪種使用場景，有哪些注意點？Redis如何和消息隊列結合使用，Redis使用有哪些注意事項？

答：消息隊列的場景還是在於數據驅動的場景，如果上游服務不關注下游的執行結果，很適合使用消息隊列。Redis也有消息隊列的功能，但是好像並不支持多消費者。只是一個FIFO的隊列

2、目前鬥魚這邊接入elk平台的業務有哪些共同特性？碰到es 慢寫入和慢查詢的時候，排查的步驟有哪些？關於es使用object與嵌套結構的分別是什麼場景？

答：碰到ES寫入慢和查詢慢的時候，先是查看監控、硬體資源以及ES中各種線程池的狀況。

3、kafka消息隊列支持更新隊列裡面的消息嗎？支持優先順序嗎？

答：不支持

4、在Flume無法支撐當前業務系統時如何進行技術替換以及可行性分析，

答：如果只是Flume寫Kafka這一個流程，換Logstash就行了。關於技術選型，可以看一下谷歌指數、GITHUB星星數量對比一下同類框架，社區活躍才是真的好

5、kafka消息持久化支持嗎？就是kafka服務掛了之後，消息是否會丟失

答：消息不會丟失的，但是Kafka刪除數據是基於時間，比如一周，這個不會一直存儲。Kafka還是針對於大數據場景，會發生數據丟失的情況，測試過。如果是敏感數據還是使用RabbitMQ

6、請問有沒有好的社區推薦？

答：推薦ES的官方文檔還是很全的，最好的社區就是GITHUB以及ES官方論壇然後國內也有個問答網站的 https://elasticsearch.cn/，還有關注ES公眾號

7、kafka的消息也是存在內存中的嗎？

答：是直接落盤， Kafka有個ACK機制，如果是不需要ACK是會丟的，看自己的設置

8、一般程序都是用log4j和log back的，為啥不自定義appender 通過zookeeper +kafka 消費kafka 數據直接建立索引到es 這樣不是快？

答：1. 做基礎組件一定要使用最小依賴，給應用依賴留有空間，讓應用方不要有顧慮。

2. Agent收集方便停機維護，即使Kafka掛了也不會丟消息。

3. 不能保證Kafka的日誌Appender日誌不會產生其他阻塞情況

9、收集到的數據進入了HSDF了嗎？

答：目前沒有持久化需求，如果想永久保留日誌，可以新建個Kafka消費者寫HDFS

10、鬥魚有用日誌做調用鏈嗎？

答：有日誌調用鏈，正在做可視化的東西，調用鏈可以參考PinPoint，用JavaAgent做logger的位元組碼織入，只不過PinPoint運行時依賴有點重。調用鏈主要還是記錄調用的setp以及他的深度，可以想像成一個樹形結構。可以定義一個ThreadLocal變數存放這些信息

11、日誌告警的定製化需求，比如多少分鐘內出現多少次錯誤就報警

答：我們開發了自己的告警平台，可以做到「包括日誌告警的定製化需求，比如多少分鐘內出現多少次錯誤就報警」這種定定製話的需求，如果想在公司里開發一套，可以先玩玩Zabbix，學習一些它的理念，很有幫助

12、用了jstom這種流式處理吧？

答：用了，還有spark streaming

http://weixin.qq.com/r/Vu1SSgHEAlx9rUUp97hE (二維碼自動識別)

1、背景

日誌對於一個系統來說十分重要，系統管理員可以從日誌中獲悉系統的運行狀況，是否發生異常等。實際上，一般應用都會以某種格式產生日誌，且日誌一般是輸出到本地的文件中。一旦系統中的節點增加到多個節點，管理和訪問這些日誌會變得複雜。如果沒有合適的工具，要從上百個節點上的上百個日誌文件中搜索出錯誤日誌會變得很困難。常見解決思路是建立集中式日誌收集系統(Centralized Logging)，將所有節點上的日誌統一收集，管理，訪問。

一般大型系統是一個分散式部署的架構，不同的服務模塊部署在不同的伺服器上，客戶反饋問題時，大部分情況需要根據客戶提供的主被叫號碼信息，定位到具體的伺服器和服務模塊，構建一套集中式日誌系統，可以提高定位問題的效率。

2、方案選型

一個完整的集中式日誌系統，包含以下幾個主要特點的。

● 收集－能夠採集多種來源的日誌數據

● 傳輸－能夠穩定的把日誌數據傳輸到中央系統

● 存儲－如何存儲日誌數據

● 分析－可以支持 UI 分析

● 警告－能夠提供錯誤報告，監控機制

基於上述思路，於是許多產品或方案就應運而生了。比如，簡單的 Rsyslog，Syslog-ng；商業化的 Splunk ；開源的有 FaceBook 公司的 Scribe，Apache 的 Chukwa、Flume，Linkedin 的 Kafak，Cloudera 的 Fluentd，ELK 等等。

● Scribe – Scribe是由Facebook開源的，主打可擴展性和可靠性的日誌聚合服務，由C++編寫，使用Thrift通信協議，但是實際上可以支持任何語言。

● Flume – Flume是apache的項目，旨在收集，聚合，移動大量的日誌數據，最終將數據存放到HDFS上。

● Chukwa – Chukwa是另外一個apache項目用來將日誌放到HDFS中。

● fluentd – 和logstash類似，也支持各種輸入和輸出，雖然不支持任何存儲層，但是可配置。另外，它的設計原則是方便安裝和低開銷。

● kafka – 由LinkIn開發的用來處理他們的活動流（activity stre am），現在是apache的孵化項目。雖然kafka可用作為日誌收集器，不過不是他的主要使用場景。需要配置Zookeeper來管理集群。

相對於其他單一產品或系統，ELK提供了一整套解決方案，它是三個軟體產品的首字母縮寫，Elasticsearch，Logstash 和 Kibana。這三款軟體都是開源軟體，通常是配合使用，而且又先後歸於 http://Elastic.co 公司名下，故被簡稱為 ELK 協議棧。

? Elasticsearch

Elasticsearch 是一個實時的分散式搜索和分析引擎，它可以用於全文搜索，結構化搜索以及分析。它是一個建立在全文搜索引擎 Apache Lucene 基礎上的搜索引擎，使用 Java 語言編寫。主要特點如下：

? 實時分析

? 分散式實時文件存儲，並將每一個欄位都編入索引

? 文檔導向，所有的對象全部是文檔

? 高可用性，易擴展，支持集群（Cluster）、分片和複製（Shards 和 Replicas）

? 介面友好，支持 JSON

? Logstash

Logstash 是一個具有實時渠道能力的數據收集引擎。使用 JRuby 語言編寫。其作者是世界著名的運維工程師喬丹西塞 (JordanSissel)。主要特點如下：

? 幾乎可以訪問任何數據

? 可以和多種外部應用結合

? 支持彈性擴展

它由三個主要部分組成：

● Shipper－發送日誌數據

● Broker－收集數據，預設內置 Redis

● Indexer－數據寫入

? Kibana

Kibana 是一款基於 Apache 開源協議，使用 JavaScript 語言編寫，為 Elasticsearch 提供分析和可視化的 Web 平台。它可以在 Elasticsearch 的索引中查找，交互數據，並生成各種維度的表圖。

ELK 三款軟體之間互相配合使用，完美銜接，高效的滿足了很多場合的應用，並且被很多用戶所採納，諸如路透社，臉書（Facebook），StackOverFlow 等等。

基於以上分析，選擇ELK方案作為大型系統的日誌方案。

3、系統架構

一般情況下平台各服務模塊的日誌都存儲在本地文件中， http://Elastic.co公司提供了Filebeat模塊，將Filebeat部署到相應的伺服器上，然後讀取日誌文件傳給Logstash或者Elasticsearch。系統架構如下圖所示：

還有一種方案，就是直接讓服務模塊按照標準的協議通過網路將日誌發送給Logstash，這樣可以減少服務模塊所在主機的磁碟IO，提高性能。另外，不需要在服務主機上安裝filebeat模塊，但需要修改應用程序的日誌處理方式。

4、安裝部署

4.1.ElastixSearch安裝

4.1.1 JAVA-1.8安裝

[yun@elk-1 ~]$ ccpdo yum install java-1.8.0-openjdk-devel.x86_64

[yun@elk-1 ~]$ ccpdo vim /etc/profile.d/jdk.sh

export JAVA_HOME=/usr/lib/jvm/java

export CLASSPATH=.:$JAVA_HOME/lib:$CLASSPATH

export PATH=$JAVA_HOME/bin:$PATH

[yun@elk-1 ~]$ source /etc/profile

4.1.2 ES安裝

wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/2.3.1/elasticsearch-2.3.1.zip

vim elasticsearch.yml ：

network.host: 0.0.0.0

環境變數設置

es內存棧大小不超過50%系統內存，並且不超過32G

vim /etc/profile.d/jdk.sh

export ES_HEAP_SIZE=8g

4.1.3.ES啟動

前台啟動：./elasticsearch

後台啟動：./elasticsearch -d

curl http://host:9200

{

"name" : "Sharon Ventura",

"cluster_name" : "elasticsearch",

"version" : {

"number" : "2.3.1",

"build_hash" : "bd980929010aef404e7cb0843e61d0665269fc39",

"build_timestamp" : "2016-04-04T12:25:05Z",

"build_snapshot" : false,

"lucene_version" : "5.5.0"

"tagline" : "You Know, for Search"

}

4.1.4.集群配置

discovery.zen.ping.unicast.hosts: ["elk-1", "elk-2", "elk-3"]

http://HOST:9200/_cluster/health

http://HOST:9200/_cluster/state

4.1.5.插件

elasticsearch/bin/plugin list

Head

elasticsearch/bin/plugin install mobz/elasticsearch-head

http://HOST:9200/_plugin/head/

kopf

elasticsearch/bin/plugin install lmenezes/elasticsearch-kopf

http://HOST:9200/_plugin/kopf/

4.2. Kibana安裝

4.2.1.安裝啟動

下載安裝文件：

wget https://download.elastic.co/kibana/kibana/kibana-4.5.0-linux-x64.tar.gz

啟動：

bin/kibana

bin/kibana &> nohup

4.2.2.查詢語法

https://lucene.apache.org/core/2_9_4/queryparsersyntax.html

Examples:

module_id:callmanager_10142 AND message:*01058364381

4.2.3.查詢結果顯示數量

When you submit a search query, the 500 most recent documents that match the query are listed in the Documents table. You can configure the number of documents shown in the table by setting thediscover:sampleSize property in Advanced Settings.

5、系統優化

top命令查看cpu負載，load average已經超過cpu核心數8.

top - 17:42:32 up 21 days, 6:00, 7 users, load average: 8.86, 9.29, 9.07

Tasks: 184 total, 1 running, 183 sleeping, 0 stopped, 0 zombie

Cpu(s): 20.7%us, 3.2%sy, 0.0%ni, 62.3%id, 13.4%wa, 0.2%hi, 0.3%si, 0.0%st

Mem: 8058056k total, 7884564k used, 173492k free, 129824k buffers

Swap: 0k total, 0k used, 0k free, 3169088k cached

執行如下iostat命令，可以看到%util接近100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。

$iostat -cx -d 2

avg-cpu: %user %nice %system %iowait %steal %idle

12.93 0.00 3.52 13.25 0.00 70.31

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

xvdb 0.00 229.50 0.00 2527.00 0.00 19760.00 7.82 11.82 4.71 0.37 94.35

dm-0 0.00 0.00 0.00 2661.00 0.00 19512.00 7.33 14.13 5.36 0.35 94.35

執行vmstat命令，可以看到r值和b值較高，r 表示運行和等待cpu時間片的進程數，如果長期大於1，說明cpu不足，需要增加cpu。

b 表示在等待資源的進程數，比如正在等待I/O、或者內存交換等。

$vmstat 2

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 2 0 414828 136456 2958988 0 0 31 277 2 1 3 1 94 2 0

7 1 0 418556 136476 2954916 0 0 6 24808 1936 1703 2 1 84 13 0

2 5 0 409116 136524 2965528 0 0 2 9638 6091 5307 13 3 71 13 0

4 3 0 403288 136564 2970064 0 0 6 8558 6524 4769 16 4 65 15 0

2 3 0 401056 136728 2972552 0 0 70 8546 5567 4658 12 3 73 12 0

8 3 0 399700 136768 2973508 0 0 2 9410 6113 5216 13 3 73 12 0

1 2 0 373900 136792 3000672 0 0 4 9206 6775 4862 19 3 66 13 0

1 0 0 382952 136812 2990552 0 0 4 10278 7599 5121 22 4 62 13 0

1 0 0 385564 136984 2987244 0 0 68 9994 6355 5294 12 3 72 13 0

5 4 0 372164 137040 2998272 0 0 6 8968 6561 5186 14 4 69 13 0

8 2 0 369444 137072 3000900 0 0 2 10582 7244 5217 17 4 65 14 0

1 6 0 368452 137112 3002140 0 0 6 11290 5904 5234 11 2 72 15 0

5.1 Elasticsearch參數調整

※ Index.number_of_replicas

elasticsearch默認會複製1份數據冗餘存儲，可以在某個index日誌收集時將複製數設置為0，以減少IO，如果後期需要存儲備份，則再將複製數設置為1，elasticsearch會自動將數據進行重新整理備份。

※ Index.refresh_interval

數據從緩存刷新到磁碟的間隔，間隔越大,磁碟IO越少。

refresh_interval: 1s – 2.0K docs/s

refresh_interval: 5s – 2.5K docs/s

refresh_interval: 30s – 3.4K docs/s

※ Index.translog.durability

默認情況下，Elasticsearch 每5 秒，或每次請求操作結束前，會強制刷新translog 日誌到磁碟上。後者是Elasticsearch 2.0 新加入的特性。為了保證不丟數據，每次index、bulk、delete、update 完成的時候，一定觸發刷新translog 到磁碟上，才給請求返回200 OK。這個改變在提高數據安全性的同時當然也降低了一點性能。如果你不在意這點可能性，還是希望性能優先，可以在index template 里設置如下參數："index.translog.durability" : "async"

※ index.merge.scheduler.max_thread_count

merge線程的數量，線程數越少，磁碟IO越少。設置為1即可。

5.2 伺服器硬體配置調整

SSD：提高I/O吞吐

CPU，內存：提高查詢性能

6、日誌管理

為了更加方便的做清除數據，合併segment，備份恢復等管理任務，Elasticsearch 在提供相關API 的同時，另外準備了一個命令行工具，叫curator 。curator 是Python 程序，可以直接通過pypi 庫安裝：pip install elasticsearch-curator

1.查看10天前的index

curator --host localhost show indices --regex "^filebeat*" --timestring "%Y.%m.%d" --older-than 10 --time-unit days

2.刪除10天前的index

curator --host localhost delete indices --regex "^filebeat*" --timestring "%Y.%m.%d" --older-than 10 --time-unit days

7、其他系統日誌架構

方案一：flume+kafka+ELK

方案二:beats+logstash+kafka+ELK

many Beats ---&> Logstash ---&> queue (Redis, Kafka, etc.) ---&> Logstash ---&> Elasticsearch

Filebeat 5.0支持直接輸出消息給kafka