Life360 访谈

这是与 Prometheus 用户系列访谈的第一篇，旨在让他们分享评估和使用 Prometheus 的经验。我们的首次访谈对象是来自 Life360 的 Daniel。

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

我是 Daniel Ben Yosef，别名 dby，我是 Life360 的基础设施工程师，在此之前，我担任了9年的系统工程职位。

Life360 致力于开发帮助家庭保持联系的技术，我们是家庭专用的家庭网络应用程序。我们非常忙碌地为这些家庭提供服务——高峰期我们每分钟处理 70 万个请求，服务于 7000 万注册家庭。

我们在生产环境中管理大约 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 上分享。