Scalefastr 访谈
2018年2月8日作者 Brian Brazil
在我们对 Prometheus 用户进行的一系列访谈中，Scalefastr 的 Kevin Burton 讲述了他们如何使用 Prometheus。
您能介绍一下自己以及 Scalefastr 的业务吗？
我叫 Kevin Burton，是 Scalefastr 的首席执行官。我的背景是分布式系统，之前运营过 Datastreamer，这是一家构建了 PB 级分布式社交媒体爬虫和搜索引擎的公司。
在 Datastreamer，我们遇到了基础设施的可扩展性问题，并构建了一个基于 Debian、Elasticsearch、Cassandra 和 Kubernetes 的高性能集群。
我们发现许多客户也在基础设施方面苦苦挣扎，我对他们在 AWS 和 Google Cloud 上托管大量内容所支付的费用感到惊讶。
我们不断评估在云端运行的成本，对我们来说，托管成本大约是我们目前支付的 5-10 倍。
我们决定推出一个基于开源和云原生技术的新云平台，如 Kubernetes、Prometheus、Elasticsearch、Cassandra、Grafana、Etcd 等。
我们目前正在托管一些 PB 级客户，并计划在本月软发布我们的新平台。
您在使用 Prometheus 之前的监控经验如何？
在 Datastreamer，我们发现指标是我们快速迭代能力的关键。我们欣然接受了对平台的可观测性，并集成了诸如 Dropwizard Metrics 等工具，以便轻松为我们的平台开发分析功能。
我们构建了一个基于 KairosDB、Grafana 和我们自己（简单的）可视化引擎的平台，它在相当长一段时间内运行得非常好。
我们发现 KairosDB 的主要问题是 Prometheus 的采用率和客户需求。
此外，Prometheus 的优点在于它支持由项目本身或社区实现的 Exporter。
使用 KairosDB 时，我们经常难以构建自己的 Exporter。与 Prometheus 相比，KairosDB 的 Exporter 已经存在的可能性相当低。
例如，KairosDB 支持 CollectD，但它在 Debian 中支持得不好，而且 CollectD 存在实际的 bug，使其无法在生产环境中可靠运行。
使用 Prometheus，您可以非常快速地启动和运行（系统相当容易安装），并且为您的平台准备好 Exporter 的可能性非常高。
此外，我们预计一旦有像 Scalefastr 这样将其作为标准化和受支持产品集成的托管平台，客户应用程序将开始标准化使用 Prometheus 指标。
对应用程序性能的可见性至关重要，而 Prometheus 的高可扩展性是实现这一目标所必需的。
您为什么决定关注 Prometheus？
我们最初很好奇其他人是如何监控他们的 Kubernetes 和容器应用程序的。
容器的主要挑战之一是它们可以快速创建和销毁，留下需要分析的日志和指标数据。
当我们看到人们在生产环境中成功地将 Prometheus 与容器优先架构结合使用，并且它支持 Exporter 和仪表盘时，我们清楚地认识到应该将 Prometheus 作为我们的分析后端进行研究。
你们是如何过渡的？
由于 Scalefastr 是一个全新的环境，所以对我们来说，过渡过程相对顺利。
大部分架构是全新的，限制因素很少。
我们的主要目标是在裸机上部署，并在现有标准化硬件之上构建云功能。
我们的想法是让集群中的所有分析都由 Prometheus 提供支持。
我们为客户提供他们自己的“管理”基础设施，其中包括 Prometheus、Grafana、Elasticsearch 和 Kibana，以及一个 Kubernetes 控制平面。我们使用 Ansible 来编排这个系统，Ansible 负责初始机器设置（ssh、核心 Debian 包等）和基线配置。
然后，我们部署 Prometheus、客户配置所需的所有 Exporter，以及 Grafana 的仪表盘。
我们发现一个问题是 Grafana.com 上的一些仪表盘是为 Prometheus 1.x 编写的，并且无法干净地移植到 2.x。事实证明，2.x 系列中只有少数功能缺失，其中许多只需要进行一些小调整。此外，一些仪表盘是为早期版本的 Grafana 编写的。
为了帮助解决这个问题，我们本周宣布了一个项目，旨在 标准化和改进 Prometheus 仪表盘，用于 Cassandra、Elasticsearch、操作系统以及 Prometheus 本身等工具。我们上周开源了该项目并 发布到了 Github 上。
我们希望这能让其他人更容易地迁移到 Prometheus。
我们希望改进的一点是自动将其与我们的 Grafana 后端同步，并将这些仪表盘上传到 Grafana.com。
我们还发布了我们的 Prometheus 配置，以便标签与我们的 Grafana 模板正确配合。这使您可以通过下拉菜单选择更具体的指标，如集群名称、实例名称等。
切换后您看到了哪些改进？
部署简便、高性能和标准化的 Exporter 使我们能够轻松切换。此外，后端相当容易配置（基本上就是守护进程本身），而且没有太多活动部件，这使得做出决策变得容易。
您认为 Scalefastr 和 Prometheus 的未来会怎样？
目前我们正在将 Elasticsearch 和 Cassandra 直接部署在裸机上。我们正在努力将它们直接在 Kubernetes 之上的容器中运行，并致力于使用容器存储接口 (CSI) 来实现这一点。
在此之前，我们需要让 Prometheus 的服务发现功能正常工作，这是我们尚未尝试过的。目前我们通过 Ansible 部署和配置 Prometheus，但很明显，随着我们的工作负载变化，容器会不断创建和销毁，这种方式无法与 Kubernetes 很好地扩展（甚至无法正常工作）。
我们还在努力改进标准仪表盘和告警功能。我们希望添加的一个功能（也许作为容器）是支持基于 Holt-Winters 预测的告警。
这实质上将使我们能够在严重的性能问题发生之前进行预测。而不是等到发生故障（比如磁盘空间不足）之后才采取纠正措施。
在一定程度上，Kubernetes 有助于解决这个问题，因为我们可以根据水位线向集群添加节点。一旦资源利用率过高，我们就可以自动扩容。
我们对 Prometheus 的未来感到非常兴奋，特别是现在我们正在推进 2.x 系列，并且 CNCF 的合作似乎进展顺利。