我们继续推出 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 社区是很自然的。
您是如何过渡的？
我们知道我们想从将 Prometheus 与我们的 API 网关集成开始。我们的 API 网关使用 Envoy 进行代理，Envoy 会自动使用 statsd 协议发送指标。我们安装了 Prometheus Operator（一些详细的说明 在此），并将其配置为开始从 Envoy 收集统计信息。我们还基于另一位 Ambassador 贡献者的一些工作，设置了一个 Grafana 仪表板 在这里。
自从切换后，您看到了哪些改进？
我们的工程师现在可以查看 L7 流量。我们还能够使用 Prometheus 来比较金丝雀部署的延迟和吞吐量，从而使我们更有信心新版本的服务不会导致性能下降。
您认为 Datawire 和 Prometheus 的未来会怎样？
使用 Prometheus Operator 仍然有点复杂。我们需要为我们的服务团队找出运营最佳实践（何时部署 Prometheus？）。然后，我们需要就这些最佳实践对我们的工程师进行教育，并培训他们如何配置 Operator 以满足他们的需求。我们预计这将是一个实验性的领域，因为我们需要弄清楚哪些有效，哪些无效。