【.com快译】在软件产品开发生命周期中，不同的团队需要关注不同的API指标。无论是API产品经理还是开发工程师，在进行API分析研究和报告时，自然会从自身的功能特点出发，审视各种关键的API指标。下面我们从团队的角色出发，讨论一下需要关注的十三个API性能指标。首先，让我们看一下典型的软件企业团队的不同职能角色。基础架构和DevOps通过适当分配有限资源，确保服务器正常运行，供多个工程团队使用。应用工程和平台API开发人员负责为API添加新功能并解决基于业务逻辑的应用程序中的问题。他们提供的产品包括：API即服务（APIasaService）、插件和与合作伙伴的集成，以及其他丰富的API。产品管理API产品经理负责确保通过API功能的路线图构建正确的API节点；通过工程时间和人员条件的限制，平衡（内部或外部）用户的需求。业务与增长这是一个由营销和销售组成的上市团队。他们不会专注于API节点，而是紧跟客户的兴趣点，以确保他们可以使用开发的API并从中发现新的销售机会。InfrastructureAPIindicators此类指标主要通过ApplicationPerformanceMonitoring（APM）工具（如Datadog等基础设施监控公司的产品）获取。他们主要关注以下几个方面：1.正常运行时间（uptime）正常运行时间是衡量服务可用性最基本的指标之一，我们有时称之为“黄金标准”。许多企业在其服务级别协议(SLA)中提及或强调各种与服务相关的“正常运行时间”标准。如下图所示，我们在一些词汇表中经常看到的“三个九”或“四个九”，用来衡量一个服务系统每年的正常运行时间和宕机时间之间的关系。当然，从“四个九”到“五个九”比从“两个九”到“三个九”要困难得多，这就是为什么，除了关键（也是最昂贵的）服务之外，还有一个原因你很少在SLA中看到“五个九”。话虽如此，我们仍然可以减少一些服务的正常运行时间，同时确保在极端的中断情况下，预期的服务处理不会受到影响。例如：Moesif（美国人工智能API服务平台）旨在即使其网站和仪表板完全中断，也能通过各种SDK继续收集数据。也就是说，SDK能够在不中断现有应用程序的情况下在本地对收集到的信息进行排队。正常运行时间通常使用Pingdom或UptimeRobot等ping服务或综合测试来衡量。您可以将检测频率配置为固定时间间隔，例如每分钟检测特定节点的/health或/status，以获取数据备份等其他服务的基本连接状态。您可以通过Statuspage.io等工具将这些收集的指标发布到您的目标网站。例如：Moesif使用基于Lambda构建的开源状态页面（参见：https://github.com/ks888/LambStatus）。当然，我们也可以设置和使用一些复杂的ping服务，称为“综合测试”。例如：运行一组特定的测试序列并确定响应负载是否包含某个值。虽然综合测试可能不代表真实的用户流量，但这些调试API对于了解系统的正常运行情况非常有意义。值得说明的是，综合监控是由监控服务触发的一组预定义的API调用，可以检查目标API序列是否满足预期的运行状态。2.CPU使用率CPU使用率也是经典的性能指标之一，可以在一定程度上反映应用程序的响应速度。如果服务器CPU使用率很高，可能意味着服务器或虚拟机超载，可能会导致应用程序的性能错误，例如：大量的自旋锁（spinlock）。基础架构工程师可以使用CPU使用率（包括内存使用百分比）来规划资源和衡量整体健康状况。某些类型的应用程序（例如高带宽代理服务和API网关）本质上会比其他进程具有更高的CPU使用率，尤其是当它涉及繁重的浮点操作时，例如视频编码和机器学习。负载。在本地调试API时，可以方便的查看系统和进程的CPU使用情况。但是在服务器上，如果不想使用SSH或者不想运行top命令，那么就需要借助各种APM工具。APM提供可嵌入到应用程序或服务器中的代理，以捕获CPU和内存使用情况等指标。当然，您还可以监视执行其他特定功能的应用程序，例如线程分析。我们在查看CPU使用率的时候，主要关注各个虚拟CPU（也就是物理线程）的使用情况。如果存在不平衡，则可能意味着应用程序未正确执行进程，或者线程池大小配置不正确。许多APM允许您使用不同的名称标记应用程序以便于聚合。例如：您可能希望对每个VM指标进行分组，例如：my-api-westus-vm0、my-api-westus-vm1、my-api-eastus-vm0等，并将它们聚合到一个名为my的组中-标签的API。3、内存占用与CPU占用类似，内存占用也是衡量资源利用率的性能指标。高内存使用率可能表示服务器超载，因此通常与配置相关。通常，各种生产环境中的大数据查询、大流量处理、数据库消耗的内存比CPU多。因此，为了减少每个VM用于批处理查询的时间，我们应该分配更多可用内存以减少检查点、网络同步和磁盘分页。我们在查看内存使用情况的同时，还要查看页错误数和I/O操作数。一个常见的错误配置是只将一小部分可用物理内存分配给应用程序。这很可能导致高位页的虚拟内存崩溃。应用程序API指标4.每分钟请求数(RPM)每分钟请求数(RPM)是我们在比较HTTP或数据库服务器时经常使用的性能指标。由于服务器在对数据库进行I/O操作时无法准确计算出第三方服务造成的延迟，所以虽然有些产品会吹嘘自己的RPM高，但你的团队仍然需要以效率为目标，尽量降低RPM。通常，您需要将一些具有多个API调用的业务功能合并为更少的API调用，以减少RPM的数量。例如：您可以在单个请求中批量处理多个请求，以确保您拥有灵活实用的分页解决方案。与RPM相关的术语包括：每秒请求数(RPS)和每秒查询数(QPS)。由于软件产品的RPM可能每周都不同，甚至一天中的每个小时都不同，因此您需要灵活地调整API以适应特定的高峰和低谷。5.平均和最大延迟在跟踪客户体验时，API延迟是一个非常重要的指标。虽然上文提到的CPU使用率等基础设施级别指标的增加可能不会让用户及时感知到响应能力的下降，但API的延迟是一定会的。有时，仅跟踪延迟可能无法让您完全了解延迟增加的原因。因此，我们需要跟踪API的各种变化，包括：新API版本的发布、在原有架构上增加新节点等，找出延迟增加的根本原因。因为从宏观上查看整体时延，可能会忽略真正有问题的慢节点，所以需要根据路由、地理位置、分段字段进行排查。例如：POST/checkout节点的延迟随着时间的推移而增加，很可能是由于未正确索引的不断增长的SQL表。然而，由于对POST/checkout的调用次数非常少，这个问题很容易被你的GET/items节点掩盖，它的数量远远超过checkout节点。同样，如果您使用GraphQLAPI，则需要查看每个GraphQL操作的平均延迟。虽然许多开发人员和架构师也关注延迟问题，但他们主要检查一组VM的整体延迟以确保VM没有过载，而没有深入研究特定于应用程序的指标，例如每条路由。因此，我们认为应用程序和工程师需要更加关注与延迟相关的问题。6.每分钟的错误率与RPM相似。“Errorsperminute”（或简称错误率）是指每分钟产生的非200系列代码的API调用次数。通过测量API的错误率及其出错倾向，我们可以进一步了解正在发生的错误类型。例如：500系列错误表示你的代码有问题，而400系列错误表示API设计和文档不完善。可见，我们在设计API时，使用合适的HTTP状态码是非常重要的。详情请参考：https://www.restapitutorial.com/httpstatuscodes.html。API产品指标值得注意的是，我们这里所说的API，不仅仅指微服务、SOA相关的应用接口，还包括那些独立的产品。此类产品越来越普遍，尤其是在与新合作伙伴开辟呼叫渠道时。其产品由API驱动的团队需要检查错误和延迟等指标，并了解API的使用方式，包括为什么它没有按预期执行。7.API使用率的增长对于许多产品经理来说，API的使用率是衡量API作为产品的转换效率的黄金标准。一个好的API产品，不仅要没有缺陷，还要有不断增加的实际使用量。通常，我们可以按月衡量API使用量的增长情况。8.API专用用户当然，某个API在一个月内的使用量增长可能只是来自某个用户账户，所以我们需要衡量API月活跃用户（MonthlyActiveUsers，MAU）或者API专用用户（独特的消费者）。这些指标可以让您全面了解用户“认可度”和使用增长情况。同时，很多API平台团队也会将API的MAU与其网站的MAU关联起来，得到一个完整的产品姿态。9、使用API??的头部用户对于一些专注于B2B业务的公司来说，了解他们API产品的头部用户是谁是非常有必要的。这少数顶级用户通常会为您的公司带来更多的收入和推荐，因此您可以根据此调用相应的节点，并进一步细分他们以了解他们使用特定节点的频率以及使用体验。10.API使用和保留你可能想知道是应该在产品和项目上投入更多，还是在增长上烧钱？只看用户留存和流失，并不能给出明确的参考。毕竟有些用户虽然觉得你的API不够友好，但是他们被强制订阅了包年合同，不能立即退订，反而不会主动使用你提供的API。因此，我们需要追踪的是API作为产品在用户端的实际使用情况。11.TimetoFirstEntry(TTFHW)作为一个重要的KPI，TimetoFirstHelloWorld(TTFHW)不仅可以跟踪API产品的运行状态，还可以跟踪开发者的整体体验（developerexperience，DX）。如果你的API是一个开放的平台，吸引第三方开发者和合作伙伴使用，那么你需要保证他们在第一次调用的时候能够顺利的使用你提供的API来开发应用。TTFHW主要衡量：从首次登录页面访问到通过您的API平台进行首次交易的MVP集成时间。该指标不仅适用于API本身，还可以检验你的营销效果，还有配套的文档和教程。12、每笔业务的API调用虽然一般来说，各种产品和业务的指标越多越好，但每笔业务的调用次数越少越好。该指标直接反映了API的设计水平。如果新用户需要三个不同的调用来组合数据，则可能意味着API没有找到正确的节点。因此，在设计API时，我们应该考虑业务交易本身和用户想要达到的目标，而不仅仅是可以提供的功能和涉及的节点。另外，你可能还需要对API进行灵活的过滤和分页操作，请参考：https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-和-分页/?utm_source=dzone&utm_medium=paid&utm_campaign=placed%20article&utm_term=13%20api%20metrics。13.SDK和版本的采用许多API平台团队可能还需要维护大量的SDK和集成。不像移动端只专注于iOS和Android，你的平台上可能有几十个甚至上百个SDK。因此，它们的持续维护通常是费时费力的。然后，您可以有选择地将一些关键功能部署到那些最流行的SDK中。同时，在弃用某些节点和功能时，也需要征求那些顶级用户的意见，对API或SDK以及版本进行权衡。结论跟踪正确的API指标对于参与构建和使用API的任何人都至关重要。不同的团队成员对不同的API指标有不同的关注点，更能从自己的专业角度解决当前和潜在的性能问题。希望以上讨论能为您和您的团队提供一些帮助。原标题：每个平台团队都应该跟踪的13个API指标，作者：DerricGilling
