Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[QUESTION]:同步日志文件到Kafka,如何将原始信息写入Kafka的topic,不要添加contents,tags,time这些字段 #1737

Open
iamhungry opened this issue Sep 4, 2024 · 13 comments
Labels
question Further information is requested

Comments

@iamhungry
Copy link

以下为实际写入Kafka的内容,预期值为:"Hello, iLogtail!"

{
"contents": {
"content": "Hello, iLogtail!"
},
"tags": {
"host.ip": "172.17.0.1",
"host.name": "sckf",
"log.file.path": "/root/simple.log"
},
"time": 1725436015
}

@iamhungry iamhungry added the question Further information is requested label Sep 4, 2024
@messixukejia
Copy link
Collaborator

这个可能要自己改下代码了

@iamhungry
Copy link
Author

具体代码在哪个地方,修改思路能说明一下吗?

@iamhungry
Copy link
Author

最好是添加一个控制参数,通过开关来实现这个功能。

@silentmoooon
Copy link
Contributor

可以参考下我的,写得比较简单粗暴,
加了个参数, 自己简单处理了一下
image
image

@iamhungry
Copy link
Author

@silentmoooon 你可以提个pr,建议官方合到主仓库去。这个需求是存在的。

@silentmoooon
Copy link
Contributor

好,待我完善一下再提

@shalousun
Copy link
Collaborator

shalousun commented Sep 14, 2024

这个方式从行业日志采集实践上将并不好,所有采集器都添加一些额外信息实际上只是为了追溯信息来源。没有来源出问题分析问题很难,除非只有一台机器自己玩。多余的几个字段也并不占太多存储空间,觉得占用空间给flusher_kafka_v2配置下压缩存储也会下降很多Compression: lz4。消费处理实际也不复杂。多节点多实例的业务一定是需要一些额外信息去辅助日志查看分析的。

@shalousun
Copy link
Collaborator

@iamhungry 这个需求的场景是什么

@iamhungry
Copy link
Author

@iamhungry 这个需求的场景是什么

https://mp.weixin.qq.com/s/A5ONkvkh9JF5SvDdDP-o0Q

我是参考这篇文章处理业务层的数据上报,想用ilogtail替换filebeat

本地落盘的log是业务层上报的数据,通过filebeat直接传入kafka。

落盘的文件按业务划分,一个业务只向一个文件里写,一个文件对应一个kafka的topic,追溯信息来源不需要特别指定是哪个文件。即通过定义约定,可以省掉很多中间的逻辑。

自己解析确实不复杂,这种日志量很大,在讲究性能的情况下,能不解析少操作一步,肯定是优化。

@iamhungry
Copy link
Author

在filebeat里,是有这个配置项的。它默认也是附加了一些字段,通过以下配置可以原样写入kafka.

1726798436726

@shalousun
Copy link
Collaborator

@iamhungry 这个需求的场景是什么

https://mp.weixin.qq.com/s/A5ONkvkh9JF5SvDdDP-o0Q

我是参考这篇文章处理业务层的数据上报,想用ilogtail替换filebeat

本地落盘的log是业务层上报的数据,通过filebeat直接传入kafka。

落盘的文件按业务划分,一个业务只向一个文件里写,一个文件对应一个kafka的topic,追溯信息来源不需要特别指定是哪个文件。即通过定义约定,可以省掉很多中间的逻辑。

自己解析确实不复杂,这种日志量很大,在讲究性能的情况下,能不解析少操作一步,肯定是优化。

日志文件和topic区分了业务,但是日志来自那个实例节点你们是直接打印的日志里吗。比如程序跑5个实例在不同的机器上,有一个实例的机器可能是网络故障、硬件损坏了,如果只存message内容目前你们是怎么在采集里区分的在那台机器出问题

@iamhungry
Copy link
Author

@iamhungry 这个需求的场景是什么

https://mp.weixin.qq.com/s/A5ONkvkh9JF5SvDdDP-o0Q
我是参考这篇文章处理业务层的数据上报,想用ilogtail替换filebeat
本地落盘的log是业务层上报的数据,通过filebeat直接传入kafka。
落盘的文件按业务划分,一个业务只向一个文件里写,一个文件对应一个kafka的topic,追溯信息来源不需要特别指定是哪个文件。即通过定义约定,可以省掉很多中间的逻辑。
自己解析确实不复杂,这种日志量很大,在讲究性能的情况下,能不解析少操作一步,肯定是优化。

日志文件和topic区分了业务,但是日志来自那个实例节点你们是直接打印的日志里吗。比如程序跑5个实例在不同的机器上,有一个实例的机器可能是网络故障、硬件损坏了,如果只存message内容目前你们是怎么在采集里区分的在那台机器出问题

哪台机器出问题,属于运维监控层面的事,负载均衡会自动去掉异常节点,不将日志流量转发过去。

监控系统很成熟,通过监控报警,自然就知道问题出现在哪台机器上。

分层思想,可以简化当前处理的问题。也就是说,我们不在业务里面处理日志的节点跟踪。

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants