Filebeat安裝部署

一、簡單概述

　　最近在了解ELK做日志采集相關的內容，這篇文章主要講解通過filebeat來實現日志的收集。日志采集的工具有很多種，如fluentd, flume, logstash,betas等等。首先要知道為什么要使用filebeat呢？因為logstash是jvm跑的，資源消耗比較大，啟動一個logstash就需要消耗500M左右的內存，而filebeat只需要10來M內存資源。常用的ELK日志采集方案中，大部分的做法就是將所有節點的日志內容通過filebeat送到kafka消息隊列，然后使用logstash集群讀取消息隊列內容，根據配置文件進行過濾。然后將過濾之后的文件輸送到elasticsearch中，通過kibana去展示。

filebeat介紹

　　Filebeat由兩個主要組成部分組成：prospector和 harvesters。這些組件一起工作來讀取文件並將事件數據發送到您指定的output。

什么是harvesters？
　　harvesters負責讀取單個文件的內容。harvesters逐行讀取每個文件，並將內容發送到output中。每個文件都將啟動一個harvesters。harvesters負責文件的打開和關閉，這意味着harvesters運行時，文件會保持打開狀態。如果在收集過程中，即使刪除了這個文件或者是對文件進行重命名，Filebeat依然會繼續對這個文件進行讀取，這時候將會一直占用着文件所對應的磁盤空間，直到Harvester關閉。默認情況下，Filebeat會一直保持文件的開啟狀態，直到超過配置的close_inactive參數，Filebeat才會把Harvester關閉。

關閉Harvesters會帶來的影響：
　　file Handler將會被關閉，如果在Harvester關閉之前，讀取的文件已經被刪除或者重命名，這時候會釋放之前被占用的磁盤資源。
　　當時間到達配置的scanfrequency參數，將會重新啟動為文件內容的收集。
　　如果在Havester關閉以后，移動或者刪除了文件，Havester再次啟動時，將會無法收集文件數據。
　　當需要關閉Harvester的時候，可以通過close*配置項來控制。

什么是Prospector？

　　Prospector負責管理Harvsters，並且找到所有需要進行讀取的數據源。如果input type配置的是log類型，Prospector將會去配置度路徑下查找所有能匹配上的文件，然后為每一個文件創建一個Harvster。每個Prospector都運行在自己的Go routine里。

　　Filebeat目前支持兩種Prospector類型：log和stdin。每個Prospector類型可以在配置文件定義多個。log Prospector將會檢查每一個文件是否需要啟動Harvster，啟動的Harvster是否還在運行，或者是該文件是否被忽略（可以通過配置 ignore_order，進行文件忽略）。如果是在Filebeat運行過程中新創建的文件，只要在Harvster關閉后，文件大小發生了變化，新文件才會被Prospector選擇到。

filebeat工作原理

　　Filebeat可以保持每個文件的狀態，並且頻繁地把文件狀態從注冊表里更新到磁盤。這里所說的文件狀態是用來記錄上一次Harvster讀取文件時讀取到的位置，以保證能把全部的日志數據都讀取出來，然后發送給output。如果在某一時刻，作為output的ElasticSearch或者Logstash變成了不可用，Filebeat將會把最后的文件讀取位置保存下來，直到output重新可用的時候，快速地恢復文件數據的讀取。在Filebaet運行過程中，每個Prospector的狀態信息都會保存在內存里。如果Filebeat出行了重啟，完成重啟之后，會從注冊表文件里恢復重啟之前的狀態信息，讓FIlebeat繼續從之前已知的位置開始進行數據讀取。
Prospector會為每一個找到的文件保持狀態信息。因為文件可以進行重命名或者是更改路徑，所以文件名和路徑不足以用來識別文件。對於Filebeat來說，都是通過實現存儲的唯一標識符來判斷文件是否之前已經被采集過。
　　如果在你的使用場景中，每天會產生大量的新文件，你將會發現Filebeat的注冊表文件會變得非常大。這個時候，你可以參考（the section called “Registry file is too large?edit），來解決這個問題。
安裝filebeat服務

二、ELK 常用架構及使用場景

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

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

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

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

2.3 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 加密傳輸，客戶端和服務器雙向認證，保證了通信安全。 
因此這種架構適合對數據安全性要求較高，同時各服務器性能比較敏感的場景。

2.4 引入消息隊列機制的架構
這種架構使用 Logstash 從各個數據源搜集數據，然后經消息隊列輸出插件輸出到消息隊列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常見消息隊列。然后 Logstash 通過消息隊列輸入插件從隊列中獲取數據，分析過濾后經輸出插件發送到 Elasticsearch，最后通過 Kibana 展示。詳見圖 4。

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

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

2.5 基於 Filebeat 架構的配置部署詳解
前面提到 Filebeat 已經完全替代了 Logstash-Forwarder 成為新一代的日志采集器，同時鑒於它輕量、安全等特點，越來越多人開始使用它。這個章節將詳細講解如何部署基於 Filebeat 的 ELK 集中式日志解決方案，具體架構見圖 5。

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

因為免費的 ELK 沒有任何安全機制，所以這里使用了 Nginx 作反向代理，避免用戶直接訪問 Kibana 服務器。加上配置 Nginx 實現簡單的用戶認證，一定程度上提高安全性。另外，Nginx 本身具有負載均衡的作用，能夠提高系統訪問性能。

三、Filebeat安裝

3.1下載和安裝key文件
sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

3.2 創建yum源文件

[root@localhost ~]# vim /etc/yum.repos.d/elk-elasticsearch.repo  [elastic-6.x] name=Elastic repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md

3.3 開始安裝
sudo yum install filebeat

3.4 啟動服務

sudo chkconfig --add filebeat systemctl start filebeat systemctl status filebeat

收集日志
這里我們先以收集docker日志為例，簡單來介紹一下filebeat的配置文件該如何編寫。具體內容如下：

[root@localhost ~]# grep "^\s*[^# \t].*$" /etc/filebeat/filebeat.yml filebeat: prospectors: - input_type: log paths: - /data/logs/nginx/*.log input_type: log document_type: nginx close_inactive: 1m scan_frequency: 5s fields: nginx_id: web-nodejs fields_under_root: true close_removed: true tail_files: true tags: 'web-nginx' spool_size: 1024 idle_timeout: 5s registry_file: /var/lib/filebeat/registry output: logstash: enabled: true hosts: ["192.168.6.108:5044"] worker: 4 bulk_max_size: 1024 compression_level: 6 loadbalance: false index: filebeat backoff.max: 120s

和我們看的一樣，其實並沒有太多的內容。我們采集/var/lib/docker/containers//.log，即filebeat所在節點的所有容器的日志。輸出的位置是我們ElasticSearch的服務地址，這里我們直接將log輸送給ES，而不通過Logstash中轉。

再啟動之前，我們還需要向ES提交一個filebeat index template，以便讓elasticsearch知道filebeat輸出的日志數據都包含哪些屬性和字段。filebeat.template.json這個文件安裝完之后就有，無需自己編寫，找不到的同學可以通過find查找。加載模板到elasticsearch中：

[root@localhost ~]# curl -XPUT 'http://192.168.58.128:9200/_template/filebeat?pretty' -d@/etc/filebeat/filebeat.template.json { "acknowledged" : true }

重啟服務
systemctl restart filebeat
提示：如果你啟動的是一個filebeat容器，需要將/var/lib/docker/containers目錄掛載到該容器中；

Kibana配置

如果上面配置都沒有問題，就可以訪問Kibana，不過這里需要添加一個新的index pattern。按照manual中的要求，對於filebeat輸送的日志，我們的index name or pattern應該填寫為："filebeat-*"。

 

轉自 https://blog.51cto.com/qiangsh/2153335