隨著互聯網、物聯網的飛速發展，軟硬件系統架構變得越來越複雜，分析各種系統產生的日誌也變得越來越困難。在日誌分析過程中，相信大部分同學會碰到以下問題：
1. 定位問題耗費大量時間 通常一個系統的各模塊是分散在各個機器上的，定位問題時運維同學只能逐臺登錄機器查看日誌。特別是分佈式系統，需要逐個模塊查日誌，流程比較繁瑣，也浪費大量的時間。
2. 定位到問題日誌後，難以過濾有效信息 日誌是以普通文本的形式存儲的，尤其生產環境的系統會打印很多冗餘日誌。在錯誤信息的上下文中，查找與問題相關的日誌時，只能通過一些簡單的less、grep等命令來做過濾，效率比較低。而且過濾出來的結果集也未必完全符合預期，分析起來比較困難。
3. 日誌量大，容易被刪除 前面提到，生產環境的系統為了在故障時提供更多的信息，往往會打印比較多的冗餘日誌，佔用過多的本機存儲空間，侵佔業務可以使用的資源。 機器故障無法登錄時，也無法查看日誌。
以上問題，Elastic Stack都可以解決！ 本次課程就主要分享下怎樣通過Elastic Stack解決日誌分析碰到的各種問題。
Elastic Stack架構
Elastic Stack由四個組件組成，分別是Beats、Logstash、Elasticsearch、Kibana。它們提供了日誌採集、清洗、存儲、可視化的能力，是一個比較完備的架構。
1. Beats：是一組工具集，一些輕量的數據採集器。 需要把他們安裝在生產環境的各個機器上，他們採集了本機日誌後，向Logstash或Elasticsearch發送數據。
2. Logstash：動態數據收集管道，負責數據的清洗、格式化、添加附屬信息等。 Logstash的功能是很強大的，它支持從多種系統中收集數據，又可以把數據推送到各種系統裡。
3. Elasticsearch：是一種分佈式搜索引擎，數據的存儲、查詢都集中在這裡。 它本身有較為強大的集群管理功能，支持水平擴展。 數據多分片、多副本存儲，即提供高併發的寫入查詢能力，又能保證數據可靠性。
4. Kibana：數據可視化平臺 支持各種豐富的圖表，可以直觀的呈現日誌數據。 也提供了易用的搜索界面，簡化問題定位過程。
從Elastic Stack的架構出發，可以看出它具備以下能力：
1. 提供了完整的解決方案，包括日誌採集、清洗、存儲、可視化的完整工具鏈。 沒有外部依賴，整個日誌分析系統的架構比較簡單。 功能完備，日誌分析領域裡的需求基本都覆蓋了。
2. 強大的分析能力 Elastic Stack即有能力將普通文本格式化成json結構存儲，又提供了豐富的查詢、聚合接口，便於統計分析。 也支持全文索引、模糊匹配、中文分詞等能力，這對於定位問題是非常有用的。
3. 可靠的分佈式存儲 存儲核心Elasticsearch是一個分佈式的存儲系統，可以彈性伸縮（水平擴展），多副本存儲保證數據可靠性，並且自身有比較完備的集群管理能力，簡單易用。
使用Elastic Stack做日誌分析
前面主要介紹了Elastic Stack的架構和基本能力，後面著重分享怎樣使用Elastic Stack做日誌分析。主要使用三個組件：
1. Elasticsearch，主要負責日誌的清洗、存儲、查詢。
2. Filebeat，日誌的採集工具，是Beats家族中的一員，顧名思義是用來採集文本文件內容的。
3. Kibana，主要提供數據可視化的能力。
Elastic Stack的架構中，有四個組件，本次課程去掉了Logstash。原因是雖然它功能強大，但是資源消耗也比較高，很容易成為整個系統的性能瓶頸。它數據日誌格式化的能力，通過Elasticsearch的數據預處理模塊替代。這樣有助於精簡架構、提整體的高性能。
中間的這張圖是本次課程的架構方案，也代表了日誌數據流動的過程，從左到右分別經過Beats（也就是Filebeat）、Elasticsearch和Kibana。但是為了便於大家理解，後面的課程會先介紹Elasticsearch，因為他是整個架構的核心，然後再介紹日誌採集器Filebeat，最後介紹可視化工具Kibana。
經過本次課程，大家能瞭解到怎樣把純文本的日誌文件變為格式化的數據，以及怎樣通過kibana快速搜索到有效信息，或者把日誌數據轉變為可視化的圖表。
Elasticsearch簡介
第一部分來介紹Elasticsearch，後續稱之為ES。在Elastic Stack的中它處於中心位置，是數據存儲的核心，所以也是最重要的部分。
這裡會帶大家瞭解下ES的總體架構和負責日誌清洗功能的Ingest Pipeline。
ES的數據模型分為幾個層級，Index、Type、Document。這張圖把這幾個層級和傳統關係型數據庫中的相關概念做了類比，便於大家理解。
Index：類似於關係型數據庫的Database或Table，用於對數據做最上層的分類。我們可以把不同模塊產生的日誌，存放在不同的Index中。
Type：類似於關係型數據庫中Table的概念，這裡和上面Index的概念有些重複。因此6.0以後的ES版本中，一個Index只能存在一個Type了，7.0以後的版本會取消對Type的支持。在使用ES時，不要再指定多個Type，數據分類完全通過Index劃分即可。
Document：類似於關係型數據庫中Row的概念，也就是一行數據。ES裡的每個Document是一個Json格式的結構體，可以有多個字段，存放不同的信息。
還有一個單獨的概念是Mapping，類比於關係型數據庫中的schema，用於指定每個字段的數據類型。通常情況下，ES是Schema free的。只有碰到特殊類型的字段，比如ES默認無法識別的Date（時間）類型的字段、不需要分詞的String類型字段時，才需要指定Mapping。本次課程中，將不涉及這個概念，我們使用ES默認生成的Mapping即可。
上面講的Index是一個邏輯上的概念，它從命名空間的維度把ES裡存儲的數據做了分類（也就是分表），同一類的數據放在同一個Index中。
而實際存儲時，一個Index的數據會分佈在多個分片上（稱之為shard），每個shard承載一個Index的一部分數據。而每個分片又可以有多個副本，其中一個是主副本，稱之為primary，其他是從副本，稱之為replica。
圖中有兩個Index，Index1和Index2. 其中Index1 有兩個Primary Shard，P1和P2. 每個Primary Shard又有兩個副本，比如P1的兩個R1副本。
至此大家理解了Index和Shard的關係，以及Primary、Replica的概念。
ES本身又是一個多節點的分佈式集群，shard被打散後分布在各個node上。不同的node可以分佈在不同的機器上。
而且ES默認同一個shard的primary和replica不會同時存在於同一個Node上，這樣即使某個Node故障脫離集群，也可以保證不丟數據，因為集群中還有另一個副本在。
圖中的P1和兩個R1，分別分佈在三個Node（Node1，Node2，Node3）上，它們所承載的數據是一模一樣的。當Node1、Node2同時故障宕機時，ES集群裡仍然有一個R1存在，不會影響數據的讀寫服務，更不會丟數據。
由ES的分佈式架構，可以總結ES的一些優點：
高性能
o 分佈式搜索引擎，可線性擴展提升系統性能
o 多個shard分攤壓力，高併發寫入、查詢
高可靠
o 多副本存儲，節點故障不丟數據
o 基架、機房感知，可以設置同一個shard的副本分配到不同的機房裡，避免機房故障導致數據丟失，達到主從容災的效果
易管理
o 自帶強大的集群管理功能，彈性可伸縮 - shard自動均衡，可以根據業務變化隨時增減節點數
易使用
o RESTful接口，易於開發和調試
o 強大的聚合分析能力，可以做複雜的統計分析（分桶、geo hash、多層聚合等）
默認情況下，下載ES的安裝包後，進入ES目錄，直接執行下面的命令，ES就會在後臺啟動，並監聽機器的9200端口。我們通過這個端口就能讀寫數據了，不需要對ES做額外的配置。
ES這個章節的第二部分，來介紹ES的一個特殊模塊，Ingest Pipeline，這個模塊用來對寫入數據做預處理。
在數據真正寫入到ES的Index之前，可以通過Ingest Pipeline對數據做一定的修改。它裡面可以定義一些processor，不同的processor可以對寫入數據做不同的處理。比如可以通過Grok Processor做日誌的格式化，來替代Logstash。
最下面的圖是Grok Processor的工作原理。對於寫入ES的文本（Simple Data），可以定義一個表達式（Grok Pattern），來規定如何對輸入的文本做解析。也就是按照一定的規則，把輸入文本分割為幾個部分，每個部分是一個單獨的字段。經過解析後，最終形成最下面的結構化數據。
所謂的Grok Pattern其實是正則表達式，只不過ES對常用的正則表達式做了別名，方便我們使用。所謂的文本解析也就是正則匹配，然後把匹配到的各個部分分別放入不同的字段，形成結構化數據。
圖中的數據是一段樣例日誌，被分為三個部分，分別通過正則匹配解析為三個字段。 - 紅色部分被解析為time字段，代表這條產生這條日誌的時間。 - 黃色部分被解析為client字段，代表訪問該服務的客戶端IP地址。 - 藍色部分被解析為duration字段，代表本次服務的耗時。
那麼該如何定義一個Pipeline呢？
圖中顯示的是本次課程使用的pipeline，根據ES的API，我們通過REST PUT命令即可定義一個Pipeline。
URL中的ingest/pipeline是ES定義pipeline的固定API，最後的apachelog是我們定義的這個pipeline的名字（pipeline_name），後面寫入數據時會用到這個pipelinename。後面會使用Filebeat採集apache的一段日誌，因此這裡的pipelien取名為apachelog。
Http的Body是json格式的，定義了processors，裡面有三個processor：grok、date、dateindexname. - grok processor我們介紹過了，這裡採用的pattern是ES內部預定義的用於解析apache日誌的表達式，我們拿來直接使用即可。 - date processor是把grok生成的timestamp字段，改為Date類型。因為默認情況下grok生成的字段是string類型的，這裡需要轉換一下。 - dateindexname processor：通常我們的日誌是跟時間強相關的，為了便於管理、刪除過期日誌等，通常index是按照時間範圍劃分的，比如一天生成一個index，當天的數據都寫到同一個index裡面，然後第二天生成的日誌會寫到一個新的index裡面。 dateindexname processor可以根據根據時間字段（也就是上面生成的timestamp字段），自動生成index name，這樣在寫入數據時就不用指定index name了。 圖中定義的index name是的一個前綴apache_log@加上當天的日期，實際生成的index name如圖中最下面部分所示。
至此，ES的部分就介紹完了。
Filebeat原理
第二部分介紹Filebeat，它處於整個Elastic Stack最上游，負責日誌採集。主要介紹下Filebeat的基本原理以及怎樣配置啟動。
filebeat的基本原理 Filebeat是Beats家族中的一員，Beats包括很多工具，感興趣的同學可以去官網瞭解下。
如第一張圖所示，Filebeat是一種文本採集器，它可以監聽文本文件，類似於linux的tailf命令，不斷採集文件中的新增內容，然後把採集到的數據發送至Logstash或者Elasticsearch。
它需要安裝在生產環境上，也就是產生日誌文件的機器上，但是它採用Golang語言編寫，效率比較高；而且功能簡單，比較輕量，佔用的機器資源較少。
它具備重啟續傳的能力。filebeat會把當前在監聽文件的元信息保存在一個registry文件中。如第二張圖所示，裡面記錄了相應文件的路徑、inode信息以及採集器已讀取的位置（offset）。當Filebeat進程退出，下次重新啟動後，會讀取regstry文件，對於其中監聽的文件，從offset的位置開始，繼續讀取文件內容。
Filebeat還具備壓力感知的能力，它會根據ES集群當前的負載狀況，動態調整自己傳送數據的速度，防止ES集群壓力過高。
filebeat的基本配置
filebeat的配置文件就在filebeat根目錄下，yaml格式。 默認狀態下，我們只需要修改input（採集哪些文件）和output（數據輸出到哪裡）即可。
input：
o enabled：默認是false，改為true後，Filebeat才會去採集文件內容。
o paths：需要採集的文件路徑，這是一個序列，可以配多個路徑，filebeat會同時監聽這些路徑下的文件。paths也支持通配符，方便配置一個路徑下的多個文件。
output： 日誌需要輸出到ES中，所以需要修改output.elasticsearch：
o hosts: ES集群各節點的ip和port，是個序列，可配置集群中多個節點的地址
o pipeline: 寫入數據時使用的pipeline，這裡填前面在ES裡創建的apache_log
這樣filebeat就配置好了，啟動的話直接執行filebeat二進制即可。 如果要後臺執行的話，可以用nohup命令啟動 如果擔心filebeat佔用過多的機器資源，可以通過taskset綁核啟動，限制filebeat的資源使用。
當採集的日誌量比較大時，默認的配置可能無法滿足需求，這裡給出一些通常使用的調優參數，大家可以做個參考。當然不同場景下，最佳的參數配置也是不同的，需要根據自己的實際使用場景，做適當的取捨和調整。對於這些參數，此處不做過多的闡述，可以參考filebeat的官方文檔。有問題可以留言交流，後面有時間也會整理下調整這些參數的原因及效果。
Kibana簡介
最後一部分介紹Kibana，它處於Elastic Stack的最下游，主要提供數據分析、可視化的能力。主要介紹Kibana的基本功能以及怎樣通過它來查詢數據、生成可視化的圖表。
Kibana提供了數據查詢、可視化及統計分析的能力。
它是一個獨立的進程，需要下載後獨立部署，它只能綁定一個ES集群，無法同時查詢多個ES集群的數據。
搜索 Discovery 查詢界面，通過簡單的查詢條件就能獲取目標數據，提高問題定位的效率。
可視化 Visualize功能，這是它最大的亮點，可以藉助ES的聚合查詢接口，生成如圖所示的各種圖表。
數據管理 提供命令行界面Console，可以完成數據的增刪改查、通過命令管理ES集群。
X-Pack Monitor 同ES提供的增值服務X-Pack一起使用的話，Kibana還可以提供監控的能力，這部分不在本次課程範圍。
kibana的啟動也很簡單，默認情況下直接執行kibana/bin目錄下的kibana二進制文件即可，它會默認連接本機的9200端口，這是ES的默認監聽端口。
要通過Kibana查詢數據的話：
第一步：先要告知Kibana我們期望查詢的Index是哪些。如第一張圖所示，通過Management頁面，配置一個Index pattern，來匹配我們要查詢的Index。Filebeat上傳的數據，會經過名為apachelog的pipeline，然後生成apachelog@開頭的Index，所以需要把index pattern指定為apache_log@*，這樣就能匹配到pipelien創建的index，如圖中藍色部分顯示。
第二步：需要選擇數據的時間字段，這裡指定為pipeline中定義的timestamp字段。
第三步可以在Discovery界面搜索數據了。可以在圖中紅色標註的文本框中輸入查詢條件。比如查詢response為403的apache日誌，只要輸入response:403即可。下面顯示的就是查詢到的相應的apache日誌，並且是結構化的數據，可以看到client ip/verb/request等信息都被解析出來了。
查詢的具體語法可以參考Kibana的官方文檔。
kibana數據可視化相關的界面主要是Visualize、Timelion和Dashboard。
因為數據可視化圖表是基於ES的聚合查詢來做的，需要對ES的聚合查詢有一定的理解。所以這裡以介紹功能為主，具體的創建方法需要理解ES的聚合查詢後，參考Kibana的官方文檔來配置。
Visualize界面主要用來創建單個圖表，比如第一張餅圖，可以看出apache的請求中，response code是200的請求佔總請求數的82.06%。還有第二章面積圖，可以看到apache每個時刻的數據吞吐量。
Timelion界面主要用來看同一個時間點，不同指標間的關係。圖中兩個圖表紅色豎線所在的位置是同一時刻，通過各個圖表的取值，可以看到相同時刻不同的指標間的關聯關係，便於定位分析。
Dashboard是儀表盤，可以將上面創建的各種圖表放置在同一個Dashboard頁面上，然後命名保存。這樣每次登錄Kibana可以直接通過Dashboard一目瞭然的看到各個圖表、各種指標。並且Dashboard可以生成url鏈接，方便共享給其他人；它也提供了iframe的鏈接，可以很方便的嵌入到其他系統的前臺頁面中。
至此本次課程的內容就介紹完了，最後分享下我們基礎架構部 ES團隊做的一些工作。我們主要基於Elasticsearch開發了兩款產品，一個是源生的Elasticsearch服務，一個是時序數據庫CTSDB。
非常感謝大家參加今天的課程，我們在騰訊雲+社區設置了Elasticsearch實驗室的專欄，定期對外發布相關文章的同時，也會交流相關問題，歡迎各位來訪，再次感謝大家！
閱讀更多 騰訊技術工程 的文章
