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）可以帮助监控许多这些指标并应对自动出现的问题。
最近整理了一份优质视频教程资源，想要的可以关注我然后私信“666”即可免费领取哦！如果文章对你有所启发和帮助，可以点个关注、收藏、转发，也可以留言讨论，这是对作者的最大鼓励。