Life360 采访

这是 Prometheus 用户系列访谈的第一篇，旨在分享用户评估和使用 Prometheus 的经验。我们的首位受访者是来自 Life360 的 Daniel。

你能介绍一下你自己以及 Life360 的业务吗？

我是 Daniel Ben Yosef，别名 dby，是 Life360  的基础设施工程师。在此之前，我在过去 9 年里一直担任系统工程方面的工作。

Life360 开发的技术旨在帮助家庭保持联系，我们是家庭领域的专属网络应用。处理这些家庭连接任务相当繁忙——高峰期我们为 7000 万注册家庭提供每分钟 70 万次的请求处理。

我们在生产环境中管理着大约 20 个服务，主要处理来自移动客户端（Android、iOS 和 Windows Phone）的位置请求，高峰期跨越 150 多个实例。冗余和高可用性是我们的目标，我们尽可能保持 100% 的正常运行时间，因为家庭信任我们的可用性。

我们的用户数据存储在 MySQL 多主集群和 12 节点的 Cassandra 环中，后者始终承载着大约 4TB 的数据。我们有使用 Go、Python 和 PHP 编写的服务，并计划在技术栈中引入 Java。我们使用 Consul 进行服务发现，当然，我们的 Prometheus 配置也与它进行了集成。

在使用 Prometheus 之前，您的监控体验是怎样的？

在切换到 Prometheus 之前，我们的监控系统包含许多组件，例如：

• Copperegg (现为 Idera)
• Graphite + Statsd + Grafana
• Sensu
• AWS Cloudwatch

我们主要使用 MySQL、NSQ 和 HAProxy，我们发现上述所有监控解决方案都非常片面，需要大量的定制工作才能使它们协同工作。

你们为什么决定研究 Prometheus？

我们切换到 Prometheus 有几个原因，其中之一就是我们需要更好的监控。

我们关注 Prometheus 已经有一段时间了，一直在跟踪并阅读关于其活跃开发的信息。在某个时间点（几个月前），我们决定开始评估将其用于生产环境。

概念验证（PoC）的结果令人难以置信。MySQL 的监控覆盖范围非常棒，我们也喜欢 Cassandra 的 JMX 监控，这在过去是非常缺乏的。

你们是如何过渡的？

我们最初使用了一个相对较小的机器（4GB 内存）作为起点。它对于少量服务是有效的，但无法满足我们全面的监控需求。

我们最初也是用 Docker 部署的，但后来逐渐迁移到了独立的 r3.2xl 实例（60GB 内存）上，这台机器能满足我们所有的服务监控需求，并能存储 30 天的内存数据。

我们开始逐步为所有主机引入 Node Exporter 并构建 Grafana 图表，直到实现了全面的服务覆盖。

我们当时也考虑过使用 InfluxDB 进行长期存储，但由于最近的事态发展 ，这可能不再是一个可行的选择。

随后我们添加了 MySQL、Node、Cloudwatch、HAProxy、JMX、NSQ（结合我们自己的部分代码）、Redis 和 Blackbox（我们贡献了代码以添加身份验证头）的导出器。

切换后你们看到了哪些改进？

可见性和仪表化的提升是我们看到的第一点。在切换之前，我们开始遇到 Graphite 的可扩展性问题，而拥有一个可以直接替换 Graphite 的方案，使得利益相关者可以继续使用 Grafana 作为监控工具，这对我们非常有价值。如今，我们专注于获取所有数据并利用它们进行异常检测，最终这些检测将转化为 Alert Manager 中的警报。

你认为 Life360 和 Prometheus 的未来会怎样？

我们目前有一个项目直接集成了 Prometheus 客户端，这是一个基于 Python 的服务。随着我们构建新服务，Prometheus 正在成为我们仪表化的首选，并将帮助我们获取关于基础设施非常有意义的警报和统计数据。

我们期待与该项目共同成长，并继续做出贡献。

谢谢你，Daniel！Life360 的仪表盘源代码已在 Github  上共享。