需要避免的 7 个 API 可观察性反模式-优快云博客

可观察性已经成为一个流行词，API 世界正在慢慢迎头赶上。但在查找有关 API 可观察性的内容时要小心 - 有许多过时的最佳实践和不相关的内容。

我最近受邀作为Stephen Townshend 的 SlightReliability 播客的嘉宾，他关于“糟糕的可观察性”的精彩博客文章激励我开始咆哮这个话题。

以下是我们讨论的后续内容：使用 API 时要避免的可观察性反模式。谢谢斯蒂芬的灵感！

反模式：你忘记了你的用户

人们很容易忽视 API 是为人们使用而构建的这一事实。API 不仅仅是一个技术接口；它们是连接数字体验并使人们能够高效完成任务的桥梁。

您的 API 有两种不同类型的用户：

将您的 API 集成到他们的系统中的开发人员。
您客户的用户，最终将与依赖您的 API 的应用程序或服务进行交互。

如果您无法理解它们如何与您的 API 交互，那么您就错过了一半。

当开发人员与您的 API 集成时，他们需要多长时间才能成功进行第一次 API 调用？哪些典型错误会拖慢他们的速度？可观察性在提供见解以改善开发人员体验方面发挥着重要作用。

一旦客户的应用程序或服务依赖于您的 API 投入生产，您能否跟踪您的版本如何影响他们的请求？他们使用哪个版本的 API？最流行的端点是什么？所有客户都获得相同的性能吗？错误率一样吗？

反模式：仅依赖 API 监控

API 监控通常涉及向 API 端点发送自动测试请求并验证响应。即使根本没有客户活动，它也可以帮助您跟踪 API 的运行状况，并可用于报告正常运行时间。

但API监控无非就是黑盒测试；你看不到里面发生了什么。您只知道您的请求到达 API 并接收响应，但您只能为某些可能的用例创建和维护测试。你会错过一些东西。

反模式：使用 API 访问日志进行故障排除

API 访问日志是对 API 发出的请求和响应的记录，捕获请求者的 IP 地址、HTTP 方法、请求的端点、状态代码和其他相关信息等详细信息，以用于监控、调试和安全目的。

使用访问日志来解决 API 问题就像在微服务大海捞针一样。我们的一位用户的 API 遇到了性能问题；他们花了几天时间使用访问日志寻找根本原因。是网关吗？需要更多的CPU吗？是配置问题吗？他们启用了分布式跟踪，几秒钟之内，他们就可以看到发生了什么：所有时间都花在了身份验证服务器发出 JWT 令牌上。

要真正了解系统中发生的情况，您需要能够跟踪从 API 网关到上游服务的单个用户请求及其依赖项，以便有效地进行故障排除。

正如Martin Thwaites 所说：“日志是穷人的观察工具。” 您需要分布式跟踪。

反模式：不同的团队、不同的工具、不同的数据

不同的团队有不同的需求。适用于您的 DevOps 团队的工具可能并不最适合您的产品团队。强迫每个人都使用相同的工具，不仅不会促进团结，反而会导致效率低下。

然而，虽然促进工具多样性可能对您的组织来说是正确的举措，但不同工具和数据源之间应该进行一些协调和集成。OpenTelemetry 等开放标准有助于确保信息可以在团队和工具之间共享和利用。

在评估最新推出的 API 产品的性能和可靠性时，DevOps 和产品团队应依赖相同的错误率。

反模式：一刀切

不同的 API 架构风格在可观察性方面有不同的需求。

REST API 可能是当今的默认 API，但GraphQL和 gRPC 等较新的样式正在变得越来越流行。这些风格中的每一种在可观察性方面都有独特的特征和要求。想想GraphQL 处理错误的方式，它与 REST API 显着不同。Web Socket 和事件驱动的 API 也有其独特的可观察性挑战。

不同的 API 架构有不同的需求，您的可观察性策略需要反映这一点，以提高应用程序的整体可靠性。