一、前言
在軟體發開技術管理裡有兩個永恆經典的問題，適合我們初到一家軟體企業或一家公司的科技團隊，來判斷自己該從哪裡入手幫助整個團隊提升科技水平和產能。問題一是“在我們團隊裡，只涉及一行程式碼的變更需要多久才能上線？”，問題二是“在我們團隊裡，定位一個線上問題需要多久？流程是什麼？”。問題一關注的是“交付”，問題二關注的是“保障”。今天寫這邊文章跟大家聊聊有關問題二的故事。
不怕大家笑話，我最初的公司每個服務生產上就兩臺Tomcat。定位生產問題，就是連上一臺機器，然後用使用 cd / tail / grep / sed / awk 等 Linux 指令碼去日誌裡查詢故障原因。如果發現不在這臺機器上，就去另一臺機器上查日誌。（如果你現在的公司還是這樣幹，記住出去面試的時候也不要說是這樣幹，不然很容易由於你之前的公司的整體技術水平太low而把你pass掉）
但在應用伺服器規模較大的場景中，此方法效率低下，面臨問題包括日誌量太大如何歸檔、文字搜尋太慢怎麼辦、如何多維度查詢。需要集中化的日誌管理，所有伺服器上的日誌收集彙總。常見解決思路是建立集中式日誌收集系統，將所有節點上的日誌統一收集，管理，訪問。一般大型系統是一個分散式部署的架構，不同的服務模組部署在不同的伺服器上，問題出現時，大部分情況需要根據問題暴露的關鍵資訊，定位到具體的伺服器和服務模組，構建一套集中式日誌系統，可以提高定位問題的效率。
以搜尋引擎聞名世界的開源軟體提供商-Elastic為我們大家提供了一套完整的日誌收集以及展示的解決方案——ELK。是三個產品的首字母縮寫，分別是ElasticSearch、Logstash 和 Kibana。
二、ELK簡介
Logstash主要是用來負責蒐集、分析、過濾日誌的工具，支援大量的資料獲取方式。一般工作方式為c/s架構，client端安裝在需要收集日誌的主機上，server端負責將收到的各節點日誌進行過濾、修改等操作在一併發往elasticsearch上去。
ElasticSearch用來負責儲存最終資料、建立索引和對外提供搜尋日誌的功能。它是個開源分散式搜尋引擎，提供蒐集、分析、儲存資料三大功能。它的特點有：分散式，零配置，自動發現，索引自動分片，索引副本機制，restful風格介面，多資料來源，自動搜尋負載等。
Kibana是一個優秀的前端日誌展示框架，它可以非常詳細的將日誌轉化為各種圖表，為使用者提供強大的資料視覺化支援。
三、不同級別的ELK架構
1、入門級
這是最簡單的ELK架構，這種架構下我們把 Logstash例項與Elasticsearch例項直接相連，主要就是圖一個簡單。我們的程式App將日誌寫入Log，然後Logstash將Log讀出，進行過濾，寫入Elasticsearch。最後瀏覽器訪問Kibana，提供一個視覺化輸出。
入門級版本的缺點主要是兩個
- 在大併發情況下，日誌傳輸峰值比較大。如果直接寫入ES,ES的HTTP API處理能力有限，在日誌寫入頻繁的情況下可能會超時、丟失，所以需要一個緩衝中介軟體。
- 注意了，Logstash將Log讀出、過濾、輸出都是在應用伺服器上進行的，這勢必會造成伺服器上佔用系統資源較高，效能不佳，需要進行拆分。
於是我們作為公司最牛的架構師，提出了一個升級版的ELK架構，解決如上兩個問題。
2、升級版
在這版中，加入一個緩衝中介軟體（訊息佇列）。另外對Logstash拆分為Shipper和Indexer。先說一下，LogStash自身沒有什麼角色，只是根據不同的功能、不同的配置給出不同的稱呼而已。Shipper來進行日誌收集，Indexer從緩衝中介軟體接收日誌，過濾輸出到Elasticsearch。具體如下圖所示
大家會發現，早期的部落格，都是推薦使用redis。因為這是ELK Stack 官網建議使用 Redis 來做訊息佇列，但是很多大佬已經通過實踐證明使用Kafka更加優秀。原因如下:
- Redis無法保證訊息的可靠性，這點Kafka可以做到
- Kafka的吞吐量和叢集模式都比Redis更優秀
- Redis受限於機器記憶體，當記憶體達到Max，資料就會拋棄。當然，你可以說我們可以加大記憶體啊？但是，在Redis中記憶體越大，觸發持久化的操作阻塞主執行緒的時間越長。相比之下，Kafka的資料是堆積在硬碟中，不存在這個問題。
但這個升級版仍然存在缺陷：
- Logstash Shipper是jvm跑的，非常佔用JAVA記憶體！ 。據《ELK系統使用filebeat替代logstash進行日誌採集》這篇文章說明，8執行緒8GB記憶體下，Logstash常駐記憶體660M（JAVA）。因此，這麼一個巨無霸部署在應用伺服器端就不大合適了，我們需要一個更加輕量級的日誌採集元件。
- 上述架構如果部署成叢集，所有業務放在一個大叢集中相互影響。一個業務系統出問題了，就會拖垮整個日誌系統。因此，需要進行業務隔離！
於是我們給我們在Elastic公司的朋友打了個電話，說明了他們這個集中型日誌解決方案的弊端——太費CPU也就太費電。Elastic公司的朋友電話中告訴我們最近新研發了一個FileBeat，它是一個輕量級的日誌收集處理工具(Agent)，Filebeat佔用資源少，適合於在各個伺服器上搜集日誌後傳輸給Logstash，官方也推薦此工具。
3、大師版
從上圖可以看到，Elasticsearch根據業務部了3個叢集，他們之間相互獨立。避免出現，一個業務拖垮了Elasticsearch叢集，整個日誌系統就一起當機的情況。而且，從運維角度來說，這種架構運維起來也更加方便。
這套架構的缺點在於對日誌沒有進行冷熱分離。因為我們一般來說，一個月之內不排查的錯誤日誌，那都是不重要的錯誤。以30天作為界限，區分冷熱資料，可以大大的優化查詢速度。
4、專家版
這一版，我們對資料進行冷熱分離。每個業務準備兩個Elasticsearch叢集，可以理解為冷熱叢集。7天以內的資料，存入熱叢集，以SSD儲存索引。超過7天，就進入冷叢集，以SATA儲存索引。這麼一改動，效能又得到提升
四、ELK的工作原理
1、Filebeat工作原理
Filebeat由兩個主要元件組成：prospectors 和 harvesters。這兩個元件協同工作將檔案變動傳送到指定的輸出中。
Harvester（收割機）：負責讀取單個檔案內容。每個檔案會啟動一個Harvester，每個Harvester會逐行讀取各個檔案，並將檔案內容傳送到制定輸出中。Harvester負責開啟和關閉檔案，意味在Harvester執行的時候，檔案描述符處於開啟狀態，如果檔案在收集中被重新命名或者被刪除，Filebeat會繼續讀取此檔案。所以在Harvester關閉之前，磁碟不會被釋放。預設情況filebeat會保持檔案開啟的狀態，直到達到close_inactive（如果此選項開啟，filebeat會在指定時間內將不再更新的檔案控制程式碼關閉，時間從harvester讀取最後一行的時間開始計時。若檔案控制程式碼被關閉後，檔案發生變化，則會啟動一個新的harvester。關閉檔案控制程式碼的時間不取決於檔案的修改時間，若此引數配置不當，則可能發生日誌不實時的情況，由scan_frequency引數決定，預設10s。Harvester使用內部時間戳來記錄檔案最後被收集的時間。例如：設定5m，則在Harvester讀取檔案的最後一行之後，開始倒數計時5分鐘，若5分鐘內檔案無變化，則關閉檔案控制程式碼。預設5m）。
Prospector（勘測者）：負責管理Harvester並找到所有讀取源。
Prospector會找到/apps/logs/*目錄下的所有info.log檔案，併為每個檔案啟動一個Harvester。Prospector會檢查每個檔案，看Harvester是否已經啟動，是否需要啟動，或者檔案是否可以忽略。若Harvester關閉，只有在檔案大小發生變化的時候Prospector才會執行檢查。只能檢測本地的檔案。
Filebeat如何記錄檔案狀態：
將檔案狀態記錄在檔案中（預設在/var/lib/filebeat/registry）。此狀態可以記住Harvester收集檔案的偏移量。若連線不上輸出裝置，如ES等，filebeat會記錄傳送前的最後一行，並再可以連線的時候繼續傳送。Filebeat在執行的時候，Prospector狀態會被記錄在記憶體中。Filebeat重啟的時候，利用registry記錄的狀態來進行重建，用來還原到重啟之前的狀態。每個Prospector會為每個找到的檔案記錄一個狀態，對於每個檔案，Filebeat儲存唯一識別符號以檢測檔案是否先前被收集。
Filebeat如何保證事件至少被輸出一次：
Filebeat之所以能保證事件至少被傳遞到配置的輸出一次，沒有資料丟失，是因為filebeat將每個事件的傳遞狀態儲存在檔案中。在未得到輸出方確認時，filebeat會嘗試一直髮送，直到得到回應。若filebeat在傳輸過程中被關閉，則不會再關閉之前確認所有時事件。任何在filebeat關閉之前為確認的時間，都會在filebeat重啟之後重新傳送。這可確保至少傳送一次，但有可能會重複。可通過設定shutdown_timeout 引數來設定關閉之前的等待事件回應的時間（預設禁用）。
2、Logstash工作原理
Logstash事件處理有三個階段：inputs → filters → outputs。是一個接收，處理，轉發日誌的工具。支援系統日誌，webserver日誌，錯誤日誌，應用日誌，總之包括所有可以丟擲來的日誌型別。
Input：輸入資料到logstash，一些常用的輸入為：
file：從檔案系統的檔案中讀取，類似於tail -f命令
syslog：在514埠上監聽系統日誌訊息，並根據RFC3164標準進行解析
redis：從redis service中讀取
beats：從filebeat中讀取
Filters：資料中間處理，對資料進行操作。
一些常用的過濾器為：
grok：解析任意文字資料，Grok 是 Logstash 最重要的外掛。它的主要作用就是將文字格式的字串，轉換成為具體的結構化的資料，配合正規表示式使用。內建120多個解析語法。（官方提供的grok表示式：https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
grok線上除錯：https://grokdebug.herokuapp.com/）
mutate：對欄位進行轉換。例如對欄位進行刪除、替換、修改、重新命名等。
drop：丟棄一部分events不進行處理。
clone：拷貝 event，這個過程中也可以新增或移除欄位。
geoip：新增地理資訊(為前臺kibana圖形化展示使用)
Outputs：outputs是logstash處理管道的最末端元件。一個event可以在處理過程中經過多重輸出，但是一旦所有的outputs都執行結束，這個event也就完成生命週期。一些常見的outputs為：
elasticsearch：可以高效的儲存資料，並且能夠方便和簡單的進行查詢。
file：將event資料儲存到檔案中。
graphite：將event資料傳送到圖形化元件中，一個很流行的開源儲存圖形化展示的元件。
3、Elasticsearch 基本原理
舉個例子，現在我們要儲存唐宋詩詞，關係型資料庫中我們們會怎麼設計？詩詞表我們可能的設計如下：
|
朝代 |
作者 |
標題 |
詩詞全文 |
|
唐 |
李白 |
靜夜思 |
床前明月光，疑是地上霜。舉頭望明月，低頭思故鄉。 |
|
宋 |
李清照 |
如夢令 |
常記溪亭日暮，沉醉不知歸路，興盡晚回舟，誤入藕花深處。爭渡，爭渡，驚起一灘鷗鷺。 |
要根據朝代或者作者尋找詩，都很簡單，比如“select 詩詞全文 from 詩詞表where作者=‘李白’”，如果資料很多，查詢速度很慢，怎麼辦？我們可以在對應的查詢欄位上建立索引加速查詢。
但是如果我們現在有個需求：要求找到包含“望”字的詩詞怎麼辦？用
“select 詩詞全文 from 詩詞表 where 詩詞全文 like‘%望%’”，這個意味著
要掃描庫中的詩詞全文欄位，逐條比對，找出所有包含關鍵詞“望”字的記錄，。
基本上，資料庫中一般的 SQL 優化手段都是用不上的。數量少，大概效能還能接受，如果資料量稍微大點，就完全無法接受了，更何況在網際網路這種海量資料的情況下呢？
怎麼解決這個問題呢，用倒排索引Inverted index
比如現在有：
蜀道難（唐）李白 蜀道之難難於上青天，側身西望長諮嗟。
靜夜思（唐）李白 舉頭望明月，低頭思故鄉。
春臺望（唐）李隆基 暇景屬三春，高臺聊四望。
鶴沖天(宋)柳永 黃金榜上，偶失龍頭望。明代暫遺賢，如何向？未遂風雲便，爭不恣狂蕩。何須論得喪？才子詞人，自是白衣卿相。煙花巷陌，依約丹青屏障。
幸有意中人，堪尋訪。且恁偎紅翠，風流事，平生暢。青春都一餉。忍把浮名，換了淺斟低唱！
這些詩詞都有望字，於是我們可以這麼儲存
|
序號 |
關鍵字 |
蜀道難 |
靜夜思 |
春臺望 |
鶴沖天 |
|
1 |
望 |
有 |
有 |
有 |
有 |
|
|
|
|
|
|
|
其實，上述詩詞的中每個字都可以作為關鍵字，然後建立關鍵字和文件之間的對應關係，也就是標識關鍵字被哪些文件包含。
所以，倒排索引就是，將文件中包含的關鍵字全部提取處理，然後再將關鍵字和文件之間的對應關係儲存起來，最後再對關鍵字本身做索引排序。使用者在檢索某一個關鍵字是，先對關鍵字的索引進行查詢，再通過關鍵字與文件的對應關係找到所在文件。
Elasticsearch 索引是對映型別的容器。一個 Elasticsearch 索引非常像關係型世界的資料庫，是獨立的大量文件集合。
當然在底層，肯定用到了倒排索引，最基本的結構就是“keyword”和“PostingList”，Posting list就是一個 int的陣列，儲存了所有符合某個 term的文件 id。
另外，這個倒排索引相位元定詞項出現過的文件列表，會包含更多其它資訊。
它會儲存每一個詞項出現過的文件總數，在對應的文件中一個具體詞項出現的總次數，詞項在文件中的順序，每個文件的長度，所有文件的平均長度等等相關資訊。