Stripe迁移至AWS托管服务的可观测性平台

Stripe将其可观测性平台从第三方供应商解决方案迁移到基于AWS托管服务的新架构，主要原因包括扩展性限制、可靠性问题以及向微服务架构过渡时成本不断上升。迁移过程涉及双写指标、资产转换、验证和用户培训。

迁移背景

Stripe在采用微服务架构后，生成了约3亿个指标、4万个警报和7千名员工生成的10万个仪表盘查询。由于数据量庞大，原有的可观测性平台开始出现扩展性和可靠性问题，且成本不断增加。

新架构选择

Stripe选择了Amazon Managed Prometheus (AMP)和Grafana作为新的解决方案，旨在提供更高的容量和成本效益。新架构包括多个组件，计算主机和Kubernetes集群收集的指标被传送到聚合层，聚合层和Amazon CloudWatch的指标通过Egress Proxy被摄入Amazon Managed Prometheus。同时，聚合和非聚合的指标也被发送到旧的时间序列数据库以支持迁移。

迁移过程

Stripe与AWS合作，将迁移过程分为四个阶段：

1. 双写指标：开始时在旧和新存储解决方案中双写指标，并创建全面的单元测试来验证数据流。
2. 资产转换：自动化转换旧资产定义（警报和仪表盘）到新格式（PromQL、AlertManager和Grafana），并推广使用模板模块以提高监控覆盖和一致性。
3. 验证新架构：使用promtool创建自动化单元测试，并对独特的警报进行人工审查。还开发了启发式方法来解决旧解决方案中的错误警报，并在必要时进行人工审查。
4. 用户采用：在工程师用户中推广新解决方案，强调验证工作流的重要性和迁移用户心智模型的影响。

关键教训

Stripe团队总结了迁移过程中的关键教训，包括：

• 需要让技术写作和开发者教育社区参与迁移过程。
• 避免为了达成指标而匆忙进行迁移和推广。
• 采用个性化教育方法，培养本地专家，以在教育更广泛的用户群体时产生乘数效应。

总结

Stripe通过迁移到基于AWS托管服务的可观测性平台，成功解决了扩展性、可靠性和成本问题。迁移过程注重验证和用户教育，确保了新平台的顺利采用。