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

查看 41|回复 6
作者: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   
    只有我觉得原方案比较合理吗?
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部