Filebeat優(yōu)化實(shí)踐的示例分析

本篇文章給大家分享的是有關(guān)Filebeat優(yōu)化實(shí)踐的示例分析，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Filebeat優(yōu)化實(shí)踐

背景介紹

目前比較主流的日志采集系統(tǒng)有ELK(ES+Logstash+Kibana),EFK(ES+Fluentd+Kibana)等。由于Logstash出現(xiàn)較早，大多數(shù)日志文件搜集采用了Logstash。但由于Logstash是JRuby實(shí)現(xiàn)的，性能開銷較大，因此我們的日志搜集采用的Filebeat，然后發(fā)送到Logstash進(jìn)行數(shù)據(jù)處理（例如：解析json，正則解析文件名稱等），最后由Logstash發(fā)送到Kafka或者ES。這種方式雖然減輕了每個(gè)節(jié)點(diǎn)的處理壓力，但部署Logstash的節(jié)點(diǎn)性能開銷依舊很大，而且經(jīng)常出現(xiàn)Filebeat無法發(fā)送數(shù)據(jù)到Logstash的情況。

拋棄Logstash

由于Logstash性能開銷較大，為了提高客戶端的日志采集性能，又減少數(shù)據(jù)傳輸環(huán)節(jié)和部署復(fù)雜度，并更充分地將 Go 語言的性能優(yōu)勢利用于日志解析，于是決定在 Filebeat 上通過開發(fā)插件的方式，實(shí)現(xiàn)針對公司日志格式規(guī)范的解析，直接作為 Logstash 的替代品。

開發(fā)自己的Processor

我們的平臺(tái)是基于Kubernetes的，因此我們需要解析每一條日志的source，從日志文件名稱中獲取Kubernetes資源名稱，以確定該條日志的發(fā)往Topic。解析文件名稱需要用到正則匹配，但由于正則性能開銷較大，如果每一條日志都用正則解析名稱將會(huì)帶來比較大的性能開銷，因此我們決定采用緩存來解決這一問題。即每個(gè)文件只解析一次名稱，存放到一個(gè)Map變量中，如果已經(jīng)解析過的文件名稱則不再解析。這樣大大提高了Filebeat的吞吐量。

性能優(yōu)化

Filebeat配置文件如下，其中kubernetes_metadata是自己開發(fā)的Processor。

################### Filebeat Configuration Example #########################

############################# Filebeat ######################################
filebeat:
  # List of prospectors to fetch data.
  prospectors:
    -
      paths:
        - /var/log/containers/*
      symlinks: true
#     tail_files: true
      encoding: plain
      input_type: log
      fields:
        type: k8s-log
        cluster: cluster1
        hostname: k8s-node1
      fields_under_root: true
      scan_frequency: 5s
      max_bytes: 1048576        # 1M

  # General filebeat configuration options
  registry_file: /data/usr/filebeat/kube-filebeat.registry

############################# Libbeat Config ##################################
# Base config file used by all other beats for using libbeat features

############################# Processors ######################################
processors:
- decode_json_fields:
    fields: ["message"]
    target: ""
- drop_fields:
    fields: ["message", "beat", "input_type"]
- kubernetes_metadata:
  # Default

############################# Output ##########################################

# Configure what outputs to use when sending the data collected by the beat.
# Multiple outputs may be used.
output:
  file: 
    path: "/data/usr/filebeat"
    filename: filebeat.log

測試環(huán)境：

• 性能測試工具使用https://github.com/urso/ljtest

• 火焰圖生成使用uber的go-torch https://github.com/uber/go-torch

• CPU通過runtime.GOMAXPROCS(1)限制使用一個(gè)核

第一版性能數(shù)據(jù)如下：

生成的CPU火焰圖如下

從火焰圖中可以看出 CPU 時(shí)間占用最多的主要有兩塊。一塊是 Output 處理部分，寫文件。另一塊就比較奇怪了，是 common.MapStr.Clone() 方法，居然占了 34.3% 的 CPU 時(shí)間。其中Errorf 占據(jù)了21%的CPU時(shí)間?？聪麓a：

func toMapStr(v interface{}) (MapStr, error) {
	switch v.(type) {
	case MapStr:
		return v.(MapStr), nil
	case map[string]interface{}:
		m := v.(map[string]interface{})
		return MapStr(m), nil
	default:
		return nil, errors.Errorf("expected map but type is %T", v)
	}
}

errors.Errorf生成error對象占據(jù)了大塊時(shí)間，把這一塊判斷邏輯放到MapStr.Clone()中就可以避免產(chǎn)生error，到此你是不是該有些思考？go的error雖然是很好的設(shè)計(jì)，但不能濫用，不能濫用，不能濫用！否則你可能會(huì)為此付出慘痛的代價(jià)。

優(yōu)化后：

處理速度竟然提高了50%多，沒想到幾行代碼的優(yōu)化，吞吐量竟然能提高這么多，驚不驚喜，意不意外。 再看下修改后的火焰圖

發(fā)現(xiàn)MapStr.Clone() 的性能消耗幾乎可以忽略不計(jì)了。

進(jìn)一步優(yōu)化：

我們的日志都是Docker產(chǎn)生的，使用 JSON 格式，而 Filebeat 使用 Go 自帶的 encoding/json 包是基于反射實(shí)現(xiàn)的，性能有一定問題。 既然我們的日志格式是固定的，解析出來的字段也是固定的，這時(shí)就可以基于固定的日志結(jié)構(gòu)體做 JSON 的序列化，而不必用低效率的反射來實(shí)現(xiàn)。Go 有多個(gè)針對給定結(jié)構(gòu)體做 JSON 序列化 / 反序列化的第三方包，這里使用的是 easyjson：https://github.com/mailru/easyjson。

由于解析的日志格式是固定的，所以提前定義好日志的結(jié)構(gòu)體，然后使用easyjson解析。 處理速度性能提升到

但這樣修改后就會(huì)使decode_json_fields 這個(gè)processor只能處理特定的日志格式，適用范圍會(huì)有所降低。所以json解析這塊暫時(shí)沒有修改。

日志處理一直是系統(tǒng)運(yùn)維中比較重要的環(huán)節(jié)，無論是傳統(tǒng)的運(yùn)維方式還是基于Kubernetes（或者M(jìn)esos，Swarm等）的新型云平臺(tái)日志搜集都格外重要。無論選用哪種方式搜集日志，都有可能遇到性能瓶頸，但一小段代碼的改善就可能完全解決了你的問題，路漫漫其修遠(yuǎn)兮，優(yōu)化永無止境。

需要稍作說明的是：

• Filebeat 開發(fā)是基于 5.5.1 版本，Go 版本是 1.8.3

• 測試中Filebeat使用runtime.GOMAXPROCS(1)限制只使用一個(gè)核

• 由于測試是在同一臺(tái)機(jī)器上使用相同數(shù)據(jù)進(jìn)行的，將日志輸出到文件對測試結(jié)果影響不大。

以上就是Filebeat優(yōu)化實(shí)踐的示例分析，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。