基于開源技術棧搭建高可用日志平臺

elastic stack開源技術棧介紹

elastic stack棧涉及到以下幾個組件

• beats：用于輕量級日志采集，支持文件采集，系統數據采集，特定中間件數據采集等
• logstash：用于日志結構化，標簽化，支持DSL方式將數據進行結構化
• elasticsearch：用于提供日志相關的索引，使得日志能夠有效的檢索
• kibana：用于提供日志檢索，特定metric展示的面板，方便使用的UI
• x-pack：用于監控與預警相關的組件，可以集成到es中，kibana有特定的面板用于展示UI
• curator：用于管理ES集群的索引相關的數據，對索引進行分析

使用elastic stack進行日志平臺架構如下圖所示：

從以上日志數據的流向可以看到掌閱的應用日志數據有三種流向，下面分別說明：

• beats->es->kibana 該場景適用于數據量比較寫，而且數據不需要太多轉換的場景
• beats->logstash->es->kibana 該場景適用于數據量不大，但是數據需要進一步分析和轉換后才能入ES集群的場景
• beats->queue->logstash->es->kibana 該場景適用于大規模日志數據，并且日志數據需要批量分析過濾結構化的場景

beats采集數據

beats是elasticstack的一員，屬于一種輕量級的日志采集組件，使用go語言開發，沒有依賴，可以簡化部署和運維操作，使用yaml格式的配置文件來采集日志或者系統信息，目前beats支持的事件采集包括：網絡數據，日志文件，mysql，system，mongodb，kafka，nginx，redis，zookeeper，haproxy等

beats提供了一個易于開發和擴展的框架用于擴展相關的監控指標的采集來滿足各種不同的指標采集需求，logstash提供了對beats數據采集的接入接口，因此只需要使用beats工具進行數據采集，然后將數據推到logstash集群即可；另外beats的數據還支持直接寫入es，這種場景適合不需要針對性的對數據做結構化的場景。

目前beats支持以下幾種：

• filebeat：用于采集文件數據
• metrcbeat：用于采集各種系統數據
• packetbeat：用于采集網絡數據
• winlogbeat：用于采集Windows系統數據
• heartbeat：用于采集心跳數據

beats使用指南

beats是基于libbeat框架進行開發的專門用于采集數據的一個組件。

開源的beats組件列表：https://www./guide/en/beats/libbeat/5.2/community-beats.html

Beats 平臺是 Elastic.co 從 packetbeat 發展出來的數據收集器系統，統一基于go進行開發和擴展。beat 收集器可以直接寫入 Elasticsearch，也可以傳輸給 Logstash。其中抽象出來的 libbeat，提供了統一的數據發送方法，輸入配置解析，日志記錄框架等功能。也就是說，所有的 beat 工具，在配置上，除了 input 以外，在output、filter、shipper、logging、run-options 上的配置規則都是完全一致的，下圖是Filebeats的架構設計

上圖的filebeat是最常見的一個日志采集工具，主要用來采集文件日志，filebeat的工作原理如下：

• 日志采集器（harvesters）：用來從日志文件讀取內容
• 日志勘察器（propectors）：用來管理所有的harvesters和發現日志源進行讀取，目前支持stdin和日志文件讀取日志，日志勘察器會發現所有定義在配置文件路徑中的日志文件，并針對每個日志文件啟動一個日志采集器進行采集，每個勘察器都會運行在自己的goroutine中。
• spooler：每個日志采集器采集完成后將日志數據發送給spooler，spooler用來匯集和聚合數據并根據配置文件的輸出進行發送出去。
• registry：啟動filebeat后會在數據目錄產生一個registry文件用來記錄采集日志事件的狀態以確保所有的日志均至少發送一次，不丟失。另外registry還有以下幾個功能：首先，確保filebeat重啟后日志數據不重復讀取，因為registry會記錄每個文件讀取的位置，當服務重啟時從記錄的位置開始執行；其次，如果后端的Elasticsearch或者logstash不可用，filebeats會記錄到最后一次發送的行到registry中，當后端可用時重新開始發送。

注意：因為registry文件記錄了每個文件的狀態并且持久化到了磁盤，如果有大量的文件的話，registry文件可能會變的很大，為了減少registry文件的大小，建議開啟clean_removed和clean_inactive兩個配置項。

安裝和使用filebeat

因為filebeat為go語言開發，語言特性決定了filebeat的安裝和使用將會特別方便，首先去官方下載對應版本的壓縮包，然后解壓到指定路徑即可。

當我們安裝完filebeat之后，我們可以在filebeat的安裝目錄下看到兩個文件

• filebeat.template.json （輸出的文件格式，在filebeat的template中指定，當服務啟動時，會被加載）
• filebeat.yml（所有的配置都在該文件下進行）

使用yaml配置beats

1，配置文件名稱filebeat.yml，格式yaml格式。

2，filebeat日志勘探器prospector配置項說明

• 輸入類型配置：input_type，控制從文件輸入還是stdin輸入
• 日志路徑配置：paths，可以配置多個路徑，支持正則匹配
• 文檔類型：document_type，可以設置特殊的文檔類型進行采集
• 過濾：excluede_lines和include_lines，可以控制是否包含或者不采集某些日志
• 標簽：tags，給日志打上tag后方便kibana過濾搜索
• 字段：fields，可以用key/value的方式定義一些特殊的字段給日志文件，方便過濾和篩選
• 采集開始時間：ignore_older，是否從當前時間開始采集，可以設置類似2h,5minutes等，默認為0
• close_*相關配置：針對文件重命名，移除，文件是否有持續寫入等條件對監聽文件句柄的一些特殊操作
• clean_*相關配置：對監聽文件的一些清理操作
• 掃描文件周期：scan_frequency 掃描日志文件的周期，默認10s，可以調大到60s
• 掃描文件的位置：tail_files，如果設置則從文件尾部開始tail，否則從文件頭開始
• backoff：Filebeat檢測到某個文件到了EOF之后，每次等待多久再去檢測文件是否有更新，默認為1s。
• max_backoff：Filebeat檢測到某個文件到了EOF之后，等待檢測文件更新的最大時間，默認是10秒。
• backoff_factor：定義到達max_backoff的速度，默認因子是2，到達max_backoff后，變成每次等待max_backoff那么長的時間才backoff一次，直到文件有更新才會重置為backoff。比如：如果設置成1，意味著去使能了退避算法，每隔backoff那么長的時間退避一次。

• spool_size:spooler的大小，spooler中的事件數量超過這個閾值的時候會清空發送出去（不論是否到達超時時間）。
• idle_timeout:spooler的超時時間，如果到了超時時間，spooler也會清空發送出去（不論是否到達容量的閾值）。
• registry_file:記錄filebeat處理日志文件的位置的文件
• config_dir:如果要在本配置文件中引入其他位置的配置文件，可以寫在這里（需要寫完整路徑），但是只處理prospector的部分。
• publish_async：是否采用異步發送模式（實驗功能）。
• 配置舉例

3，輸出相關的配置：output

• 輸出到elasticsearch：output.elasticsearch，以下配置會自動裝載es的索引模板

安裝filebeats的時候會在相應得目錄下有一份filebeat.template.json的文件，該文件用于高速Elasticsearch集群如何處理filebeat采集的日志，可以用以下命令手動裝載該模板：

如果要刪除該模板，執行：

• 輸出到logstash：output.logstash

• 輸出到kafka：output.kafka

• 輸出到redis：output.redis

• 輸出到文件：output.file

• 輸出到終端：output.console

4，完成配置后需要檢查配置的可用性

編寫完成filebeats相關的配置后執行如下命令檢查配置是否正確

5，啟動beats

使用本地文件為輸入源，console為輸出進行debug測試啟動

• 配置文件

• 啟動命令

線上啟動可以用nohup或者supervisord進行管理。

6，使用beats組件需要測試和了解的幾項指標

• filebeats采集數據的速率每秒支持1w行級別日志采集，如何優化配置還可以更高。
• 采集數據對系統資源的占用，小數據量幾乎不耗（需要大數據量進一步驗證）如果配置scan_相關的參數間隔時間短會導致消耗CPU。
• mem：小數據量幾乎不耗（需要大數據量進一步驗證）相對于flume來說可以忽略。
• 采集數據時新增文件，刪除文件，變更文件采集方式，對于日志文件變更，重命名，刪除，新增等常見場景filebeat都有處理，filebeat會定期掃描配置的日志路徑去發現新增的日志，當日志被移除會通過close_removed相關的配置邏輯進行執行操作，默認移除日志后自動關閉句柄。當日志發生重命名操作也會觸發close_removed操作進行舊日志移除和關閉，然后重新掃描到新名字日志加入監聽。
• 采集數據時如果接收數據的集群異常是否能夠正確處理，如果接收數據服務不可用或者阻塞filebeat會監聽到并停止數據發送，然后以30s的間隔進行探測，當探測到后端可用后重新開始數據發送。
• filebeat異常退出或者重啟是否影響日志采集，如果filebeat退出或者重啟對日志采集不會有影響，filebeat內部會記錄每個日志采集到什么位置的文件registry到磁盤，每次重啟的時候會從該文件讀取一下上次采集到什么位置，然后基于上次記錄的位置開始采集。
• filebeat配置多個ouput服務時是如何選擇服務的，當配置多個接收端時，采取隨機選擇策略。

安裝和使用logstash

1，logstash安裝

安裝Java環境，要求Jdk版本大于1.8。

安裝logstash

解壓到指定路徑

測試logstash是否安裝成功

2，logstash配置文件講解

logstash的配置文件是一種DSL的配置方式，主要包括三部分：

• input：配置日志輸入源
• filter：配置對日志的過濾清洗規則
• output：將日志輸出到指定服務

配置文件舉例：

3，啟動logstash進行測試

常規啟動方式：

推薦使用supervisord進行管理啟動，啟動腳本supervisord.conf配置舉例：

4，logstash的工作原理

在logstash中有輸入，過濾，輸出即：input，filter，output三種配置，這三種功能在logstash中是通過不同的線程進行處理，通過top命令然后H可以查看logstash的各個線程的工作情況

logstash處理的數據在線程之間以event形式傳遞，在過濾的過程中可以給event添加或者刪除修改event的tag，每個filter插件都會提供add_tag,remove_tag,add_field和remove_field四個方法。

logstash默認基于內存的隊列在管道間進行事件傳遞，如果logstash異常終止緩存在內存的事件將會被丟失，為了避免logstash異常終止導致的事件丟失，可以考慮使用持久化隊列來處理事件。跟持久化隊列相關的配置項有以下幾個：

• queue.type：設置為persisted使之有持久化能力，默認是memory
• path.queue：持久化隊列存放的位置
• queue.page_capacity：持久化隊列最大隊列頁，默認250mb，該項理論不會對性能產生影響。
• queue.max_events：允許的最大事件數，默認為0，不限制
• queue.max_bytes：隊列的容量，默認1G

當使用了持久化隊列的配置后，有一種場景也可能發生就是隊列分配的資源使用完了，這時候logstash為了避免后端ES過載采取的措施是不再接受新事件輸入。這個時候如果往logstash寫入數據的是beats組件時，beats會停止往logstash寫入數據，直到logstash隊列被消費后才繼續寫入。

5，logstash事件生命周期

logstash的事件會經歷inputs=>filters=>outputs這樣的管道完成一個事件的生命周期，我們針對事件的完整生命周期來分別講解每個階段的工作內容。

5.1 inputs

可以作為輸入源的類型有以下幾種

• file：文件
• syslog：通用的syslog日志，簡單的syslog架構如下圖所示

• redis：從redis中接收日志
• beats：通過filebeat接收日志

5.2 filters

filters階段是對event的加工處理，每個事件在該階段都是運行在一個獨立的線程中，并將讀取到event寫入到Java的一個同步隊列SynchronousQueue，該隊列會將數據發送給當前空閑的worker去處理，如果所有的worker都是busy狀態就會阻塞。worker線程數可以通過配置文件進行設置，優化logstash的執行性能可以參考Tuning and Profiling logstash Performance

默認情況下logstash在各個管道（pipeline）間通過內存隊列做緩沖進行事件傳遞

常用的filters有以下幾種

• grok：解析并結構化文本，將非結構化數據轉換為結構化數據常用的filter，有120多個匹配模式可以使用
• mutate：對event進行調整，增刪修改某個event的field
• drop：可以丟棄掉某個event，比如debug級別
• clone：生成一個event的拷貝
• geoip：添加IP地理位置相關的數據到event

5.3 outputs

event最后的處理階段，該階段將event事件輸出到指定的服務中，當前支持的輸出服務有以下幾個

• elasticsearch：發送數據到elasticsearch
• file：發送數據到文件
• graphite：發送事件到graphite
• statsd：發送事件到statsd

5.4 Codec

可以用于input或者output中。codecs可以簡化某些event的序列化操作，比較流行的codec有以下幾個

• json：增加對json數據序列化、反序列化支持
• multiline：對多行數據支持比如stacktrace消息

6，logstash插件架構

基于以上架構可以擴展和豐富logstash日志插件。不再贅述，如果當前插件不能滿足業務需求的時候可以考慮進行開發和擴展。以下是官方的插件列表舉例：

7，使用filebeat做為文件輸入源進行簡單配置舉例

8，logstash性能調優

logstash默認會選擇最佳的性能方案，當默認配置不能滿足需求的時候可以對影響性能的幾個參數進行調整，涉及到性能相關的參數有以下幾個：

• pipeline.workers
• pipeline.batch.size
• pipeline.batch.delay

9，logstash測試指標

• logstash每秒可以處理的數據量
• logstash服務重啟是否丟失事件
• logstash集群化如何和filebeat進行集成

使用隊列做數據緩沖

由于數據寫入太快logstash或者ES集群性能有問題會導致數據寫入失敗，因此常規的架構上一般在輸入數據層都會使用一個隊列系統做緩沖區進行緩沖，常見的做為日志平臺的數據緩沖的隊列系統有以下幾種：

• kafka
• redis
• rabitmq

幾種隊列做一個簡單的對比：

1. 是否需要保證日志數據不丟失持久化（kafka）
2. 是否需要高性能（redis，kafka）
3. 是否需要支持分布式擴展（kafka，rabbitmq）
4. 運維友好性（redis）
5. 開發友好性（redis）
6. 完整的隊列特性（kafka，rabbitmq）

引入隊列中間件的好處：

• 增加緩沖區，是的ES寫入可控，logstash的接收可控
• 增加高可用，日志數據寫入到隊列集群中時logstash的升級和回滾操作不會導致數據丟失

從以上對比分析可以無論選擇什么隊列做中間件，只要自己能夠hold住整體架構即可，每個中間件自身都各有千秋。接下來我們以kafka為隊列中間件做分析和舉例：

1，kafka架構及原理講解

kafka通過zookeeper集群保證服務的高可用，kafka自身又包括生產者和消費者，生產者和消費者的連接的橋梁是broker。

生產者將數據轉發到自己感興趣的topic中，每個topic在kafka上又支持劃分多個分區，通過分區的方式來解決負載均衡問題。多個消費者可以訂閱自己感興趣的topic，

從上圖可以看出生產者是推送數據給kafka，消費者是從kafka拉取數據。

2，kafka集群搭建

從以上原理圖大家大概能知道kafka集群的搭建首先需要搭建zookeeper集群，搭建完zookeeper集群后需要根據日志平臺進行評估kafka集群的規模，設計kakfa服務器的磁盤分區以及配置項，由于篇幅有限，本文不再單獨講解kafka如何搭建。有興趣的讀者可以參考：http:///2017/09/04/kafka-best-pratice/

存儲集群ElasticSearch講解

elasticsearch是基于luncene的一個分布式搜索服務，支持在線擴容，海量數據存儲，高性能倒排列表，模糊搜索等高級特性，為了方便大家理解我拿ES和普通的關系數據庫進行對比如下：

使用es2unix工具可以在命令行上操作es

可以用paramedic插件監控ES集群的狀態，使用head插件可以查看ES索引的狀態，具體如何安裝插件和擴展請大家參考插件官方網站即可，不再贅述。

1，單機搭建ES集群講解

下載elasticsearch指定版本，注意ES官方目前已經升級到6.0以上版本，建議基于最新穩定版本搭建。

ES安裝比較簡單，從官方下載指定的壓縮包，然后解壓到指定路徑即可。

2，單機模式ES服務啟動

用于測試ES服務的接口和API等相關特性，搭建一個節點的單機版本進行測試

啟動ES集群前需要先設置ES啟動時依賴的一些系統參數：

• 查看ulimit -Hn 如果值小于65535則需要進行調整，編輯/etc/security/limits.conf將 soft和hard相關的配置參數調整到一個大于65535的值
• 配置jvm.options將其堆的大小調整到一個合適的值，默認為2g，如果是測試環境可以調為512m
• 查看系統中max_map_count，先查看sysctl -a|grep vm.max_map_count 如果小于65535則將其調大，可以設置為262144，用sysctl -w vm.max_map_count=262144寫入即可，若要永久生效編輯/etc/sysctl.conf將vm.max_map_count=262144即可。

啟動命令：

3，集群模式搭建

由于不同規模，不同配置的硬件對集群搭建要求不一樣，建議大家基于自身服務器條件進行定制化搭建，不再贅述。

4，curator管理elasticsearch的索引

curator是python開發的一個工具，專門用來管理es集群相關的索引，通過該工具的api可以對es集群的索引進行單獨管理，包括查看，修改，刪除，副本，restore，snapshot等。

總結

以上就是一個簡單的日志平臺涉及到的關鍵組件的講解和對應組件的原理分析。下面一個章節我們會將docker和這些組件的適配進行講解。敬請大家期待。