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

創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、成都做網(wǎng)站、長順網(wǎng)絡(luò)推廣、微信平臺小程序開發(fā)、長順網(wǎng)絡(luò)營銷、長順企業(yè)策劃、長順品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供長順建站搭建服務(wù)，24小時服務(wù)熱線：18982081108，官方網(wǎng)址：aaarwkj.com

Filebeat優(yōu)化實踐

背景介紹

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

拋棄Logstash

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

開發(fā)自己的Processor

我們的平臺是基于Kubernetes的，因此我們需要解析每一條日志的source，從日志文件名稱中獲取Kubernetes資源名稱，以確定該條日志的發(fā)往Topic。解析文件名稱需要用到正則匹配，但由于正則性能開銷較大，如果每一條日志都用正則解析名稱將會帶來比較大的性能開銷，因此我們決定采用緩存來解決這一問題。即每個文件只解析一次名稱，存放到一個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)限制使用一個核

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

平均速度	100萬條總時間
11970 條/s	83.5秒

生成的CPU火焰圖如下

從火焰圖中可以看出 CPU 時間占用最多的主要有兩塊。一塊是 Output 處理部分，寫文件。另一塊就比較奇怪了，是 common.MapStr.Clone() 方法，居然占了 34.3% 的 CPU 時間。其中Errorf 占據(jù)了21%的CPU時間?？聪麓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ù)了大塊時間，把這一塊判斷邏輯放到MapStr.Clone()中就可以避免產(chǎn)生error，到此你是不是該有些思考？go的error雖然是很好的設(shè)計，但不能濫用，不能濫用，不能濫用！否則你可能會為此付出慘痛的代價。

優(yōu)化后：

平均速度	100萬條總時間
18687 條/s	53.5秒

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

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

進一步優(yōu)化：

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

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

平均速度	100萬條總時間
20374 條/s	49秒

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

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

需要稍作說明的是：

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

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

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

以上就是Filebeat優(yōu)化實踐的示例分析，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

本文標(biāo)題：Filebeat優(yōu)化實踐的示例分析
文章出自：http://aaarwkj.com/article26/jeggcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、做網(wǎng)站、靜態(tài)網(wǎng)站、企業(yè)建站、App開發(fā)、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)