ELK+Filebeat 集中式日誌解決方案詳解

時間 2019-11-14

標籤 elk+filebeat elk filebeat 集中日誌解決方案詳解简体版

原文原文鏈接

連接：https://www.ibm.com/developerworks/cn/opensource/os-cn-elk-filebeat/index.html?ca=drs-html

ELK Stack 簡介

ELK 不是一款軟件，而是 Elasticsearch、Logstash 和 Kibana 三種軟件產品的首字母縮寫。這三者都是開源軟件，一般配合使用，並且又前後歸於 Elastic.co 公司名下，因此被簡稱爲 ELK Stack。根據 Google Trend 的信息顯示，ELK Stack 已經成爲目前最流行的集中式日誌解決方案。node

Elasticsearch：分佈式搜索和分析引擎，具備高可伸縮、高可靠和易管理等特色。基於 Apache Lucene 構建，能對大容量的數據進行接近實時的存儲、搜索和分析操做。一般被用做某些應用的基礎搜索引擎，使其具備複雜的搜索功能；
Logstash：數據收集引擎。它支持動態的從各類數據源蒐集數據，並對數據進行過濾、分析、豐富、統一格式等操做，而後存儲到用戶指定的位置；
Kibana：數據分析和可視化平臺。一般與 Elasticsearch 配合使用，對其中數據進行搜索、分析和以統計圖表的方式展現；
Filebeat：ELK 協議棧的新成員，一個輕量級開源日誌文件數據蒐集器，基於 Logstash-Forwarder 源代碼開發，是對它的替代。在須要採集日誌數據的 server 上安裝 Filebeat，並指定日誌目錄或日誌文件後，Filebeat 就能讀取數據，迅速發送到 Logstash 進行解析，亦或直接發送到 Elasticsearch 進行集中式存儲和分析。

若是您對 ELK Stack 還尚不瞭解，或是想了解更多，請點擊集中式日誌系統 ELK 協議棧詳解，查看具體介紹。nginx

ELK 經常使用架構及使用場景介紹

在這個章節中，咱們將介紹幾種經常使用架構及使用場景。git

最簡單架構

在這種架構中，只有一個 Logstash、Elasticsearch 和 Kibana 實例。Logstash 經過輸入插件從多種數據源（好比日誌文件、標準輸入 Stdin 等）獲取數據，再通過濾插件加工數據，而後經 Elasticsearch 輸出插件輸出到 Elasticsearch，經過 Kibana 展現。詳見圖 1。github

圖 1. 最簡單架構

這種架構很是簡單，使用場景也有限。初學者能夠搭建這個架構，瞭解 ELK 如何工做。正則表達式

Logstash 做爲日誌蒐集器

這種架構是對上面架構的擴展，把一個 Logstash 數據蒐集節點擴展到多個，分佈於多臺機器，將解析好的數據發送到 Elasticsearch server 進行存儲，最後在 Kibana 查詢、生成日誌報表等。詳見圖 2。docker

圖 2. Logstash 做爲日誌搜索器

這種結構由於須要在各個服務器上部署 Logstash，而它比較消耗 CPU 和內存資源，因此比較適合計算資源豐富的服務器，不然容易形成服務器性能降低，甚至可能致使沒法正常工做。vim

Beats 做爲日誌蒐集器

這種架構引入 Beats 做爲日誌蒐集器。目前 Beats 包括四種：數組

Packetbeat（蒐集網絡流量數據）；
Topbeat（蒐集系統、進程和文件系統級別的 CPU 和內存使用狀況等數據）；
Filebeat（蒐集文件數據）；
Winlogbeat（蒐集 Windows 事件日誌數據）。

Beats 將蒐集到的數據發送到 Logstash，經 Logstash 解析、過濾後，將其發送到 Elasticsearch 存儲，並由 Kibana 呈現給用戶。詳見圖 3。瀏覽器

圖 3. Beats 做爲日誌蒐集器

這種架構解決了 Logstash 在各服務器節點上佔用系統資源高的問題。相比 Logstash，Beats 所佔系統的 CPU 和內存幾乎能夠忽略不計。另外，Beats 和 Logstash 之間支持 SSL/TLS 加密傳輸，客戶端和服務器雙向認證，保證了通訊安全。

所以這種架構適合對數據安全性要求較高，同時各服務器性能比較敏感的場景。

引入消息隊列機制的架構

到筆者整理本文時，Beats 還不支持輸出到消息隊列，因此在消息隊列先後兩端只能是 Logstash 實例。這種架構使用 Logstash 從各個數據源蒐集數據，而後經消息隊列輸出插件輸出到消息隊列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常見消息隊列。而後 Logstash 經過消息隊列輸入插件從隊列中獲取數據，分析過濾後經輸出插件發送到 Elasticsearch，最後經過 Kibana 展現。詳見圖 4。

圖 4. 引入消息隊列機制的架構

這種架構適合於日誌規模比較龐大的狀況。但因爲 Logstash 日誌解析節點和 Elasticsearch 的負荷比較重，可將他們配置爲集羣模式，以分擔負荷。引入消息隊列，均衡了網絡傳輸，從而下降了網絡閉塞，尤爲是丟失數據的可能性，但依然存在 Logstash 佔用系統資源過多的問題。

基於 Filebeat 架構的配置部署詳解

前面提到 Filebeat 已經徹底替代了 Logstash-Forwarder 成爲新一代的日誌採集器，同時鑑於它輕量、安全等特色，愈來愈多人開始使用它。這個章節將詳細講解如何部署基於 Filebeat 的 ELK 集中式日誌解決方案，具體架構見圖 5。

圖 5. 基於 Filebeat 的 ELK 集羣架構

由於免費的 ELK 沒有任何安全機制，因此這裏使用了 Nginx 做反向代理，避免用戶直接訪問 Kibana 服務器。加上配置 Nginx 實現簡單的用戶認證，必定程度上提升安全性。另外，Nginx 自己具備負載均衡的做用，可以提升系統訪問性能。

系統信息

平臺

筆者試驗平臺爲 RHEL 6.x。注意，目前 ELK（包括 Beats）不支持 AIX。具體對平臺的支持請查看這裏。

JDK

JDK 是 IBM Java 8。ELK 須要 Oracle 1.7(或者是 OpenJDK 1.7) 及以上，若是是 IBM Java，則須要 8 及以上的版本。具體信息。

瀏覽器

Kibana 4.x 不支持 IE9 及如下；Kibana 3.1 雖然支持 IE9，可是不支持 Safari(iOS)和 Chrome(Android)。具體對瀏覽器的支持，請看這裏。

軟件版本

Filebeat：1.2.3；
Logstash：2.3.4；
Elasticsearch：2.3.4；
Kibana：4.5.4；
Nginx：1.8.1。

Filebeat + ELK 安裝

安裝步驟

ELK 官網對於每種軟件提供了多種格式的安裝包（zip/tar/rpm/DEB），以 Linux 系列系統爲例，若是直接下載 RPM，能夠經過 rpm -ivh path_of_your_rpm_file 直接安裝成系統 service。之後就可使用 service 命令啓停。好比 service elasticsearch start/stop/status。很簡單，但缺點也很明顯，就是不能自定義安裝目錄，相關文件放置比較分散。

實際使用中更經常使用是使用 tar 包安裝。每種軟件產品的安裝過程很是類似，因此下面僅以 Elasticsearch 爲例簡述安裝過程。

建立 elk 用戶和用戶組；

 
           groupadd elk          # 添加用戶組 
          
           useradd -g elk elk    # 添加用戶到指定用戶組 
          
           passwd elk            # 爲指定用戶設置密碼

切換到新建立的 elk 用戶作以下操做。

下載安裝包；

若是待安裝機器能訪問外網，能夠直接用如下命令下載安裝包。

 
           wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/2.3.4/elasticsearch-2.3.4.tar.gz

不然下載好後用 ftp 客戶端等工具把包傳過去。

解壓到指定目錄；

tar xzvf elasticsearch-2.3.4.tar.gz -C /opt

這時就能在/opt 下看到剛纔解壓出來的 elasticsearch-2.3.4 文件夾。
運行；

./Path_of_elasticsearch/bin/elasticsearch

驗證是否啓動；

curl 'http://localhost:9200'

若是看到以下相似信息，就說明 Elasticsearch 正常啓動了。

 
           { 
          
           "name" : "node-235", 
          
           "cluster_name" : "elasticsearch_cms", 
          
           "version" : { 
          
           "number" : "2.3.4", 
          
           "build_hash" : "e455fd0c13dceca8dbbdbb1665d068ae55dabe3f", 
          
           "build_timestamp" : "2016-06-30T11:24:31Z", 
          
           "build_snapshot" : false, 
          
           "lucene_version" : "5.5.0" 
          
           }, 
          
           "tagline" : "You Know, for Search" 
          
           }

配置 Elasticsearch service；
上面的運行命令是在前臺啓動 Elasticsearch。實際使用中更可能是在後臺運行，或者是把 Elasticsearch 配置成 service。

Github 上有以 service 形式運行 Elasticsearch 的腳本，下載後放到/etc/init.d 目錄下，而後用 vim 打開，根據實際狀況修改好比用戶名、log 路徑、數據保存路徑等信息。圖 6 是筆者試驗用的變量值。

圖 6. Elasticsearch service 腳本中的變量定義
以 service 形式啓/停/查看狀態；

service elasticsearch start/stop/status

以上就是如何以 service 形式安裝 Elasticsearch，對於 Filebeat、Logstash 和 Kibana 還有 Nginx 都能以相同方式安裝，這裏就不贅述。

Filebeat + ELK 配置

Filebeat 和 ELK 的安裝很簡單，比較難的是如何根據需求進行配置。這個章節選取了幾個比較典型且重要的配置需求和配置方法。

Filebeat 與 Logstash 安全通訊

用戶可使用 TLS 雙向認證加密 Filebeat 和 Logstash 的鏈接，保證 Filebeat 只向可信的 Logstash 發送加密的數據。一樣的，Logstash 也只接收可信的 Filebeat 發送的數據。

這個功能默認是關閉的。可經過以下步驟在配置文件中打開：

生成 Filebeat 自簽名證書和 key 文件

由於試驗用，因此這裏使用的都是自簽名證書。如何使用 openssl 生成自簽名證書，網上有不少教程，Elastic github 上也直接提供了參考指令。

 
           openssl req -subj '/CN=hostname/' -x509 -days $((100*365)) -batch -nodes -newkeys rsa:2048 -keyout ./pki/tlk/provate/filebeat.key -out ./pki/tls/certs/filebeat.crt

這條指令生成自簽名證書和 key 文件。讀者須要把 hostname 部分改爲實際環境的 hostname，或者是 IP 地址。

生成 Logstash 自簽名證書和 key 文件
命令相似。

Filebeat 配置

首先把 Logstash 的自簽名證書傳送到 Filebeat 所在服務器。而後，對 logstash output 部分的 tls 配置做以下修改：

 
           tls: 
          
           ## logstash server 的自簽名證書。 
          
           certificate_authorities: ["/etc/pki/tls/certs/logstash.crt"] 
          
           certificate: "/etc/pki/tls/certs/filebeat.crt" 
          
           certificate_key: "/etc/pki/tls/private/filebeat.key"

其中：

certificate_authorities：CA 證書，即用來簽署證書的證書。這裏表示配置 Filebeat 使其信任全部由該 CA 證書發行的證書。由於自簽名證書的發行者和證書主體相同，因此這裏直接使用 Logstash 證書使 Filebeat 信任使用該證書的 Logstash server；
certificate & certificate_key：Filebeat 證書和 key 文件。Filebeat 將使用它們向 Logstash server 證實本身的可信身份。

Logstash 配置

同 Filebeat 配置相似，首先把 Filebeat client 上的證書複製到 Logstash server 上，而後做以下修改。

 
           input { 
          
           beats { 
          
           port => 5044 
          
           ssl => true 
          
           ssl_certificate_authorities => ["/etc/pki/tls/certs/filebeat.crt"] 
          
           ssl_certificate => "/etc/pki/tls/certs/logstash.crt" 
          
           ssl_key => "/etc/pki/tls/private/logstash.key" 
          
           ssl_verify_mode => "force_peer" 
          
           } 
          
           }

其中：

ssl：true 表示開啓 Logstash 的 SSL/TLS 安全通訊功能；
ssl_certificate_authorities：配置 Logstash 使其信任全部由該 CA 證書發行的證書；
ssl_certificate & ssl_key：Logstash server 證書和 key 文件。Logstash 使用它們向 Filebeat client 證實本身的可信身份；
ssl_verify_mode：代表 Logstash server 是否驗證 Filebeat client 證書。有效值有 peer 或 force_peer。若是是 force_peer，表示若是 Filebeat 沒有提供證書，Logstash server 就會關閉鏈接。

Filebeat 實現 log rotation

通俗的說，log rotation 是指當日志文件達到指定大小後，把隨後的日誌寫到新的日誌文件中，原來的日誌文件重命名，加上日誌的起止時間，以實現日誌歸檔的目的。

Filebeat 默認支持 log rotation，但須要注意的是，Filebeat 不支持使用 NAS 或掛載磁盤保存日誌的狀況。由於在 Linux 系列的操做系統中，Filebeat 使用文件的 inode 信息判斷當前文件是新文件仍是舊文件。若是是 NAS 或掛載盤，同一個文件的 inode 信息會變化，致使 Filebeat 沒法完整讀取 log。

雖然 Filebeat 默認支持 log rotation，可是有三個參數的設置須要留意。

registry_file：這個文件記錄了當前打開的全部 log 文件，以及每一個文件的 inode、當前讀取位置等信息。當 Filebeat 拿到一個 log 文件，首先查找 registry_file，若是是舊文件，就從記錄的當前讀取位置處開始讀取；若是是新文件，則從開始位置讀取；
close_older：若是某個日誌文件通過 close_older 時間後沒有修改操做，Filebeat 就關閉該文件的 handler。若是該值過長，則隨着時間推移，Filebeat 打開的文件數量不少，耗費系統內存；
scan_frequency：Filebeat 每隔 scan_frequency 時間讀取一次文件內容。對於關閉的文件，若是後續有更新，則通過 scan_frequency 時間後，Filebeat 將從新打開該文件，讀取新增長的內容。

Elasticsearch 集羣

Elasticsearch 啓動時會根據配置文件中設置的集羣名字（cluster.name）自動查找並加入集羣。Elasctisearch 節點默認使用 9300 端口尋找集羣，因此必須開啓這個端口。

一個 Elasticsearch 集羣中通常擁有三種角色的節點，master、data 和 client。

master：master 節點負責一些輕量級的集羣操做，好比建立、刪除數據索引、跟蹤記錄集羣中節點的狀態、決定數據分片（shards）在 data 節點之間的分佈；
data：data 節點上保存了數據分片。它負責數據相關操做，好比分片的 CRUD，以及搜索和整合操做。這些操做都比較消耗 CPU、內存和 I/O 資源；
client：client 節點起到路由請求的做用，實際上能夠看作負載均衡器。

配置文件中有兩個與集羣相關的配置：

node.master：默認 true。True 表示該節點是 master 節點；
node.data：默認 true。True 表示該節點時 data 節點。若是兩個值都爲 false，表示是 client 節點。

一個集羣中不必定有 client 節點，可是確定有 master 和 data 節點。默認第一個啓動的節點是 master。Master 節點也能起到路由請求和搜索結果整合的做用，因此在小規模的集羣中，無需 client 節點。可是若是集羣規模很大，則有必要設置專門的 client。

Logstash 使用 grok 過濾

日誌數據通常都是非結構化數據，並且包含不少沒必要要的信息，因此須要在 Logstash 中添加過濾插件對 Filebeat 發送的數據進行結構化處理。

使用 grok 正則匹配把那些看似毫無心義、非結構化的日誌數據解析成可查詢的結構化數據，是目前 Logstash 解析過濾的最好方式。

Grok 的用戶不須要從頭開始寫正則。ELK github 上已經寫好了不少有用的模式，好比日期、郵箱地址、IP4/六、URL 等。具體查看這裏。除此以外，還有 grok 正則表達式的debug 工具，能方便快速檢驗所寫表達式是否正確。

下面是一個 grok 的配置實例，讀者能夠適當修改知足你的需求。

 
         filter { 
        
         grok { 
        
         match => { 
        
         "message" => [ 
        
         "\[(?< 
         Logtime 
         >(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+(?< 
         LogSource 
         >([\w|\S]+))\s+%{WORD:LogLevel}\s+(?< 
         LogStr 
         >[\w|\W]*)", 
        
         "\[(?< 
         Logtime 
         >(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+%{WORD:LogLevel}\s+(?< 
         LogStr 
         >[\w|\W]*(\\n)+)" 
        
         ] 
        
         } 
        
         remove_field => ["message"] 
        
         } 
        
         if "_grokparsefailure" in [tags] { 
        
         grok { 
        
         match => ["message", "(?< 
         LogStr 
         >[\w|\W]+)"] 
        
         remove_field => ["message"] 
        
         remove_tag => ["_grokparsefailure"] 
        
         add_field => { 
        
         LogSource => "-" 
        
         LogLevel => "-" 
        
         LogTime => "-" 
        
         } 
        
         }   
        
         } 
        
         }

第一個 grok 列了兩種正則表達式，若是第一種不匹配，則自動使用第二種。若是第二種也沒有匹配，則匹配失敗，log 數據中添加一個"_grokparsefailure"域，代表 grok 匹配失敗了。讀者可根據實際需求決定如何處理匹配失敗的數據。這裏，對於匹配失敗的，將再匹配一次，並給沒有匹配上的域賦予默認值"-"，這樣使得日誌數據格式統一，都含有 4 個域：Logtime、LogSource、LogLevel、LogTime，便於後續數據搜索和展現。

配置 Nginx 實現用戶認證

關於這部分配置的教程不少，這裏就不贅述了。

遇到的典型問題

問題：Filebeat 如何讀取多個日誌目錄？

若是 Filebeat 所在 server 上運行有多個 application servers，各自有不一樣的日誌目錄，那 Filebeat 如何同時讀取多個目錄，這是一個很是典型的問題。

解決方案：經過配置多個 prospector 就能達到要求。在配置文件的 prospectors 下，每一個"-"表示一個 prospector，每一個 prospector 包含一些配置項，指明這個 prospector 所要讀取的日誌信息。以下所示：

 
         prospectors: 
        
         - 
        
         paths: 
        
         - /home/WLPLog/*.log 
        
         # 其餘配置項，具體參考 Elastic 官網 
        
         - 
        
         paths: 
        
         - /home/ApacheLog/*.log 
        
         # 其餘配置項，具體參考 Elastic 官網

問題：Filebeat 如何區分不一樣日誌來源？

仍是上題中提到的場景，Filebeat 雖然能讀取不一樣的日誌目錄，可是在 Logstash 這邊，或者是 Elasticsearch 這邊，怎麼區分不一樣 application server 的日誌數據呢？

解決方案：Filebeat 的配置項 fields 能夠實現不一樣日誌來源的區分。用法以下：

 
         prospectors: 
        
         - 
        
         paths: 
        
         - /home/WLPLog/*.log 
        
         fields: 
        
         log_source: WLP 
        
         - 
        
         paths: 
        
         - /home/ApacheLog/*.log 
        
         fields: 
        
         log_source: Apache

在 fields 配置項中，用戶能夠自定義域來標識不一樣的 log。好比上例中的"log_source"就是筆者自定義的。如此，從 Filebeat 輸出的 log 就有一個叫作 log_source 的域代表該 log 的實際來源。

問題：如何配置 Logstash 與 Elasticsearch 集羣通訊？

咱們知道 Logstash 使用 Elasticsearch 輸出插件就能把數據發送到 Elasticsearch 進行存儲和搜索。Elasticsearch 插件中有個 hosts 配置項說明 Elasticsearch 信息。可是假如是一個 Elasticsearch 集羣，應該怎麼配置 hosts？

解決方案：最簡單的作法是把集羣中全部的 Elasticsearch 節點的 IP 或者是 hostname 信息都在 hosts 中配上（它支持數組）。可是若是集羣比較大，或者是集羣節點變更頻繁的話，還須要維護這個 hosts 值，不太方便。比較推薦的作法是隻配集羣中某個節點的信息，能夠是 client 節點，也能夠是 master 節點或者是 data 節點。由於無論是哪一個節點，都知道該它所在集羣的信息（集羣規模，各節點角色）。這樣，Logstash 與任意節點通訊時都會先拿到集羣信息，而後再決定應該給哪一個節點發送數據輸出請求。