这是 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 上分享。