一、啥是日誌， 為啥要聚合
面試初級同學常問的問題之一就是，一個線上執行的生產系統，如果出現了一些在測試環境復現不了的bug該如何處理啊？錯誤回答：“我們的系統從沒有出過問題”，正確回答：“加日誌”。
對於不能穩定復現，或者不方便除錯的場景， 通過在程式的執行路徑上增加一些文字的記錄，輸出為檔案，供後續分析檢視程式的執行過程，是謂之日誌。日誌可以24小時，無人值守的忠實記錄程式的執行過程，是排查偶發問題，以及運維監控利器。
日誌一般都存在級別（error,warn,info,debug）的概念，詳盡程度依次遞增， 因為寫日誌本身也會產生磁碟IO，佔用系統資源，所以在生產環境一般不會輸出debug級別日誌。日誌檔案的副檔名通常為.log.
if(a>1){ log.i("a>1");//日誌 }else{ log.i("a不大於1"); //日誌 }
——日誌
那為啥是日誌聚合呢？實際場景中，日誌檔案通常不會是簡簡單單的一份， 例如現在流行的微服務，或者分散式部署。一個系統各個模組被執行在不同的系統程式，甚至於不同的物理伺服器上。這樣就會產生數個日誌檔案， 分佈在不同的資料夾或者不同的計算機上。 如果我想完整的跟蹤一個使用者操作（如下訂單），如果這不是一個簡單的單程式伺服器，那我只能去依次開啟，各個模組所輸出的日誌檔案，然後根據時間人肉拼湊在一起看。由於系統是多執行緒多使用者的，在多個日誌檔案中關聯追蹤一筆業務的發生過程，會非常繁瑣。
——模擬多執行緒，多使用者系統的日誌檔案內容
聚合就可以理解為把這些分散的日誌檔案，合併到一起，可以統一的查詢，過濾。
二、日誌收集系統原理組成
如何可以把日誌收集到一起，並方便檢視呢? 比如一個簡單直接的想法就是各模組都把日誌儲存到一個統一的資料庫中，這樣就可以統一儲存，查詢了。其實日誌收集系統的基本原理也是如此。基本分為
收集器 —— 可以看做資料庫的客戶端驅動，讀取日誌檔案，通過網路傳送給儲存中心。
日誌儲存（資料庫）—— 可以看做資料庫，把收集器收集到的檔案儲存下來，並提供查詢功能。通常支援特定的簡單查詢語言，可以通過編寫指令碼的方式查詢。
查詢介面 —— 類似於圖形介面的資料庫查詢工具，提供直觀的操作互動，比黑洞洞的控制檯體驗好的多。
——日誌被自下而上收集，使用者通過圖形介面統一查詢
三、全文索引與輕量化
在日誌收集的這三個角色中，日誌收集器與圖形介面都相對簡單，容易理解，而日誌的儲存查詢部分則要複雜一些。
日誌通常條數眾多，一個有一定有戶數的WEB系統，每天產生個幾千上萬個W條數的日誌，都是毫不意外地。對於這樣多的日誌資料，如何提供快速查詢能力，是要想點特殊的辦法的。簡單的記事本字串查詢的方式，等結果可能會到天荒地老。
全文索引 —— 就是對一段特定的文字進行預處理，生成一個處理結果，這個結果記錄了，每個文字/單詞，在文件中出現的位置，並將這個結果儲存起來，後續利用這個預處理結果，當你想查詢一個文字/單詞時，就可以快速的給出，包含這個字詞的行數。
第一行：我很醜可是我很溫柔
第二行：我很醜可是我有音樂和啤酒
索引
我： 第一行，第二行
醜：第一行，第二行
音樂：第二行。
……
——全文索引簡單原理說明，搜尋我時，則可以快速的定位到第一第二行。
從上面的簡單介紹可以看出，如何分詞是有很有技術含量的，分詞方法會影響索引結果的大小，進而與查詢效率有關。而通常索引檔案都是大於被索引的內容本身的。
對日誌內容進行全文索引，優點是可以提供較好的查詢效率，缺點則是需要更多的儲存空間，更大的磁碟，更好的硬體則意味更多的￥ :-) 。著名的ELK日誌聚合解決方案中的儲存部分Elasticsearch就是採用全文索引技術，提供搜尋優化的。
輕量化 —— 如果沒有￥，但是有時間，也是有解決方案的。比如我有多套開發，測試，聯測環境，用ELK這類全文索引類的儲存太佔地方。不做全文索引，用蠻力進行字串搜尋的方案也是存在的，如Grafana Labs 的 Loki。像標稱的那樣，的確很輕量化，安裝簡單，配置簡單，不需要太多的儲存空間，在處理的日誌不是太多時，搜尋效率完全可以接受。更多資訊：https://grafana.com/oss/loki/
四、滾(Rolling)
只要程式在執行，日誌就會源源不斷產生。於是終於有一天會佔滿全部硬碟，然後就沒有然後了。所以日誌檔案的生成，要記得配置滾動週期，讓超期的日誌檔案自動刪除。這點對於日誌聚合系統來說也非常重要，可能更加重要，因為畢竟是一個儲存中心，會儲存多個收集器同步的日誌檔案，不定時清理，會很快被塞滿。
~~最後， 希望能幫助入門的同學，願世界和平~~~！