Datawire 访谈

我们继续对 Prometheus 用户的系列访谈，本期由来自 Datawire 的 Richard Li 讲述他们如何过渡到 Prometheus。

您能介绍一下您自己以及 Datawire 是做什么的吗？

在 Datawire，我们开发开源工具，帮助开发人员在 Kubernetes 上更快地编码。我们的项目包括用于 Kubernetes 服务本地开发的 Telepresence ；一个基于 Envoy Proxy  构建的 Kubernetes 原生 API 网关 Ambassador ；以及一个构建/部署系统 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 以满足他们的需求。我们预计这将是一个需要进行一些实验的领域，以找出哪些方法有效，哪些无效。