Datawire 访谈

继续我们关于 Prometheus 用户访谈的系列，来自 Datawire 的 Richard Li 谈论了他们如何过渡到 Prometheus。

你能介绍一下你自己以及 Datawire 做什么吗？

在 Datawire，我们开发开源工具，帮助开发人员更快地在 Kubernetes 上进行编码。我们的项目包括 Telepresence ，用于 Kubernetes 服务的本地开发；Ambassador ，一个基于 Envoy Proxy  构建的 Kubernetes 原生 API 网关；以及 Forge ，一个构建/部署系统。

我们在 AWS 中的 Kubernetes 中运行了许多任务关键型的云服务来支持我们的开源工作。这些服务支持诸如每天动态配置数十个 Kubernetes 集群之类的用例，然后这些集群被我们的自动化测试基础设施使用。

在使用 Prometheus 之前，您的监控体验是怎样的？

我们使用了 AWS CloudWatch。这很容易设置，但我们发现随着我们采用更分布式的开发模式（微服务），我们想要更多的灵活性和控制。例如，我们希望每个团队能够根据需要自定义他们的监控，而无需运营人员的帮助。

你们为什么决定研究 Prometheus？

我们有两个主要要求。第一个是我们希望这里的每位工程师都能对其服务拥有运营控制权和可见性。我们的开发模式在设计上是高度去中心化的，我们尽量避免工程师需要等待其他工程师才能完成某项工作的情况。对于监控，我们希望我们的工程师能够对他们的指标基础设施拥有很大的灵活性和控制权。我们的第二个要求是强大的生态系统。强大的生态系统通常意味着成熟的（且有文档记录的）最佳实践、持续的开发以及在您遇到困难时能够提供帮助的人员。

Prometheus，特别是 Prometheus Operator ，符合我们的要求。通过 Prometheus Operator，每个开发人员都可以根据需要创建自己的 Prometheus 实例，而无需运营人员的帮助（没有瓶颈！）。我们也是 CNCF  的成员，在 Kubernetes 和 Envoy 社区有丰富的经验，因此关注 Prometheus 的另一个 CNCF 社区是顺理成章的。

你们是如何过渡的？

我们知道我们想从与我们的 API 网关集成开始。我们的 API 网关使用 Envoy 进行代理，Envoy 使用 statsd 协议自动发出指标。我们安装了 Prometheus Operator（一些详细笔记 在这里 ）并对其进行配置以开始收集 Envoy 的统计信息。我们还设置了一个 Grafana 仪表板 基于另一位 Ambassador 贡献者的工作 。

切换后你们看到了哪些改进？

我们的工程师现在可以看见 L7 流量。我们还能够使用 Prometheus 来比较我们的金丝雀部署的延迟和吞吐量，这使我们更有信心新版本的服务不会导致性能回归。

你认为 Datawire 和 Prometheus 的未来会怎样？

使用 Prometheus Operator 仍然有点复杂。我们需要为我们的服务团队弄清楚运营最佳实践（什么时候部署 Prometheus？）。然后我们需要向我们的工程师传授这些最佳实践，并培训他们如何配置 Operator 以满足他们的需求。我们预计这将是一个充满实验的领域，因为我们会摸索出什么有效，什么无效。