开云「中国」电子-官方网站

　　Prezi 的工程团队最近分享了他们从基于 Prometheus 的监控系统切换到 VictoriaMetrics 的经历，重点讲述了在成本优化、性能提升和架构简化方面的成果。这次转型使成本降低了约 30%，复杂查询的完成时间也从 30 多秒缩短至 3 - 7 秒。

　　Prezi 的高级站点可靠性工程师 Grzegorz Skołyszewski 在一篇 博客文章 中总结了这段历程。到 2024 年，Prezi 的 Prometheus 部署已经过时且成本高昂，它运行在一个已弃用的内部平台上，维护起来需要耗费大量资源。该团队希望通过降低系统复杂度、迁移到 Kubernetes 平台以及降低运营成本，实现指标收集和存储系统的现代化升级。

　　然而，现有的 Prometheus 系统存在诸多问题。由于其规模（拥有 500 万个活跃序列），资源需求极高；在管理用于仪表盘展示和警报功能的多个实例时十分复杂；并且还依赖老旧的基础设施。

　　为了解决这些问题，团队开始探索替代方案，对托管式和自托管式的解决方案都进行了评估。托管式方案因成本过高被排除，而像 Thanos、Cortex/Mimir 和 VictoriaMetrics 等自托管式方案则进入了考虑范围。最终，Prezi 工程团队选择了 VictoriaMetrics，因为它具有简单易用、成本效益高和性能优越等优势。

　　与其他依赖如 AWS S3 等对象存储的工具不同，VictoriaMetrics 使用块存储，这种存储方式成本更低且性能更好，还省去了外部缓存子系统。团队进行了概念验证，结果显示：之前在 Prometheus 中会超时的查询，在 VictoriaMetrics 中 3 - 7 秒就能完成，同时存储使用量降低了 70%，内存使用量降低了 60%，CPU 使用时间减少了 30%。

　　起初，团队在多个 AWS 可用区（AZ）中部署了 VictoriaMetrics 集群版本，以确保高可用性。但这种部署方式因跨可用区的网络流量，大幅增加了成本。每个指标的写入或查询操作，都需要在 VMInsert 和 VMStorage 等组件之间进行额外的跳转，增加了数据传输费用。为解决这个问题，他们将集群部署改为在不同可用区分别部署两个独立的 VictoriaMetrics Single 单实例。

　　团队引入了负载均衡器来实现故障转移冗余，并配置了代理在实例停机期间缓存数据，以防止数据丢失。这种架构在保持可靠性的同时，最大程度减少了跨可用区的流量。

　　团队还做了其他改进，以进一步优化系统。为了在不支付企业许可证费用或依赖 Grafana Cloud 等外部服务的情况下实现指标的长期存储，他们部署了另一个设置了自定义保留策略的 VictoriaMetrics Single 实例。

　　我们发现技术社区在 Hacker News 和 Reddit 上展开了有趣的讨论。Hacker News 上的讨论围绕云计算中跨可用区数据传输成本高昂的问题展开，有人认为这扭曲了最佳实践，也有人认为这种定价反映了扩展数据中心间带宽的成本。

　　在 Reddit 上，讨论聚焦于监控系统设计的权衡。一种观点警告说，远程写入系统会引入延迟，并依赖中央规则评估，在数据积压时存在故障风险。另一种观点则认为，与 Prometheus 这种有状态的系统相比，无状态代理结合延迟规则评估的方式在可扩展性、一致性和维护便利性上更具优势，而如何权衡则取决于用户的偏好。

　　这次迁移为 Prezi 的工程运营带来了显著的好处。除了降低成本和缩短查询时间外，借助 Kubernetes 原生工具，指标的获取也变得更加便捷。新系统在可扩展性和可靠性方面也有了提升，更能应对未来的业务增长。

　　开云电子网站 开云平台入口

　　Aditya Kulkarni，Aditya 近期一直担任具有技术敏锐度的交付负责人。他曾与多家企业合作，助力其踏上敏捷转型与 DevOps 变革之路。他热爱阅读，始终热衷于关注软件开发领域的最新动态！

　　开云电子 kaiyun网址