这是 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（我们自己贡献了添加身份验证标头）添加了 exporters。
自从切换以来，您看到了哪些改进？
可见性和仪表盘的提升是我们首先看到的。在切换之前，我们开始遇到 Graphite 的可扩展性问题，并且有一个现成的 Graphite 替代品，以便利益相关者可以继续使用 Grafana 作为监控工具，这对我们来说非常有价值。现在，我们正专注于获取所有这些数据，并用它来检测异常，这些异常最终将成为 Alert Manager 中的警报。
您认为 Life360 和 Prometheus 的未来会怎样？
我们目前有一个项目直接使用 Prometheus 客户端进行仪表化，这是一个基于 Python 的服务。随着我们构建新的服务，Prometheus 正在成为我们仪表化的首选，并将帮助我们获得关于我们基础设施的非常有意义的警报和统计数据。
我们期待与该项目共同成长并继续做出贡献。
谢谢 Daniel！Life360 仪表盘的源代码在 Github 上共享。