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 环中存储用户数据，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  上共享。