日志采集服务需要为 kafka 兜底吗？如果兜底的话，你们都是怎么做的？？

[lsk569937453]

背景

周五的时候另外一个项目组要交接项目给我们组。此项目主要是日志采集的项目。主要就是 logstash 发送日志到采集服务，然后采集服务将日志发送到 Kafka ，每秒钟发送的日志量大概 10000 条，单条不超过 10K 。

架构上采集服务收到日志后，会直接落到本地磁盘，然后有个定时任务去固定的将磁盘上的文件批量发送给 Kafka 。因为他们是为了做断点续传，比如 kafka 挂掉之后，采集服务仍然可以运行，不丢失日志。

疑问

刚交接的时候没感觉有问题，今天越想越不对。作为采集服务，你的 Kafka 就是你的核心依赖啊，你 kafka 挂掉，直接不提供服务/日志没法采集不就好了，或者你发送端重新发送。

• 如果为每个服务的核心依赖都做兜底，那依赖数据库的是不是每次也要先把数据写到文件中，防止数据库挂掉，保证数据能落到数据库中？
• 你的项目/服务为 kafka 兜过底吗？
• 我这个采集服务应不应该支持断点续传？如果支持的话要怎么支持？

[liprais]

你那服务比 kafka 整个挂掉的可能性高太多了
qps 几十万 kafka 也是轻松接住的

[bronyakaka]

1 、很显然这个架构太冗余了，kafka 可用性是很高的，根本不用担心这些
2 、采集服务受到日志后，直接发送到 kafka 集群即可
3 、kafka 本身也是个分布式存储系统，哪怕挂了短期内文件也不会丢失（除非你配置了自动删除过期文件），重新在上次的进度继续消费就行

[ruanimal]

好像马老板要依赖你兜里的两块五

[tairan2006]

怕挂掉的话 kafka 多部署几个节点不就完了…

[helloluckydamon]

一些浅见：
技术方案上大部分时候是没有绝对答案的。
楼主所提出的是否要未 kafka 兜底的问题，其实要看前置条件，就像代码在机器上执行也需要上下文一样。

哪些场景需要楼主进行兜底：
* 指标与责任：日志服务的可用性、数据的完整性指标是由楼主团队来负责的
* 业务与价值：日志采集是 P0 级服务，数据价值高，不能丢失
* 能力与现状：发送方目前无能力进行异常兜底，如重试、暂存、监控告警等

哪些场景不需要楼主进行兜底：
* 发送方已经做了重试、暂存、落地等异常处理进行兜底，同时数据短暂丢失可以接受

兜底的理由有很多，数据价值、服务可用性等等，不兜底的理由只有一个，就是相比之下，有更有价值和急切的事情要做。

兜底：
一切安好。

不兜底：
未来某一天日志丢失、不可用，两个团队互相指责、推卸、谩骂、诋毁、内耗。

---

另外，其实楼主的问题中反复提到，是为了 kafa 兜底，那其实更应该考虑的是，如何提高和保障 kafka 集群的可用性，而非采集服务。

[1423]

只有我觉得原方案比较合理吗?

[julyclyde]

按说是不需要
kafka 本身就是个兜底工具了，不能无限的为工具再兜底

[dmanbu]

ELK 那套的话，还是建议加个 kafka ，也就是 filebeat -> kafka -> logstash
直接 filebeat -> logstash 的话，日志量小没啥，量大的话，会出现丢日志的情况

[julyclyde]

@dmanbu filebeat 不是 TCP 发送的嘛？为什么丢呢？
按说死要见尸啊

[dmanbu]

@julyclyde 没深入研究过，但就是丢，加了 Kafka 就好了