随着在 Kubernetes 上运行的微服务的不断增加，PayIt 转向 Grafana 和 Prometheus 以实现云原生规模的可观察性。

倍增问题

PayIt 使用基于微服务的架构，是 Kubernetes 的早期采用者之一，自 2015 年以来一直在使用它进行容器编排。

在创业阶段的初期，PayIt 只有一个 Kubernetes 集群，这使得基础设施团队很容易手动监控所有内容。

对于应用程序开发人员来说，情况也是类似地简单。在应用程序每天只有 5 个交易的情况下，日志中的杂乱信息很少，使得服务日志和文件很容易找到。

但是，随着 PayIt 业务的扩展和公司推出更多服务，传统的做法变得不再有效。当一个集群中的一百个服务变成了两个集群中的一百个服务时，简单的查询就成为了过去。PayIt 基础设施平台工程团队的工程师 Matt Beers 解释说：“我们遇到了一个倍增问题。” 因此，PayIt 团队无法轻松地知道下游服务是否会影响上游的另一个服务，也无法查询信息来了解情况。

随着服务的增加，解决用户面临的问题也变得越来越具有挑战性，尤其是在数据流量在一天中变化的情况下。在那时，他们建立了一个自建系统来监控警报，并将其发布到 Slack，但这通常比有用更令人困惑。Slack 警报只表明文件处于不健康状态，但没有在文件恢复到健康状态后发出“正常”警报。PayIt 维护团队的软件工程经理 Matt Menzenski 说：“我们会收到两个文件的警报，然后看到稍后的警报只针对一个文件，我们必须据此推断出第二个文件已经恢复到‘正常’状态。” “有了 Grafana 仪表盘，我们就不需要推断任何东西，所有信息都一目了然地显示出来。”

一个大问题：他们如何将噪音转化为信号，并获得可观察性，以了解他们复杂系统中真正发生的情况？

众多的优势

PayIt 从一开始就是云原生的，一直在寻找云原生的解决方案。考虑到这一点，该团队寻找一个工具，该工具能够提供基础设施级别的可视性，并且由于 PayIt 是一家初创公司，因此该工具还必须具有成本效益。他们想要一个能够让开发人员在诊断问题时进行更多自助服务的解决方案，并且该解决方案必须是可配置的，并且可以轻松部署到他们现有的基础设施中。

他们的解决方案：Grafana 和 Prometheus.

他们喜欢这种组合的一个主要原因是：“这是一个大型社区支持的 Kubernetes 模型，”Beers 解释说。

当我们构建云原生应用程序时，我们期望服务器是不可变的，如果服务器处于不良状态，它们就会消失并被替换。像 Grafana 和 Kubernetes 这样的云原生工具可以开箱即用地解决这个问题。

Matt Beers，工程师，基础设施平台工程团队，Payit

这意味着能够支持云原生规模。截至 2021 年初，该公司的规模已扩展到 9 个 Kubernetes 集群（每个集群有 6 到 21 个节点），每个集群都有自己的 Prometheus-Grafana 集群。他们每天产生大约 4500 万条日志，这意味着每天大约有 40 到 50GB 的数据被接入。

利用社区仪表盘生态系统

PayIt 目前有 36 个 Grafana 仪表盘，包含数百个面板。其中大约一半是基于 Kubernetes 的（集群监控、Pod 监控、工作流、工作负载、控制平面监控）。其他仪表盘涵盖 Java 服务、节点服务和指标。该团队通过利用现有的 社区仪表盘快速上手使用 Grafana。Beers 说：“这些仪表盘已经提供了所有数据，并从 API 服务器以及我们所需的一切中汇总了所有指标。”

例如，Menzenski 使用一个社区模板，发现使用 Node Prometheus 客户端库来创建仪表盘以公开 Prometheus 度量指标端点“非常容易”。它只用了大约半个小时就运行起来了，一旦数据可用，他就能从将要使用它的团队那里获得即时的反馈。他们的反应是：“这太棒了。这正是我们能够在生产环境中运行此服务所需要的。”

Menzenski 真正地欣赏它的快速整合，他指出，作为一个非 Node.js 开发人员，他将花费大部分时间来自己构建它。因为创建 Grafana 仪表盘不需要特殊技能，因此在开发环境中，PayIt 的任何人都可以以管理员身份登录，并 使用 JSON 创建仪表盘.

因此，PayIt 能够构建一些针对特定业务需求定制的仪表盘。其关键仪表盘之一有助于在客户每天的数据文件交付（例如，关于市政账单余额的每日报告）上进行警报。Menzenski 说：“如果该文件没有到达，那将是坏消息。” “这意味着我们的余额可能过时了，或者付款将不会反映在客户系统中，这意味着糟糕的公民体验。”

Menzenski 说，当他们意识到可以将现有数据可视化，使其对非工程师更易理解时，他们“真正地恍然大悟”。与过去不得不依赖他们从头开始拼凑起来的不可靠、嘈杂的 Slack 警报系统相比，他们现在拥有了一种清晰、标准化和系统化的方式来可视化正常状态，直接看到它，并采取主动措施来修复问题。

Grafana 还帮助 PayIt 改善了客户体验。其中一个仪表板包含来自 PayIt 消息服务的队列，该服务向用户发送电子邮件，提醒他们即将到期的账单或确认其相关付款。由于警报，PayIt 团队能够在服务开始发送可能会让客户困惑（和恼火）的重复电子邮件之前发现问题。在政府服务的业务中，确保与公众清晰一致的沟通，可以提升急需的公众信任。

“这让我很高兴我们现在拥有了这些数据，” Menzenski 说。

现在有了集中化的可观测性解决方案，当 Payit 在一项服务中识别出问题时，他们可以使用这些信息对其他服务进行更改，以避免将来出现类似的问题。

丰厚的回报

借助 Grafana，PayIt 不仅可以捕获和防止这些面向客户的问题，还可以将它们化解。

在公司内部，任何拥有 PayIt 邮箱的人都可以被认证查看仪表板。因此，包括支持团队在内的非工程师都可以访问数据，因此在支持问题期间，不再需要等待维护团队——这将可能成为客户体验的瓶颈。

一个很方便的例子是，当客户付款后没有立即收到收据，于是他们打电话给客户支持。代表可以查看仪表板，看到积压情况，然后告诉他们很快就会收到收据。使用他们之前的、手动可观测性解决方案，支持团队不可能处理这个问题。维护团队将被这些请求淹没，无法继续为公司创新新的工具和系统。

能够管理谁获取数据以及何时获取数据的能力也为基础设施团队带来了回报。Beers 说，如果有人在某个环境中报告问题，基础设施团队的第一步是将他们重定向到 Grafana 或其中一个日志提供商，尝试收集尽可能多的数据，然后再联系更大的团队。

能够使用 Grafana 收集和可视化多个环境中的数据的另一个好处是，他们可以在事件发生后回溯以查找趋势。“能够比较和对比这些指标真的很酷，” Beers 说。

Grafana 帮助 PayIt 维持了其需要不断发展业务的以客户为中心的工程文化，但他指出，它也对工程专业发展产生了影响。“我们不再需要让工程师独自费力地浏览日志文件，而是可以为他们提供一个更符合行业标准的框架，帮助他们了解如何调试应用程序和复杂系统。”

采用 Grafana 也让他们有机会赋能新成立的团队。当 PayIt 建立了一个名为客户运营的新非工程团队（由两名客户成功团队成员组成）时，该团队被授予访问 Grafana 仪表板的权限，以便在日常运营问题上与客户互动。这使工程师能够专注于真正需要他们专业知识的工作。现在，如果文件交付问题再次出现，例如，客户成功团队可以带着时间戳直接与客户联系，让他们知道哪些内容丢失——甚至解释发生了什么问题。

“拥有触手可及的数据，会让这次对话走向完全不同的方向，” Menzenski 补充说。

缓存和检查

总的来说，Grafana 帮助 PayIt 的团队更好地定位和理解问题及其范围，因为他们可以从一个地方看到所有内容。

它还让他们通过查看某些服务对其他服务的影响，了解了某些服务的的重要性。他们面临挑战的一个特定领域是缓存。“我们可以查看响应时间的百分位数，以查看对系统的影响，” Beers 说。“这种级别的可观测性真正突出了这些特定服务的关键性，因为它们有许多消费者。如果它们出了问题，整个平台就会开始出现问题。”

有一次，他们发现其 Web 应用程序调用出现的问题与支付服务调用出现的问题类似。经过数人对仪表板进行深入研究后，他们能够发现多个峰值和瓶颈，并意识到这些问题是相关的，并影响了所有人。由于他们的 集中式可观测性平台，他们在一次电话会议中仅用了一个小时就找到了问题，而如果没有 Grafana，他们可能需要花费几个小时、多个战情室，以及太多的人来关联不同的数据集。

Menzenski 说，Grafana 仪表板提供的可视化是不可或缺的。没有它，他们可能会错过有价值的信息。

这就像所有的信号，没有噪音。你调用 Grafana，它只显示你想要的内容，这真的很棒。

Matt Menzenski，软件工程经理

展望未来

现在他们已经了解了 Grafana 可以为他们做些什么，PayIt 正在考虑更广泛的应用方式。

展望未来，Menzenski 希望与非工程利益相关者进行更多合作。他的目标是发现哪些数据点——以及他们尚未收集的指标——对他们在仪表板上拥有价值。“潜力巨大，” 他说。一个想法是创建一个仪表板，显示付款成功率与失败率。“如果某个特定服务出现错误激增，这对我们的客户集成团队来说可能非常有价值。”

PayIt 还针对其平台的新无代码版本，团队可以在其中无需工程师编写一行代码即可建立新的集成。“我们能否创建一些仪表板，以便在无需工程介入的情况下进行自助服务？” Menzenski 问道。“我们还有很多潜力尚未开发，我们才刚刚开始思考。我个人觉得，我对于这个工具的应用还只是触及了皮毛。”