这是 Prometheus 用户系列访谈的第一篇，旨在让他们分享评估和使用 Prometheus 的经验。我们的第一位受访者是来自 Life360 的 Daniel。
您能介绍一下您自己以及 Life360 的业务吗？
我是 Daniel Ben Yosef，别名 dby，我是 Life360 的基础设施工程师，在此之前，我从事系统工程工作已有 9 年。
Life360 创建技术帮助家庭保持联系，我们是面向家庭的家庭网络应用程序。我们非常忙碌地服务这些家庭——高峰期我们每分钟处理 70 万次请求，服务 7000 万注册家庭。
我们在生产环境中管理大约 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（包含我们自己贡献的添加认证头的功能）的 Exporter。
切换后您看到了哪些改进？
可见性和可观测性（instrumentation）的提升是我们首先看到的。就在切换之前，我们开始遇到 Graphite 的可伸缩性问题，而用 Prometheus 作为 Graphite 的原地替换，让利益相关者可以继续使用 Grafana 作为监控工具，这对我们来说非常有价值。如今，我们正专注于利用所有这些数据来检测异常，这些异常最终将成为 Alert Manager 中的警报。
您认为 Life360 和 Prometheus 的未来会怎样？
目前，我们有一个项目直接使用 Prometheus 客户端进行插桩（instrumented），这是一个基于 Python 的服务。随着我们构建新的服务，Prometheus 正在成为我们进行可观测性插桩的首选工具，这将帮助我们获得关于基础设施的非常有意义的警报和统计数据。
我们期待与项目共同成长并继续贡献。
谢谢 Daniel！Life360 仪表盘的源代码已在 Github 上分享。