API监控：你应该衡量什么？API监控实现原理

在监控第三方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 服务的真实错误率。

结束

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

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

API监控实现原理

1、什么是API

API（Application Programming Interface，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序给开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

2.Zabbix API

（1) Zabbix API允许你以编程方式检索和修改Zabbix的配置，并提供对历史数据的访问。 它广泛用于：

• 创建新的应用程序以使用Zabbix；

• 将Zabbix与第三方软件集成；

• 自动执行常规任务。

(2) Zabbix API是基于Web的API，作为Web前端的一部分提供。它使用JSON-RPC 2.0协议，这意味着

• 该API包含一组独立的方法；

• 客户端和API之间的请求和响应使用JSON格式进行编码==

(3) Zabbix API由许多名义上分组的独立API方法组成。每个方法执行一个特定任务。例如，方法 host.create 隶属于 host 这个API分组 ，用于创建新主机。历史上，API分组有时被称为“类”。

大多数API至少包含四种方法： get， create， update 和 delete ，分别是检索，创建，更新和删除数据，但是某些API提供一套完全不同的一组方法。

根据单个或分布式平台上不同软件应用程序间的数据共享性能，可以将 API 分为四种类型：

• 远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。

• 标准查询语言（SQL）：是标准的访问数据的查询语言，通过通用数据库实现应用程序间的数据共享。

• 文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。
  信息交付：指松耦合或紧耦合应用程序间的小型格式化信息，通过程序间的直接通信实现数据共享。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。