Filebeat安裝部署

1、簡單概述

　　最近在瞭解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服務

2、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 自己具備負載均衡的做用，可以提升系統訪問性能。

3、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-*"。