0
点赞
收藏
分享

微信扫一扫

如何进行技术方案选型?

背景

我们的业务服务,已经全部部署在kubernetes集群中,全业务线通过fluent-bit直接写入es进行日志收集,单业务线日志规模为1TB/天, 这样带来3个问题:

1. 高峰期出现丢日志情况(采集组件直写es,并发太大导致es写入失败)

2. 日志集群规模大,成本非常高。

3. 历史数据仅能存储3天,无法长期保留。



 目标

为了解决上述存在的3个问题,我们进行了日志专项探讨,期望通过引入新技术,新方案来解决存在的问题。在保障日志不丢的同时,满足业务侧对日志查询的需求,降低业务成本。


选型

预选方案:

fluent-bit->kafka->lambda-es (增加kafka队列)

fluent-bit->s3->sqs->lambda-es (使用s3+sqs队列,低成本)

promtail->loki->s3->grafana (低成本)


下面就如何对loki方案进行选型验证,进行详细描述。



拆解分析:

业务侧需求

  • 需要保留7天的日志。可按照服务级别重要程度进行存储。(基本功能)
  • 在分钟级别,查询到当天指定字段的日志,实现问题定位。(效率)
  • 能在平台业务,通过简单的操作,即可完成日志查询。(易用)


技术方案对比


Loki

Es


社区活跃度

***

*****

  • 有多少人在用
  • 是否在持续更新

文档全面性

***

*****


技术语言

go

java


性能

***

*****


成本

***

*****


生态

*****

*****

grafana+loki可观测性更全面

功能

****

*****


优势

成本低

全文索引


可维护性

*****

****

loki 横向扩容能力强

成熟度

***

*****

es方案更加成熟

用户体验

****

***





方案调研

  • 满足技术选型目标吗?
  • 满足范围、时间和成本的约束吗?
  • 成功案例
  • 运维复杂度,学习成本
  • 有什么样的风险?风险是不是可控?
  • 优缺点是什么?



验证

在实际环境中进行验证确认。

决策

决策会


注意事项

  1. 不过分追求新技术,以满足业务需求为主
  2. 技术栈建议和团队保持一致,以便后续维护。
  3. 技术生态是否丰富,社区是否活跃,文档是否健全,在出现问题时,这些将成为是否能快速解决问题的重点。
  4. 了解技术的优缺点。
  5. 选择最熟悉、使用最多的技术。
  6. 先验证,后使用。
  7. 是否有完善的技术体系(如何监控、运维、扩展)。
  8. 时间成本和人力成本。结合实际情况,有人堆人,有时间就堆时间。



举报

相关推荐

0 条评论