新版flusher kafka数据转换和配置问题讨论

[shalousun]

背景

当前ilogtail flusher kafka 新版本的开发和测试基本已经完毕，但是当前flusher配置存在一些分歧点需要大家一起讨论下。讨论确定后做适量优化修改完成最终flusher kafka版本开发。

ilogtail日志协议了解

ilogtail单条json日志转换协议内容参考：

{
	"contents": {
		"class": "org.springframework.web.servlet.DispatcherServlet@initServletBean:547",
		"application": "springboot-docker",
		"level": "INFO",
		"message": "Completed initialization in 9 ms",
		"thread": "http-nio-8080-exec-10",
		"time": "2022-07-20 16:55:05.415"
	},
	"tags": {
        "k8s.namespace.name":"java_app",
		"host.ip": "192.168.6.128",
		"host.name": "master",
		"log.file.path": "/data/test.log"
	},
	"time": 1664435098
}

• 从上面的日志可以看出ilogtail标准的日志协议字段为：contents，tags，time
• contents主要是用户的日志内容，等价于ELK上message字段

topic配置讨论

针对上面写入的这种日志格式，如果想根据application名称针对不用的应用推送到不通的topic，
则topic可以这样配置。

Topic: test_%{attribute.application}

最后ilogtail就自动将日志推送到test_springboot-docker这个topic中。

topic动态表达式规则：

• %{attribute.fieldname}。attribute代表从contents中取指定字段值
• %{tag.fieldname},tag表示从tags中取指定字段值，例如：%{tag.k8s.namespace.name}
• 其它方式暂不支持

配置讨论点：

• 使用attribute代表从contents中取指定字段值，这里是否需要和协议字段前缀统一？

  配置动态topic是否需要变更为test_%{contents.application} ，filebeat是直接用的原始字段前缀。

• 从tags中取字段替换动态topic时，当前使用的tag前缀，是否也需要类似filebeat的配置一样直接使用原始字段名作为前缀方便记忆。

分区hash分发配置讨论

ilogtail一共支持三种分区分发方式：

• random随机分发, 默认。
• roundrobin轮询分发。
• hash分发。

random和roundrobin分发只需要配置PartitionerType指定对应的分区分发方式即可。
hash分发相对比较特殊，可以指定HashKeys，HashKeys的中配置的字段名只能是contents中的字段属性。

配置用例：

enable: true
inputs:
  - Type: file_log
    LogPath: /home/test_log
    FilePattern: "*.log"
flushers:
  - Type: flusher_kafka_v2
    PartitionerType: hash
    HashKeys:
      - application  //contents中的`application`
    Brokers:
      - 192.XX.XX.1:9092
    Topic: KafkaTestTopic

• 对HashKeys的配置，ilogtail实现是基于contents中用户的真实日志字段来做hash计算分发。配置时是否需要加前缀保持和前面配置统一？

HashKeys:
  - `contents.application` 主要和topic从字段取值统一

欢迎大家积极参与讨论和提出宝贵的优化建议

[messixukejia]

filebeat是直接用的原始字段前缀
是否也需要类似filebeat的配置一样直接使用原始字段名作为前缀方便记忆。
---- 这里所说的原始字段名做前缀能否举个例子？

[shalousun]

{
	"@timestamp": "2022-07-30T03:04:43.176Z",
	"@metadata": {
		"beat": "filebeat",
		"type": "_doc",
		"version": "7.4.2",
		"topic": "kubernetes_springboot-docker"
	},
	"message": "hello word",
	"program": "filebeat_k8s",
	"stream": "stdout",
	"fields": {
	   "log_topics": "kubernetes_springboot-docker"
	},
}

filebeat比如想用fields中的log_topics。它的配置通常是%{[fields][log_topics]}，来源可能看起来比较清晰

[messixukejia]

格式是这个吧 topic: '%{[fields.log_topic]}'？

[shalousun]

格式是这个吧 topic: '%{[fields.log_topic]}'？

应该两个都支持，我也是从实际的生成配置测试模板中copy的

[messixukejia]

个人意见：
%{tag.fieldname} -- 保持现状
%{attribute.fieldname} -- 不再加前缀，直接使用%{fieldname}

[yyuuttaaoo]

不加前缀是否会有重名风险，比如contents里面有个字段tag.name，至少也应该需要用一个点来进行区分前缀和key，例如.tag.name，这样就与真正的tags里的name(tag.name)区分开来了。
直观上来将，我觉得用contents，tags作为前缀是合理的，并且不存在重名风险。如果不是特别原因，例如要和别的什么功能对其的话，我觉得是可取的。
另外现在我们假设基于日志是kv的数据模型，这种表达没有任何问题。如果考虑后续支持更丰富的话，使用javascript原生的语法就非常直观了，比如log['contents']['meta']['topic']

[henryzhx8]

topic配置讨论：意见同上
分区hash分发配置讨论：个人认为保持现状即可，除非有计划用tag作为hashkey

[shalousun]

个人更倾向于保持有前缀并且前缀和协议字段名尽量统一，这样语义和来源也比较直观清晰，即便出现协议字段扩充也不会造成使用混乱，字段来列不明确的现象。目前看前缀也不会影响性能

[messixukejia]

首先明确下原则。字段提取实现与输出格式标准化是两个独立的过程，字段提取更早一些，所以需要基于ilogtail内部的处理流程来实现更合适下。也就是下面的pb结构。

所以建议改成用%{content.xxx}、%{tag.xxx}的形式。conventor转换的地方也麻烦改下吧。