常見日志收集方案及相關組件

一、常見日志收集方案

1.1、EFK

​ 在Kubernetes集群上運行多個服務和應用程序時，日志收集系統可以幫助你快速分類和分析由Pod生成的大量日志數據。Kubernetes中比較流行的日志收集解決方案是Elasticsearch、Fluentd和Kibana（EFK）技術棧，也是官方推薦的一種方案。

1）Elasticsearch：是一個實時的，分布式的，可擴展的搜索引擎，它允許進行全文本和結構化搜索以及對日志進行分析。它通常用於索引和搜索大量日志數據，也可以用於搜索許多不同種類的文檔。

2）Kibana：Elasticsearch通常與Kibana一起部署，kibana可以把Elasticsearch采集到的數據通過dashboard（儀表板）可視化展示出來。Kibana允許你通過Web界面瀏覽Elasticsearch日志數據，也可自定義查詢條件快速檢索出elasticccsearch中的日志數據。

3）Fluentd：是一個流行的開源數據收集器，我們在 Kubernetes 集群節點上安裝 Fluentd，通過獲取容器日志文件、過濾和轉換日志數據，然后將數據傳遞到 Elasticsearch 集群，在該集群中對其進行索引和存儲。

1.2、ELK Stack

1）Elasticsearch：日志存儲和搜索引擎，它的特點有：分布式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多數據源，自動搜索負載等。

2）Logstash：是一個完全開源的工具，他可以對你的日志進行收集、過濾，並將其存儲供以后使用（支持動態的從各種數據源搜集數據，並對數據進行過濾、分析、豐富、統一格式等操作。）。

3）Kibana ：是一個開源和免費的工具，Kibana可以為 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以幫助您匯總、分析和搜索重要數據日志。

考慮到聚合端（日志處理、清洗等）負載問題和采集端傳輸效率，一般在日志量比較大的時候在采集端和聚合端增加隊列，以用來實現日志消峰。

1.3、ELK+filebeat

Filebeat（采集）—> Logstash（聚合、處理）—> ElasticSearch （存儲）—>Kibana （展示）

1.4、其他方案

ELK日志流程可以有多種方案（不同組件可自由組合，根據自身業務配置），常見有以下：

1）Logstash（采集、處理）—> ElasticSearch （存儲）—>Kibana （展示）
2）Logstash（采集）—> Logstash（聚合、處理）—> ElasticSearch （存儲）—>Kibana （展示）
3）Filebeat（采集、處理）—> ElasticSearch （存儲）—>Kibana （展示）
4）Filebeat（采集）—> Logstash（聚合、處理）—> ElasticSearch （存儲）—>Kibana （展示）
5）Filebeat（采集）—> Kafka/Redis(消峰) —> Logstash（聚合、處理）—> ElasticSearch （存儲）—>Kibana （展示）

二、相關組件介紹

2.1、elasticsearch組件介紹

Elasticsearch 是一個分布式的免費開源搜索和分析引擎，適用於包括文本、數字、地理空間、結構化和非結構化數據等在內的所有類型的數據。Elasticsearch 在 Apache Lucene 的基礎上開發而成，由 Elasticsearch N.V.（即現在的 Elastic）於 2010 年首次發布。Elasticsearch 以其簡單的 REST 風格 API、分布式特性、速度和可擴展性而聞名，是 Elastic Stack 的核心組件；Elastic Stack 是一套適用於數據采集、擴充、存儲、分析和可視化的免費開源工具。人們通常將 Elastic Stack 稱為 ELK Stack（代指 Elasticsearch、Logstash 和 Kibana），目前 Elastic Stack 包括一系列豐富的輕量型數據采集代理，這些代理統稱為 Beats，可用來向 Elasticsearch 發送數據。

2.2、filebeat組件介紹

2.2.1、filebeat和beat關系

filebeat是Beats中的一員。Beats是一個輕量級日志采集器，Beats家族有6個成員，早期的ELK架構中使用Logstash收集、解析日志，但是Logstash對內存、cpu、io等資源消耗比較高。相比Logstash，Beats所占系統的CPU和內存幾乎可以忽略不計。

目前Beats包含六種工具：

1、Packetbeat：網絡數據（收集網絡流量數據）
2、Metricbeat：指標（收集系統、進程和文件系統級別的CPU和內存使用情況等數據）
3、Filebeat：日志文件（收集文件數據）
4、Winlogbeat：windows事件日志（收集Windows事件日志數據）
5、Auditbeat：審計數據（收集審計日志）
6、Heartbeat：運行時間監控（收集系統運行時的數據）

2.2.2、filebeat是什么

Filebeat是用於轉發和收集日志數據的輕量級傳送工具。Filebeat監視你指定的日志文件或位置，收集日志事件，並將它們轉發到Elasticsearch或 Logstash中。Filebeat的工作方式如下：啟動Filebeat時，它將啟動一個或多個輸入，這些輸入將在為日志數據指定的位置中查找。對於Filebeat所找到的每個日志，Filebeat都會啟動收集器。每個收集器都讀取單個日志以獲取新內容，並將新日志數據發送到libbeat，libbeat將聚集事件，並將聚集的數據發送到為Filebeat配置的輸出。

Filebeat 有兩個主要組件：

• harvester：一個harvester負責讀取一個單個文件的內容。harvester逐行讀取每個文件，並把這些內容發送到輸出。每個文件啟動一個harvester。
• Input：一個input負責管理harvesters，並找到所有要讀取的源。如果input類型是log，則input查找驅動器上與已定義的log日志路徑匹配的所有文件，並為每個文件啟動一個harvester。

2.2.3、Filebeat工作原理

1）在任何環境下，應用程序都有停機的可能性。 Filebeat 讀取並轉發日志行，如果中斷，則會記住所有事件恢復聯機狀態時所在位置。

2）Filebeat帶有內部模塊（auditd，Apache，Nginx，System和MySQL），可通過一個指定命令來簡化通用日志格式的收集，解析和可視化。

3）FileBeat 不會讓你的管道超負荷。FileBeat 如果是向 Logstash 傳輸數據，當 Logstash 忙於處理數據，會通知 FileBeat 放慢讀取速度。一旦擁塞得到解決，FileBeat將恢復到原來的速度並繼續傳播。

4）Filebeat保持每個文件的狀態，並經常刷新注冊表文件中的磁盤狀態。狀態用於記住harvester正在讀取的最后偏移量，並確保發送所有日志行。Filebeat將每個事件的傳遞狀態存儲在注冊表文件中。所以它能保證事件至少傳遞一次到配置的輸出，沒有數據丟失。

2.2.4、Filebeat傳輸方案

1）output.elasticsearch

如果你希望使用 filebeat 直接向 elasticsearch 輸出數據，需要配置 output.elasticsearch

output.elasticsearch:
  hosts: ["192.168.40.180:9200"]

2）output.logstash

如果使用filebeat向 logstash輸出數據，然后由 logstash 再向elasticsearch 輸出數據，需要配置 output.logstash。 logstash 和 filebeat 一起工作時，如果 logstash 忙於處理數據，會通知FileBeat放慢讀取速度。一旦擁塞得到解決，FileBeat 將恢復到原來的速度並繼續傳播。這樣，可以減少管道超負荷的情況。

output.logstash:
  hosts: ["192.168.40.180:5044"] 

3）output.kafka

如果使用filebeat向kafka輸出數據，然后由 logstash 作為消費者拉取kafka中的日志，並再向elasticsearch 輸出數據，需要配置output.kafka

output.kafka:
  enabled: true
  hosts: ["192.168.40.180:9092"]
  topic: elfk8stest

2.3、logstash組件介紹

2.3.1、logstash是什么

Logstash是一個開源數據收集引擎，具有實時管道功能。Logstash可以動態地將來自不同數據源的數據統一起來，並將數據標准化到你所選擇的目的地。Logstash 是一個應用程序日志、事件的傳輸、處理、管理和搜索的平台。你可以用它來統一對應用程序日志進行收集管理，提供 Web 接口用於查詢和統計。

輸入：采集各種樣式、大小和來源的數據

數據往往以各種各樣的形式，或分散或集中地存在於很多系統中。Logstash 支持各種輸入選擇 ，可以在同一時間從眾多常用來源捕捉事件。能夠以連續的流式傳輸方式，輕松地從你的日志、指標、Web 應用、數據存儲以及各種 AWS 服務采集數據。

過濾器：實時解析和轉換數據

數據從源傳輸到存儲庫的過程中，Logstash 過濾器能夠解析各個事件，識別已命名的字段以構建結構，並將它們轉換成通用格式，以便更輕松、更快速地分析和實現商業價值。

Logstash 能夠動態地轉換和解析數據，不受格式或復雜度的影響：
1、利用 Grok 從非結構化數據中派生出結構
2、從 IP 地址破譯出地理坐標
3、將 PII 數據匿名化，完全排除敏感字段
4、整體處理不受數據源、格式或架構的影響

輸出：選擇你的存儲，導出你的數據

盡管 Elasticsearch 是我們的首選輸出方向，能夠為我們的搜索和分析帶來無限可能，但它並非唯一選擇。Logstash 提供眾多輸出選擇，你可以將數據發送到你要指定的地方

2.3.2、Logstash工作原理

Logstash 有兩個必要元素：input 和 output ，一個可選元素：filter。 這三個元素，分別代表 Logstash 事件處理的三個階段：輸入 > 過濾器 > 輸出

• Input：負責從數據源采集數據。
• filter ：將數據修改為你指定的格式或內容。
• output：將數據傳輸到目的地。

在實際應用場景中，通常輸入、輸出、過濾器不止一個。Logstash 的這三個元素都使用插件式管理方式，可以根據應用需要，靈活的選用各階段需要的插件，並組合使用。

1）常用input模塊

Logstash 支持各種輸入選擇 ，可以在同一時間從眾多常用來源捕捉事件。能夠以連續的流式傳輸方式，可從日志、指標、Web 應用、數據存儲以及各種 AWS 服務采集數據。

• file：從文件系統上的文件讀取
• syslog：在眾所周知的端口514上偵聽系統日志消息，並根據RFC3164格式進行解析
• redis：從redis服務器讀取，使用redis通道和redis列表。 Redis經常用作集中式Logstash安裝中的“代理”，它將接收來自遠程Logstash“托運人”的Logstash事件排隊。
• beats：處理由Filebeat發送的事件

2）常用的filter模塊

過濾器是Logstash管道中的中間處理設備。可以將條件過濾器組合在一起，對事件執行操作。

• grok：解析和結構任意文本。 Grok目前是Logstash中將非結構化日志數據解析為結構化和可查詢的最佳方法。
• mutate：對事件字段執行一般轉換。可以重命名，刪除，替換和修改事件中的字段。
• drop：完全放棄一個事件，例如調試事件。
• clone：制作一個事件的副本，可能會添加或刪除字段。
• geoip：添加有關IP地址的地理位置的信息

3）常用output模塊

• elasticsearch：將事件數據發送給 Elasticsearch（推薦模式）。
• file：將事件數據寫入文件或磁盤。
• graphite：將事件數據發送給 graphite（一個流行的開源工具，存儲和繪制指標， http://graphite.readthedocs.io/en/latest/）。
• statsd：將事件數據發送到 statsd （這是一種偵聽統計數據的服務，如計數器和定時器，通過UDP發送並將聚合發送到一個或多個可插入的后端服務）。

4）常用code插件

• json：以JSON格式對數據進行編碼或解碼。
• multiline：將多行文本事件（如java異常和堆棧跟蹤消息）合並為單個事件。

# 示例
input {
      kafka {
        bootstrap_servers => "192.168.40.180:9092"
        auto_offset_reset => "latest"
        consumer_threads => 5
        decorate_events => true
        topics => ["elktest"]
      }
}
          
output { 
    elasticsearch { 
        hosts => ["192.168.40.180:9200"]
        index => "elkk8stest-%{+YYYY.MM.dd}"
        }
}

2.4、fluentd組件介紹

fluentd是一個針對日志的收集、處理、轉發系統。通過豐富的插件系統，可以收集來自於各種系統或應用的日志，轉化為用戶指定的格式后，轉發到用戶所指定的日志存儲系統之中。

fluentd 常常被拿來和Logstash比較，我們常說ELK，L就是這個agent。fluentd 是隨着Docker和es一起流行起來的agent。

• fluentd 比 logstash 更省資源；
• 更輕量級的 fluent-bid 對應 filebeat，作為部署在結點上的日志收集器；
• fluentd 有更多強大、開放的插件數量和社區。插件多，也非常靈活，規則也不復雜。

三、常用工具對比

常見的日志采集工具有Logstash、Filebeat、Fluentd、Logagent、rsyslog等等，那么他們之間有什么區別呢?什么情況下我們應該用哪一種工具?

3.1、Logstash

Logstash是一個開源數據收集引擎，具有實時管道功能。Logstash可以動態地將來自不同數據源的數據統一起來，並將數據標准化到你所選擇的目的地。

1）優勢
Logstash 主要的優點就是它的靈活性，主要因為它有很多插件，詳細的文檔以及直白的配置格式讓它可以在多種場景下應用。我們基本上可以在網上找到很多資源，幾乎可以處理任何問題。

2）劣勢
Logstash 致命的問題是它的性能以及資源消耗(默認的堆大小是 1GB)。盡管它的性能在近幾年已經有很大提升，與它的替代者們相比還是要慢很多的。這里有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比。它在大數據量的情況下會是個問題。另一個問題是它目前不支持緩存，目前的典型替代方案是將 Redis 或 Kafka 作為中心緩沖池

3）典型應用場景

因為 Logstash 自身的靈活性以及網絡上豐富的資料，Logstash 適用於原型驗證階段使用，或者解析非常的復雜的時候。在不考慮服務器資源的情況下，如果服務器的性能足夠好，我們也可以為每台服務器安裝 Logstash 。我們也不需要使用緩沖，因為文件自身就有緩沖的行為，而 Logstash 也會記住上次處理的位置。

如果服務器性能較差，並不推薦為每個服務器安裝 Logstash ，這樣就需要一個輕量的日志傳輸工具，將數據從服務器端經由一個或多個 Logstash 中心服務器傳輸到 Elasticsearch。

隨着日志項目的推進，可能會因為性能或代價的問題，需要調整日志傳輸的方式(log shipper)。當判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有着准確的估計，這也決定了需要為 Logstash 投入多少硬件資源。

3.2、Filebeat

作為 Beats 家族的一員，Filebeat 是一個輕量級的日志傳輸工具，它的存在正彌補了 Logstash 的缺點：Filebeat 作為一個輕量級的日志傳輸工具可以將日志推送到中心 Logstash。

在版本 5.x 中，Elasticsearch 具有解析的能力(像 Logstash 過濾器)— Ingest。這也就意味着可以將數據直接用 Filebeat 推送到 Elasticsearch，並讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩沖，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移，如果需要緩沖(例如，不希望將日志服務器的文件系統填滿)，可以使用 Redis/Kafka，因為 Filebeat 可以與它們進行通信。

1）優勢

Filebeat 只是一個二進制文件沒有任何依賴。它占用資源極少，盡管它還十分年輕，正式因為它簡單，所以幾乎沒有什么可以出錯的地方，所以它的可靠性還是很高的。它也為我們提供了很多可以調節的點，例如：它以何種方式搜索新的文件，以及當文件有一段時間沒有發生變化時，何時選擇關閉文件句柄。

2）劣勢

Filebeat 的應用范圍十分有限，所以在某些場景下我們會碰到問題。例如，如果使用 Logstash 作為下游管道，我們同樣會遇到性能問題。正因為如此，Filebeat 的范圍在擴大。開始時，它只能將日志發送到 Logstash 和 Elasticsearch，而現在它可以將日志發送給 Kafka 和 Redis，在 5.x 版本中，它還具備過濾的能力。

3.3、Fluentd

Fluentd 創建的初衷主要是盡可能的使用 JSON 作為日志輸出，所以傳輸工具及其下游的傳輸線不需要猜測子字符串里面各個字段的類型。這樣，它為幾乎所有的語言都提供庫，這也意味着，我們可以將它插入到我們自定義的程序中。

1）優勢

和多數 Logstash 插件一樣，Fluentd 插件是用 Ruby 語言開發的非常易於編寫維護。所以它數量很多，幾乎所有的源和目標存儲都有插件(各個插件的成熟度也不太一樣)。這也意味這我們可以用 Fluentd 來串聯所有的東西。

2）劣勢

因為在多數應用場景下，我們會通過 Fluentd 得到結構化的數據，它的靈活性並不好。但是我們仍然可以通過正則表達式，來解析非結構化的數據。盡管，性能在大多數場景下都很好，但它並不是最好的，和 syslog-ng 一樣，它的緩沖只存在與輸出端，單線程核心以及 Ruby GIL 實現的插件意味着它大的節點下性能是受限的，不過，它的資源消耗在大多數場景下是可以接受的。對於小的或者嵌入式的設備，可能需要看看 Fluent Bit，它和 Fluentd 的關系與 Filebeat 和 Logstash 之間的關系類似。

3）典型應用場景

Fluentd 在日志的數據源和目標存儲各種各樣時非常合適，因為它有很多插件。而且，如果大多數數據源都是自定義的應用，所以可以發現用 fluentd 的庫要比將日志庫與其他傳輸工具結合起來要容易很多。特別是在我們的應用是多種語言編寫的時候，即我們使用了多種日志庫，日志的行為也不太一樣。

3.4、Logagent

Logagent 是 Sematext 提供的傳輸工具，它用來將日志傳輸到 Logsene(一個基於 SaaS 平台的 Elasticsearch API)，因為 Logsene 會暴露 Elasticsearch API，所以 Logagent 可以很容易將數據推送到 Elasticsearch 。

1）優勢

可以獲取 /var/log 下的所有信息，解析各種格式(Elasticsearch，Solr，MongoDB，Apache HTTPD等等)，它可以掩蓋敏感的數據信息，例如，個人驗證信息(PII)，出生年月日，信用卡號碼，等等。它還可以基於 IP 做 GeoIP 豐富地理位置信息(例如，access logs)。同樣，它輕量又快速，可以將其置入任何日志塊中。在新的 2.0 版本中，它以第三方 node.js 模塊化方式增加了支持對輸入輸出的處理插件。重要的是 Logagent 有本地緩沖，所以不像 Logstash ，在數據傳輸目的地不可用時會丟失日志。

2）劣勢
盡管 Logagent 有些比較有意思的功能(例如，接收 Heroku 或 CloudFoundry 日志)，但是它並沒有 Logstash 靈活。

3）典型應用場景

Logagent 作為一個可以做所有事情的傳輸工具是值得選擇的(提取、解析、緩沖和傳輸)。

3.5、Logtail

阿里雲日志服務的生產者，目前在阿里集團內部機器上運行，經過3年多時間的考驗，目前為阿里公有雲用戶提供日志收集服務。采用C++語言實現，對穩定性、資源控制、管理等下過很大的功夫，性能良好。相比於logstash、fluentd的社區支持，logtail功能較為單一，專注日志收集功能。

1）優勢
logtail占用機器cpu、內存資源最少，結合阿里雲日志服務的E2E體驗良好。

2）劣勢
logtail目前對特定日志類型解析的支持較弱，后續需要把這一塊補起來。

3.6、Rsyslog

絕大多數 Linux 發布版本默認的 syslog 守護進程，rsyslog 可以做的不僅僅是將日志從 syslog socket 讀取並寫入 /var/log/messages 。它可以提取文件、解析、緩沖(磁盤和內存)以及將它們傳輸到多個目的地，包括 Elasticsearch 。可以從此處找到如何處理 Apache 以及系統日志。

1）優勢

rsyslog 是經測試過的最快的傳輸工具。如果只是將它作為一個簡單的 router/shipper 使用，幾乎所有的機器都會受帶寬的限制，但是它非常擅長處理解析多個規則。它基於語法的模塊(mmnormalize)無論規則數目如何增加，它的處理速度始終是線性增長的。這也就意味着，如果當規則在 20-30 條時，如解析 Cisco 日志時，它的性能可以大大超過基於正則式解析的 grok ，達到 100 倍(當然，這也取決於 grok 的實現以及 liblognorm 的版本)。
它同時也是我們能找到的最輕的解析器，當然這也取決於我們配置的緩沖。

2）劣勢
rsyslog 的配置工作需要更大的代價(這里有一些例子)，這讓兩件事情非常困難：
文檔難以搜索和閱讀，特別是那些對術語比較陌生的開發者。
5.x 以上的版本格式不太一樣(它擴展了 syslogd 的配置格式，同時也仍然支持舊的格式)，盡管新的格式可以兼容舊格式，但是新的特性(例如，Elasticsearch 的輸出)只在新的配置下才有效，然后舊的插件(例如，Postgres 輸出)只在舊格式下支持。
盡管在配置穩定的情況下，rsyslog 是可靠的(它自身也提供多種配置方式，最終都可以獲得相同的結果)，它還是存在一些 bug 。

3）典型應用場景
rsyslog 適合那些非常輕的應用(應用，小VM，Docker容器)。如果需要在另一個傳輸工具(例如，Logstash)中進行處理，可以直接通過 TCP 轉發 JSON ，或者連接 Kafka/Redis 緩沖。
rsyslog 還適合我們對性能有着非常嚴格的要求時，特別是在有多個解析規則時。那么這就值得為之投入更多的時間研究它的配置。