碼上快樂

相關內容    簡體    繁體

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

本文轉載自   查看原文   2017-03-25 01:41   3005 

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

ELK Stack 簡介

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

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

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

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

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

最簡單架構

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

圖 1. 最簡單架構

 

這種架構非常簡單，使用場景也有限。初學者可以搭建這個架構，了解 ELK 如何工作。

Logstash 作為日志搜集器

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

圖 2. Logstash 作為日志搜索器

 

這種結構因為需要在各個服務器上部署 Logstash，而它比較消耗 CPU 和內存資源，所以比較適合計算資源豐富的服務器，否則容易造成服務器性能下降，甚至可能導致無法正常工作。

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 正常啟動了。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
       {
           "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 上，然后作如下修改。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    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/6、URL 等。具體查看這里。除此之外，還有 grok 正則表達式的debug 工具，能方便快速檢驗所寫表達式是否正確。

下面是一個 grok 的配置實例，讀者可以適當修改滿足你的需求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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 所要讀取的日志信息。如下所示：

1
2
3
4
5
6
7
8
9
prospectors:
     -
       paths:
          - /home/WLPLog/*.log
       # 其他配置項，具體參考 Elastic 官網
     -
       paths:
          - /home/ApacheLog/*.log
       # 其他配置項，具體參考 Elastic 官網

問題：Filebeat 如何區分不同日志來源？

還是上題中提到的場景，Filebeat 雖然能讀取不同的日志目錄，但是在 Logstash 這邊，或者是 Elasticsearch 這邊，怎么區分不同 application server 的日志數據呢？

解決方案：Filebeat 的配置項 fields 可以實現不同日志來源的區分。用法如下：

1
2
3
4
5
6
7
8
9
10
11
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 與任意節點通信時都會先拿到集群信息，然后再決定應該給哪個節點發送數據輸出請求。

問題：如何在 Kibana 顯示日志數據？

解決方案：當數據存儲在 Elasticsearch 端之后就可以在 Kibana 上清楚的展示了。首先在瀏覽器上打開 Kibana 頁面。如果使用了 Nginx，就使用 Nginx 配置的 URL；否則就是http://yourhostname:5601。

創建日志索引。Logstash 發送的數據，默認使用 logstash 前綴作為數據索引。見圖 7。

圖 7. Kibana 創建索引頁面

 

點擊 Create，再選擇 Discover 頁面就能看見 Logstash 發送的數據了,如圖 8 所示。

圖 8. 數據展示頁面

 

Kibana 具體的使用，比如如何創建日志 visualization，如何將 visualization 添加到 dashboard，如何在 Kibana 上搜索日志，這些可以參考官網。

結束語

本文首先簡要介紹了 ELK 協議棧的幾種典型的架構及其使用場景，然后針對 Filebeat 的架構，詳細說明了如何安裝和配置。限於篇幅，同時由於某些基本配置，官網有詳盡的說明，所以本文只是選取了幾個比較重要，同時官網上說得不是很明確的地方作說明，希望對大家有幫助。

ELK 論壇上有不少內部人士熱心幫忙解答用戶的問題。如果讀者在使用過程中有不懂的，搜索了很久也找不到答案的問題，可以在 ELK 論壇尋求幫助。

參考資料

 

                        （--轉載--）


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 elk + filebeat，6.3.2版本簡單搭建，實現我們自己的集中式日志系統 理解OpenShift（6）：集中式日志處理 中小型研發團隊架構實踐七：集中式日志ELK 用elk+filebeat監控容器日志 Linux下Rsyslog日志遠程集中式管理 Centos7搭建集中式日志系統 ES 集中式日志分析平台 Elastic Stack（介紹） elk+filebeat ELK+Filebeat 搭建 基於docker部署使用ELK+FileBeat日志管理平台
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM