需要避免的 7 个 API 可观察性反模式

本文探讨了API可观察性中的七个常见陷阱,包括忽视用户需求、过度依赖API监控、使用日志故障排除、工具和数据整合、针对不同架构的定制策略、预生产和API网关的追踪误区。作者强调了考虑用户和全链路追踪的重要性以提升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 架构有不同的需求,您的可观察性策略需要反映这一点,以提高应用程序的整体可靠性。

反模式:仅用于生产的可观察性

为什么不在预生产中使用可观察性?

通过在 API 开发生命周期中使用分布式跟踪,开发人员可以跟踪不同服务之间的请求和响应流,从而全面了解 API 在各种场景下的行为方式。

借助可观察性,他们可以识别性能瓶颈,甚至可以检测 GraphQL 查询中的 N+1 问题等架构问题。

对于利用 APIOps 实践的团队来说,可观测性数据可以用作将 API 推广到生产阶段之前的附加验证。

反模式:在 API 网关处启动跟踪被高估了

有关可观察性的教程通常从微服务级别开始检测过程。能够详细了解您的微服务真是太好了。但在处理 API 时,API 网关级别会发生很多事情。

您希望捕获所有用户事务,包括那些由于速率限制规则、身份验证问题或缓存机制而从未到达微服务的事务。

在 API 网关处启动跟踪可为您提供清晰的入口点和所有用户旅程的完整画面。这就是为什么使用内置 OpenTelemetry 支持的现代 API 网关非常重要。

现在您已经了解了:需要避免的七个 API 可观察性陷阱。让您的 API 易于观察,让您的用户满意!

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值