elasticsearch+logstash+kinana搭建的日誌收集系統

elasticsearch是基於倒排序查詢的查詢引擎，什麼叫倒排序？比如mysql建立的索引是正排序，對於規範化資料(比如表格，元資料)而言基本使用正排序索引，倒排序一般用於文字之類的查詢，典型的例子是關鍵字搜尋文獻，在錄入文獻時，對每一個關鍵字建立索引，可以看到它屬於哪一篇文章，這樣就可以很方便的進行查詢，缺點是對內容建索引代價比較高，如果要進行查詢需要把所有的日誌載入到記憶體中，耗記憶體大

logstash作為日誌系統的收集器起著收集和過濾功能，需要在每一臺被收集日誌的主機上安裝logstash_shippment，master節點安裝logstash_indexer,可以在其中使用grok外掛在裡面編寫一些正則完成過濾，規定內容格式（比如json）,設定一些規則或者做統計，最典型的例子：指定輸入路徑/var/log/messages,輸出的地方寫kafka host:9092這樣就預設把日誌匯出到kafka中，注意要有時間戳，還要符合預設格式，

kibana作為視覺化工具，只需要會安裝，使用和其他元件通過網路埠對接即可。可以在文字框裡輸入查詢條件查詢，也可以確定索引條件之後進行查詢。

中介軟體為了保證效能（查詢快）和高可用性（一個節點崩掉還能使用的叢集）用了kafka訊息佇列搭建的叢集做logstash_shippment和logstash_indexer的對接，kafka對某一類日誌建立topic,每一個topic收集的日誌劃分為若干partition（日誌收集太多一個節點的儲存不夠），每一個partition可以複製來保證高可用性，每個broker存放一個topic下的一個partition,仔細看的話，一個topic實際上是一個訊息佇列，partition是拆分的檔案，如broker1存放著topic_1資料夾，broker2存放著topic_2資料夾，合併起來是一個topic。shippement做生產者，indexer做消費者。為了保證高可用，kafka有一個引數replic表示一份訊息的備份數量，叢集會選出一個master節點，每次日誌先匯入master節點，之後master節點同從節點進行通訊從而完成同步，主節點崩掉之後從節點中再次選舉出主節點，叢集之間選舉使用zookeeper元件完成節點之間的同步通訊和選舉。

部署叢集至少使用三個節點，少於3會引起zookeeper選舉master的一個bug.

最早無腦搭建，花了三天時間排查錯誤，發現kibana只有一個空介面，沒有索引。後來排查是和es對接有問題，問題1KO。

再往下，有索引出不來查詢日誌，往下摳，摳到kafaka，看kafka的日誌，發現是zookeeper報錯，zkServer沒啟動起來，再看zookeeper.out(zk安裝目錄下的日誌檔案)，有一個java connected refused錯誤，最後先單節點的zkServer自己和自己通訊，發現zkServer可以啟動，和其他主機通訊有問題，可能是網路問題。

發現報錯，不要慌，先看報錯行，有時候你看到的不一定是真實的，比如zkSever.sh執行之後會報zkServer has Started，但是真的Started了嗎？沒有，看zk.out就會看到

javaExceptiioin(5607) connected refused，這時候先在核對配置，有時候註釋啦，空格啦的低階失誤可能是元凶，之後再想想和理想化環境有什麼差別，比如電腦上安裝了什麼軟體，有影響？最後把錯誤搬到網上，可能之前其他人也碰到過這種詭異的事情。其中最詭異的事情是，我把主機上的kibana解除安裝之後，開啟host:5601之後發現kibana還能訪問？最後發現是主機上裝了docker,訪問的是docker上的kb

在排查zk錯誤的過程中，去檢查了三遍配置，網上查kafka,zk原理，學習了一些新命令,嘗試著寫#!/bash/bin開頭的shell指令碼在每一臺主機上部署

sh -n先檢查指令碼，sh -x執行指令碼並且在控制檯列印輸出，echo變數

sudo -i登陸root的方法

tail -n 200 aaa.log列印最新的日誌

sudo ufw enable|disable開啟或者關閉防火牆

最常用兩個安裝目錄/usr/local,/opt

命令多敲，多思考

具體實現，推薦

https://kibana.logstash.es/content/logstash/get-start/install.html