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