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 时，我们经常难以构建自己的导出器。相比 Prometheus，KairosDB 已经存在导出器的可能性相当低。
例如，KairosDB 支持 CollectD，但在 Debian 中支持不佳，并且 CollectD 存在实际的错误，导致它无法在生产环境中可靠地工作。
使用 Prometheus，您可以相当快地启动和运行（系统相当容易安装），并且您的平台有现成导出器的可能性相当高。
此外，我们预计客户应用程序将开始标准化 Prometheus 指标，一旦有了像 Scalefastr 这样的托管平台，将其集成到标准化和支持的产品中。
了解您的应用程序性能至关重要，而 Prometheus 的高可扩展性是实现这一点的必要条件。
你们为什么决定研究 Prometheus？
起初我们很想知道其他人是如何监控他们的 Kubernetes 和容器应用程序的。
容器的主要挑战之一是它们可以快速出现和消失，留下需要分析的日志和指标数据。
一旦我们看到人们在生产环境中使用 Prometheus，并结合了容器优先的架构——以及对导出器和仪表板的支持——我们便清楚应该将 Prometheus 作为我们的分析后端进行研究。
你们是如何过渡的？
对于我们来说，过渡是相对无痛的，因为 Scalefastr 是一个全新的环境。
架构在很大程度上是新的，限制因素非常少。
我们的主要目标是部署在裸机上，但要在现有和标准化的硬件之上构建云功能。
我们的想法是让集群中的所有分析都由 Prometheus 提供支持。
我们为客户提供自己的“管理”基础设施，包括 Prometheus、Grafana、Elasticsearch 和 Kibana，以及 Kubernetes 控制平面。我们使用 Ansible 来编排这个系统，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 一起工作），因为随着我们工作负载的变化，容器会不断出现和消失。
我们还在努力改进标准仪表板和警报。我们想添加的一项功能（可能是作为容器）是支持基于霍尔特斯冬季预测的警报。
这实际上将使我们能够在严重性能问题发生之前就预测到它们。而不是等到出现问题（例如磁盘空间不足）才采取行动纠正。
在某种程度上，Kubernetes 可以帮助解决这个问题，因为我们可以根据一个水位标记向集群添加节点。一旦资源利用率过高，我们就可以进行自动扩展。
我们对 Prometheus 的未来感到非常兴奋，特别是现在我们正在推进 2.x 系列，并且 CNCF 协作似乎也在顺利进行。