继续我们的 Prometheus 用户访谈系列，Scalefastr 的 Kevin Burton 将会谈论他们如何使用 Prometheus。
您能介绍一下您自己以及 Scalefastr 是做什么的吗？
我叫 Kevin Burton，是 Scalefastr 的 CEO。我的背景是分布式系统，之前我运营过 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 的优点在于对由项目本身或社区实施的 exporters 的支持。
对于 KairosDB，我们经常努力构建我们自己的 exporters。与 Prometheus 相比，已经存在 KairosDB 的 exporter 的可能性相当低。
例如，KairosDB 有 CollectD 支持，但它在 Debian 中不受很好的支持，并且 CollectD 存在实际的错误，阻止其在生产环境中可靠地工作。
使用 Prometheus，您可以非常快速地启动并运行（系统非常容易安装），并且您的平台很有可能已经准备好了一个 exporter。
此外，我们预计客户应用程序将开始标准化 Prometheus 指标，一旦有像 Scalefastr 这样的托管平台将其作为标准化和受支持的产品集成。
了解您的应用程序性能至关重要，而 Prometheus 的高可扩展性是实现这一目标所必需的。
您为什么决定关注 Prometheus？
最初我们很好奇其他人是如何监控他们的 Kubernetes 和容器应用程序的。
容器的主要挑战之一是它们可以快速来去，留下需要分析的日志和指标数据。
当我们看到人们成功地在生产环境中使用 Prometheus 以及容器优先的架构，以及对 exporters 和仪表板的支持时，我们清楚地意识到我们应该将 Prometheus 作为我们的分析后端进行研究。
您是如何过渡的？
对于我们来说，过渡相当轻松，因为 Scalefastr 是一个全新的环境。
在很大程度上，该架构是新的，限制因素非常少。
我们的主要目标是在裸机上部署，但在现有和标准化的硬件之上构建云功能。
我们的想法是将我们集群中的所有分析都由 Prometheus 支持。
我们为客户提供他们自己的“管理”基础设施，其中包括 Prometheus、Grafana、Elasticsearch 和 Kibana 以及 Kubernetes 控制平面。我们使用 Ansible 编排这个系统，Ansible 处理初始机器设置（ssh、核心 Debian 软件包等）和基线配置。
然后我们部署 Prometheus、客户配置所需的所有 exporters，以及 Grafana 的仪表板。
我们发现有点问题的是 Grafana.com 上的一些仪表板是为 Prometheus 1.x 编写的，并且没有干净地移植到 2.x。事实证明，2.x 系列中只缺少一些函数，其中许多函数只需要稍微调整一下。此外，一些仪表板是为早期版本的 Grafana 编写的。
为了帮助解决这个问题，我们本周宣布了一个项目，标准化和改进 Prometheus 的仪表板，用于 Cassandra、Elasticsearch、操作系统以及 Prometheus 本身。我们开源了这个项目，并在上周 发布到了 Github。
我们希望这能让其他人更容易迁移到 Prometheus。
我们想要改进的一件事是自动将其与我们的 Grafana 后端同步，以及将这些仪表板上传到 Grafana.com。
我们还发布了我们的 Prometheus 配置，以便标签可以与我们的 Grafana 模板正确地协同工作。这允许您使用下拉菜单来选择更具体的指标，如集群名称、实例名称等。
自从切换以来，您看到了哪些改进？
易于部署、高性能和标准化的 exporters 使我们能够轻松切换。此外，后端相当容易配置（基本上只是守护程序本身），并且没有太多移动部件，这使它成为一个容易做出的决定。
您认为 Scalefastr 和 Prometheus 的未来会怎样？
目前，我们直接在裸机上部署 Elasticsearch 和 Cassandra。我们正在努力直接在 Kubernetes 之上的容器中运行它们，并努力使用容器存储接口 (CSI) 使之成为可能。
在我们能做到这一点之前，我们需要让 Prometheus 服务发现工作起来，这是我们尚未尝试过的。目前我们通过 Ansible 部署和配置 Prometheus，但这显然无法随着 Kubernetes 扩展（甚至无法工作），因为容器会随着我们的工作负载变化而来来去去。
我们还在努力改进标准仪表板和警报。我们想要添加的功能之一（可能作为容器）是支持基于 holts winters 预测的警报。
这基本上使我们能够在严重的性能问题发生之前预测它们。而不是等到某些东西发生故障（例如磁盘空间不足）才采取行动纠正它。
在一定程度上，Kubernetes 帮助解决了这个问题，因为我们可以根据水位线向集群添加节点。一旦资源利用率过高，我们就可以自动扩展。
我们对 Prometheus 的未来感到非常兴奋，特别是现在我们正在 2.x 系列上取得进展，并且 CNCF 协作似乎进展顺利。