PayIt随着运行在 Kubernetes 上的微服务数量不断增加，PayIt 转向 Grafana 和 Prometheus 以实现云原生规模的可观测性
倍增问题
PayIt 采用微服务架构，是 Kubernetes 的早期使用者，自 2015 年起就将其用于容器编排。
在初创阶段（他们开始使用 Grafana 之前），PayIt 只有一个 Kubernetes 集群，基础设施团队可以很容易地手动监控一切。
对应用开发者来说，事情同样不复杂。那时候应用一天只有五笔交易，日志混乱度极低，服务日志和文件很容易找到。
但随着 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 服务、Node 服务和指标。团队通过利用现有的社区仪表盘，使用 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 说：“能够比较和对比这些类型的指标真是太棒了。”
Beers 指出，Grafana 帮助 PayIt 维持了其业务持续增长所需的以客户为中心的工程文化，同时也在影响工程师的职业发展。“不必让工程师独自辛苦地处理日志文件，我们可以为他们提供一个更符合行业标准的框架，帮助他们理解如何调试应用和复杂系统。”
采用 Grafana 还为他们赋能新成立的团队提供了机会。当 PayIt 成立了一个新的非工程团队——客户运营团队（由两名客户成功团队成员组成）时，该团队获得了访问 Grafana 仪表盘的权限，用于处理日常运营中与客户沟通的问题。这使得工程师能够专注于真正需要他们专业知识的工作。现在，如果那个文件交付问题再次出现，例如，客户成功团队可以直接带着时间戳去找客户，告诉他们缺少了什么，甚至可以解释哪里出了问题。
“数据触手可及，让沟通完全不一样了，” Menzenski 补充道。
缓存和检查
总的来说，Grafana 帮助 PayIt 的团队更好地定位和理解问题及其范围，因为他们可以在一个地方查看所有信息。
通过查看某些服务对其他服务的影响，他们也更深刻地认识到这些服务的重要性。他们面临挑战的一个特定领域是缓存。Beers 说：“我们可以查看响应时间的百分位，看看在系统中产生了什么连锁反应。”他继续说，“这种程度的可观测性真正突显了这些特定服务的关键性，因为它们有很多使用者。如果它们出了问题，那么整个平台就会开始出现问题。”
有一次，他们发现来自 Web 应用的调用问题与来自支付服务的调用问题类似。在几个人深入研究仪表盘后，他们能够发现多个峰值和瓶颈，并意识到这些问题是相互关联且影响着所有人。得益于他们的集中式可观测性平台，通过一次一小时的电话会议就找到了问题，而如果他们没有 Grafana 来关联分散的数据集，可能需要数小时、多个会议室以及过多的人力。
Menzenski 说，Grafana 仪表盘提供的可视化功能是不可或缺的。没有它，他们可能会错过有价值的信息。
这就像全是信号，没有噪音。你打开 Grafana，它只会展示你想要看的内容，这太棒了。
Matt Menzenski，软件工程经理
展望未来
现在他们知道了 Grafana 对他们有什么帮助，PayIt 正在考虑更广泛地使用它。
展望未来，Menzenski 希望与非工程领域的利益相关者有更多合作。他的目标是发现哪些数据点（以及他们尚未收集的哪些指标）对于在仪表盘上展示会很有价值。他说：“潜力巨大。”一个想法是创建一个仪表盘，显示支付成功率与失败率。“如果某个特定服务的错误出现峰值，这对于我们的客户集成团队来说可能非常有价值。”
PayIt 还在开发其平台的新无代码版本，团队可以在不让工程师写一行代码的情况下建立新的集成。Menzenski 想知道：“我们能否制作一些仪表盘，让您可以在不涉及工程团队的情况下自行上线？”他接着说，“我们才刚刚开始思考很多潜在的可能性。我个人觉得，我才刚刚触及这个工具能力的皮毛。”
