1. 程式人生 > 其它 >常見日誌收集方案及相關元件

常見日誌收集方案及相關元件

常見日誌收集方案及相關元件

一、常見日誌收集方案

1.1、EFK

​ 在Kubernetes叢集上執行多個服務和應用程式時,日誌收集系統可以幫助你快速分類和分析由Pod生成的大量日誌資料。Kubernetes中比較流行的日誌收集解決方案是ElasticsearchFluentdKibanaEFK)技術棧,也是官方推薦的一種方案。

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 有兩個必要元素:inputoutput ,一個可選元素: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 還適合我們對效能有著非常嚴格的要求時,特別是在有多個解析規則時。那麼這就值得為之投入更多的時間研究它的配置。

作者:Lawrence 出處:http://www.cnblogs.com/hujinzhong/

-------------------------------------------

個性簽名:獨學而無友,則孤陋而寡聞。做一個靈魂有趣的人!

掃描上面二維碼關注我 如果你真心覺得文章寫得不錯,而且對你有所幫助,那就不妨幫忙“推薦"一下,您的“推薦”和”打賞“將是我最大的寫作動力! 本文版權歸作者所有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連線.