采访 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 社区拥有丰富的经验，因此关注另一个 CNCF 社区——Prometheus 是顺理成章的选择。

你们是如何过渡的？

我们知道，我们要从将 Prometheus 与我们的 API 网关集成开始。我们的 API 网关使用 Envoy 进行代理，Envoy 会自动使用 statsd 协议发布指标。我们安装了 Prometheus Operator（详细说明参见此处 ），并配置它开始从 Envoy 收集统计数据。我们还基于另一位 Ambassador 贡献者的工作成果 建立了一个 Grafana 仪表盘。

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

我们的工程师现在可以洞察 L7 流量。我们还能够利用 Prometheus 比较金丝雀发布中的延迟和吞吐量，从而让我们更有信心确保新版本的服务不会导致性能下降。

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

使用 Prometheus Operator 仍然有点复杂。我们需要为我们的服务团队找出最佳运维实践（什么时候部署一个 Prometheus？）。然后，我们需要向工程师普及这些最佳实践，并培训他们如何配置 Operator 以满足其需求。我们预计在摸索出哪些方案可行、哪些不可行时，这一领域还需要进行一些实验。