API监控：你应该衡量什么？

来源：https://blog.zhangbing.site/

在监控第三方API和Web服务时，监控的内容与监控的方式一样重要。数据是有用的，但可操作的数据才是真正的价值所在。下面我们列出了在依赖第三方API集成和Web服务时，需要监控的最常见、最有价值的指标。准确的监控和警报可以为你的企业提供决策所需的数据，以决定使用哪些API，如何构建弹性应用程序以及将精力集中在何处。

当你开始监视API或Web服务时，以下是我们推荐的指标：

文章目录

延迟
响应时间
可用性
消费量
故障率
状态码
结束

延迟

延迟是指消息在“线上”花费的时间。这里，数字越短越好。延迟可能是由你的服务器和API服务器之间的连接引起的，它也可能是由你的服务器和API服务器之间发生的延迟造成的。这可能是网络流量或资源过载的结果，在这种情况下节流请求可能会适应重载。

为了监控延迟，Web服务需要跟踪发出和传入请求的时间戳，并在给定时间内与过去和未来的请求进行比较。这仍然很棘手，因为来自服务器的响应也将受到响应时间的影响，如果可用，ping端点或调用健康检查端点可能是接收准确延迟估计的最佳方式。

这种评估在对服务器进行地理定位时很有用，通过确定最低的延迟，你的企业可以决定选择哪个供应商。如果确定延迟是导致响应延迟的真正原因，还可以选择特定的区域提供商服务，或者如果资源的响应时间是问题所在，则可以选择不同的提供商。在实际实践中，等待时间和响应时间通常会合并为一个值。

响应时间

响应时间是指服务响应一个请求所需的时间。这可能更难用第三方API和Web服务来跟踪，因为发送和接收数据的延迟是响应时间的一部分。你可以通过比较给定API上多个资源的响应时间来估计响应时间，由此，你可以估计API服务器和你的服务器之间的共享延迟，并确定真正的价值。

响应时间直接影响应用程序的性能，API响应的延迟将导致用户交互变慢。你可以通过确保你所选择的API提供商有响应时间保证，或者通过实施在检测到尖峰时使用后备API或缓存资源的解决方案来避免这种情况。

可用性

API的可用性可以描述为停机时间或正常运行时间。两者都基于相同的数据，但根据上下文可能会有不同的说法。

可用性可能是最容易跟踪的指标。停机错误是可以识别的，有时API提供商会宣布预定的停机。但是，即使是最可靠的API也会遇到无法预料的停机时间。停机时间可以表示为单个事件，也可以表示为给定时期的总体平均值。虽然在评估API提供商时，停机配额和诸如“99.999%正常运行时间”之类的保证很有价值，但即使是最小的停机时间也可能对你的应用程序产生很大影响。

许多API依赖于外部提供商，如亚马逊网络服务（AWS）、微软Azure和谷歌云服务。因此，现在个别网络服务提供商的停机时间也依赖于你的应用不直接与之进行业务往来的第三方。即使 API 提供商的服务按预期运行，第三方也可能不会。因此，当出现较大的宕机时间时，你将希望有一个备用程序，它不依赖于与原始API相同的底层提供商。

虽然在衡量方式上与停机时间类似，但API的正常运行时间可以为业务决策提供洞察力。如果你知道某个API在关键工作时间内可以为客户带来更好的正常运行时间，则可以使用此指标在提供商之间进行切换。

一些利益相关者在选择放弃哪个API提供商时可能会对停机时间做出反应，而其他利益相关者在考虑选择哪个提供商时可能会更多地对正常运行时间做出反应。这些数值是有联系的，但是，它们可以讲述不同的数据故事。

消费量

在监控API的时候，很容易忘记使用情况，或者说消费情况。内部API可能不需要使用此指标，但是对第三方API使用的预测可以帮助制定业务决策，如果没有适当的数据，使用Web服务时估计成本可能会很困难。消费量可以作为一个整体来评估，也可以以突发事件来评估。一些API供应商按月计费，但有些供应商可能对其定价层有费率限制，也会观察较小时间窗口的使用情况。

通过跟踪消费情况并设置高使用率警报，可以避免不必要的成本。此外，认识到什么时候没有使用API也是有益的。缺乏消费是一个标志，表明一个API仍然是你的代码库的一部分，但可能对你的应用程序不重要，在这种情况下，你可以调整功能优先级并深入了解应用程序的使用情况。

最好将消费视为运行值，并可以通过时间窗口进行过滤，这使得仪表盘可以提供一个概览，以及关于何时使用API的详细情况。

故障率

请求失败的原因有很多种。当对第三方API或Web服务的请求失败时，可能是由于用户错误、API停机、速率限制或各种网络相关问题。虽然API故障有时可能是由你的应用程序引起的，但在跟踪第三方API时，你希望主要关注你无法控制的失败率。

跟踪故障并确定故障率可以帮助：

向API供应商报告问题
在多个API提供商之间做出决定
做出与后备方案相关的明智决策
围绕某些资源建立弹性

某些错误可能来自无效请求，这些可以告诉你应用程序在发出请求之前需要调整内部验证。来自服务器相关问题的错误（如状态码在400和500范围内）表明问题可能与API或web服务提供商有关。

状态码

跟踪HTTP响应可以为你提供有关单个API的细粒度细节，但是跟踪特定的状态码可以让你更好地洞察问题的类型。例如，即使发生错误，某些API提供程序也会以 200 OK 状态响应。这个错误的指标可能会让你相信一切都按预期进行，但是用户可能会遇到问题，并且你的内部日志记录可能会讲述一个不同的故事。

将 API 提供商的状态码指标与内部错误日志进行比较，可以进一步了解你的应用程序所依赖的第三方 Web 服务的真实错误率。

结束

记住这些指标，你的应用程序就可以更好地处理依赖于第三方集成时不可避免的问题。

测量所有这些指标听起来像是一项艰巨的任务。幸运的是，某些开发人员工具（例如Bearer）可以帮助监控许多这些指标并应对自动出现的问题。

原文：https://dev.to/bearer
作者：Mark Michon