如何进行技术方案选型？

背景

我们的业务服务，已经全部部署在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天的日志。可按照服务级别重要程度进行存储。（基本功能）
• 在分钟级别，查询到当天指定字段的日志，实现问题定位。（效率）
• 能在平台业务，通过简单的操作，即可完成日志查询。（易用）

技术方案对比

方案调研

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

验证

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

决策

决策会

注意事项

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