Filebeat优化实践

Filebeat优化实践

背景介绍

目前比较主流的日志采集系统有ELK(ES+Logstash+Kibana),EFK(ES+Fluentd+Kibana)等。因为Logstash出现较早，大多很多天志文件搜集采用了Logstash。但因为Logstash是JRuby实现的，性能开销较大，所以咱们的日志搜集采用的Filebeat，而后发送到Logstash进行数据处理（例如：解析json，正则解析文件名称等），最后由Logstash发送到Kafka或者ES。这种方式虽然减轻了每一个节点的处理压力，但部署Logstash的节点性能开销依旧很大，并且常常出现Filebeat没法发送数据到Logstash的状况。

抛弃Logstash

因为Logstash性能开销较大，为了提升客户端的日志采集性能，又减小数据传输环节和部署复杂度，并更充分地将 Go 语言的性能优点利用于日志解析，因而决定在 Filebeat 上经过开发插件的方式，实现针对公司日志格式规范的解析，直接做为 Logstash 的替代品。

开发本身的Processor

咱们的平台是基于Kubernetes的，所以咱们须要解析每一条日志的source，从日志文件名称中获取Kubernetes资源名称，以肯定该条日志的发往Topic。解析文件名称须要用到正则匹配，但因为正则性能开销较大，若是每一条日志都用正则解析名称将会带来比较大的性能开销，所以咱们决定采用缓存来解决这一问题。即每一个文件只解析一次名称，存放到一个Map变量中，若是已经解析过的文件名称则再也不解析。这样大大提升了Filebeat的吞吐量。

性能优化

Filebeat配置文件以下，其中kubernetes_metadata是本身开发的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

测试环境：

• 性能测试工具使用https://github.com/urso/ljtest
• 火焰图生成使用uber的go-torch https://github.com/uber/go-torch
• CPU经过runtime.GOMAXPROCS(1)限制使用一个核

初版性能数据以下：

平均速度	100万条总时间
11970 条/s	83.5秒

生成的CPU火焰图以下

从火焰图中能够看出 CPU 时间占用最多的主要有两块。一块是 Output 处理部分，写文件。另外一块就比较奇怪了，是 common.MapStr.Clone() 方法，竟然占了 34.3% 的 CPU 时间。其中Errorf 占据了21%的CPU时间。看下代码：

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对象占据了大块时间，把这一块判断逻辑放到MapStr.Clone()中就能够避免产生error，到此你是否是该有些思考？go的error虽然是很好的设计，但不能滥用，不能滥用，不能滥用！不然你可能会为此付出惨痛的代价。

优化后：

平均速度	100万条总时间
18687 条/s	53.5秒

处理速度居然提升了50%多，没想到几行代码的优化，吞吐量居然能提升这么多，惊不惊喜，意不意外。 再看下修改后的火焰图

发现MapStr.Clone() 的性能消耗几乎能够忽略不计了。

进一步优化：

咱们的日志都是Docker产生的，使用 JSON 格式，而 Filebeat 使用 Go 自带的 encoding/json 包是基于反射实现的，性能有必定问题。 既然咱们的日志格式是固定的，解析出来的字段也是固定的，这时就能够基于固定的日志结构体作 JSON 的序列化，而没必要用低效率的反射来实现。Go 有多个针对给定结构体作 JSON 序列化 / 反序列化的第三方包，这里使用的是 easyjson：https://github.com/mailru/easyjson。

因为解析的日志格式是固定的，因此提早定义好日志的结构体，而后使用easyjson解析。 处理速度性能提高到

平均速度	100万条总时间
20374 条/s	49秒

但这样修改后就会使decode_json_fields 这个processor只能处理特定的日志格式，适用范围会有所下降。因此json解析这块暂时没有修改。

总结

日志处理一直是系统运维中比较重要的环节，不管是传统的运维方式仍是基于Kubernetes（或者Mesos，Swarm等）的新型云平台日志搜集都格外重要。不管选用哪一种方式搜集日志，都有可能遇到性能瓶颈，但一小段代码的改善就可能彻底解决了你的问题，路漫漫其修远兮，优化永无止境。

须要稍做说明的是：

• Filebeat 开发是基于 5.5.1 版本，Go 版本是 1.8.3
• 测试中Filebeat使用runtime.GOMAXPROCS(1)限制只使用一个核
• 因为测试是在同一台机器上使用相同数据进行的，将日志输出到文件对测试结果影响不大。

参考连接： https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247486717&idx=1&sn=37fae9ba997b156c2ccb5f28803130b7&chksm=96c9ba9da1be338b040041a60a1b8553563363e9f1b27225bfd6829b3de758d6b8e641a48041#rd