平台团队应该追踪的 13 个 API 指标

封面图片由 Sean Kirkpatrick 拍摄，来自 Flickr

识别关键 API 指标

每个团队在 API 方面需要跟踪不同的 KPI。
对基础设施团队重要的 API 指标与对 API 产品或 API 平台团队重要的 API 指标截然不同。
指标的选择也可能取决于 API 在产品生命周期中所处的阶段。一个新推出的 API 会更注重
改进设计和使用体验，而牺牲可靠性和向后兼容性。维护已被企业团队广泛采用的 API 的团队可能会
更注重推动每个账户采用更多功能，并将可靠性和向后兼容性置于设计之上。

一般来说，有三到四个团队关注 API 指标。

基础设施/DevOps

确保服务器正常运行，并正确分配有限的资源，可能需要分配给多个工程团队。

应用工程/平台

API 开发人员负责为 API 添加新功能，同时调试 API 业务逻辑中特定于应用程序的问题。
这些产品可以是 API 即服务 (APIaaS)、面向合作伙伴的插件和集成、集成到大型产品中的 API，或其他形式。

产品管理

API 产品经理负责制定 API 功能路线图，确保构建正确的 API 端点，并在满足客户（无论是内部客户还是外部客户）需求与工程时间和个人限制之间取得平衡。

业务/增长

面向业务的团队，例如市场营销和销售团队，并不考虑 API 端点，而是更关注客户采纳情况，确保客户成功使用 API，了解客户的来源，以及哪些用户可能带来新的销售机会。

基础设施 API 指标

这些指标大多是应用程序性能监控 (APM) 工具和基础设施监控公司（如 Datadog）关注的重点。

1：正常运行时间

正常运行时间或可用性是最基本的指标之一，也是衡量服务可用性的黄金标准。许多企业协议都包含服务级别协议 (SLA)，正常运行时间
通常会包含在其中。您经常会听到“三个 9”或“四个 9”之类的说法，它们衡量的是每年正常运行时间与停机时间的比例。

当然，从四个九提升到五个九远比从两个九提升到三个九要难得多，因此除了那些最关键
（也最昂贵）的服务之外，你几乎看不到五个九的正常运行时间。即便如此，某些服务实际上可以降低正常运行时间，同时确保优雅地处理故障，而不会影响你的服务。
例如，Moesif 的设计使其即使在网站和控制面板完全宕机的情况下也能继续从我们的 SDK 收集数据。
即使在最糟糕的情况下，我们的数据收集网络也宕机了，SDK 也会在本地排队，不会对应用程序造成任何中断。

正常运行时间通常通过 ping 服务或合成测试（例如Pingdom或UptimeRobot）来测量。您可以配置探测程序以固定间隔（例如
每分钟）运行，以探测特定端点（例如/health服务器或终端/status）。此端点应进行基本的连接性测试，例如与任何后端数据存储或其他服务的连接性测试。

您可以使用Statuspage.io等工具将这些指标发布到您的网站上。
事实上，Moesif 使用的是一个基于 Lambda 构建的开源状态页面。

还有一种更高级的 ping 服务叫做合成测试，它可以执行更复杂的测试设置，例如运行
特定的序列并断言响应负载具有特定值。但请记住，合成测试可能无法代表来自
客户的真实流量。即使 API 存在缺陷，您仍然可以保持高正常运行时间。

什么是合成监控？
顾名思义，它是一组预定义的 API 调用，由服务器（通常是监控服务提供商之一）触发来调用您的服务。虽然它不能反映用户的真实体验，但有助于了解这些 API 调用的顺序是否符合预期。

2：CPU 使用率

CPU 使用率是最经典的性能指标之一，可以作为衡量应用程序响应速度的参考。服务器 CPU 使用率过高可能意味着
服务器或虚拟机资源过载，也可能意味着应用程序存在性能缺陷，例如自旋锁过多。基础设施工程师
使用 CPU 使用率（以及与之相关的内存使用率）进行资源规划和整体健康状况评估。某些类型的应用程序，例如高带宽代理服务和 API 网关，其 CPU 使用率自然会高于其他指标，此外，涉及 大量浮点运算的工作负载（例如视频编码和机器学习工作负载）
也会有较高的 CPU 使用率。

在本地调试 API 时，您可以通过Windows 的任务管理器（或Mac 的活动监视器）轻松查看系统和进程的 CPU 使用率。但在服务器上，
您可能不想通过 SSH 连接并运行top命令。这时，各种应用程序性能管理 (APM) 提供商就能派上用场了。APM 包含一个代理，您可以将其嵌入到应用程序或服务器中，用于捕获 CPU 和内存使用率等指标。它还可以执行其他特定于应用程序的监控，例如线程分析。

查看 CPU 使用率时，务必关注每个虚拟 CPU（即物理线程）的使用率。使用率不均衡可能意味着应用程序线程分配不正确或
线程池大小不合适。

许多 APM 提供商允许您使用多个名称标记应用程序，以便执行汇总。例如，您可能希望将每个虚拟机的指标细分
为my-api-westus-vm0、my-api-westus-vm1、my-api-eastus-vm0等，同时将这些指标汇总到名为my-api的单个应用程序中。

3：内存使用情况

与 CPU 使用率类似，内存使用率也是衡量资源利用率的良好指标，因为 CPU 和内存容量是物理资源，而其他指标可能更依赖于配置。内存使用率极低的虚拟机可以缩减规模，或者为其分配额外的服务以消耗更多内存。另一方面，内存使用率过高可能表明服务器过载。通常，大数据查询/流处理和生产数据库消耗的
内存远多于 CPU。事实上，每个虚拟机的内存大小可以很好地指示批处理查询的耗时，因为更多可用内存可以减少检查点、网络同步和磁盘分页。查看内存使用率时，还应关注缺页次数和 I/O 操作次数。一个容易犯的错误是，应用程序
配置为最多只分配可用物理内存的一小部分，这会导致虚拟内存页面抖动异常高。

应用程序 API 指标

4：每分钟请求数 (RPM)

每分钟请求数 (RPM) 是比较 HTTP 或数据库服务器时常用的性能指标。
通常，实际端到端 RPM 会远低于标称 RPM，后者更像是简单“Hello World”API 的上限。
因为服务器不会考虑对数据库、第三方服务等进行 I/O 操作所产生的延迟。虽然有些人喜欢炫耀高
RPM，但工程团队的目标应该是提高效率并努力降低 RPM。某些需要大量 API 调用的业务功能可以合并为更少的 API 调用来降低 RPM。将多个请求批量处理到单个请求中，以及确保 拥有灵活的分页方案，
都是非常有效的方法。

您的每分钟请求数 (RPM) 可能会因星期几甚至每天的小时数而异，尤其当您的 API 面向其他业务时，这些业务在夜间和
周末的使用率较低。RPM 还与其他一些术语相关，例如每秒请求数 (RPS) 和每秒查询数 (QPS)。

5：平均延迟和最大延迟

追踪客户体验最重要的指标之一是 API 延迟或运行时间。虽然 CPU 使用率等基础设施级别指标的增加可能并不必然导致用户感知响应速度的下降，但 API 延迟的增加却会直接影响用户体验。然而，仅仅追踪延迟本身可能无法让你完全了解
延迟增加的原因。因此，追踪 API 的任何变更至关重要，例如新 API 版本的发布、新增端点、架构变更等等，以便
找到延迟增加的根本原因。

因为仅查看总延迟可能会掩盖存在问题的慢速端点，所以按路由、地理位置和其他
字段细分延迟至关重要。例如，某个POST /checkout端点的延迟可能随着时间的推移而缓慢增加，这可能是由于 SQL 表的大小不断增加
但索引不正确造成的。然而，由于该端点的调用量较低POST /checkout，这个问题被调用次数远高于结账端点的端点所掩盖GET /items。同样，如果您有 GraphQL API，则需要查看每个 GraphQL 操作的平均延迟。

尽管许多 DevOps/基础设施团队也会关注延迟，但我们仍然将其归类于应用/工程范畴。通常，基础设施人员会查看
一组虚拟机的总体延迟，以确保虚拟机没有过载，但他们不会深入到特定于应用程序的指标，例如每个路由的延迟。

6：每分钟错误数

与 RPM 类似，每分钟错误数（或错误率）是指每分钟返回非 200 系列状态码的 API 调用次数，它对于衡量 API 的缺陷和错误倾向至关重要。为了跟踪每分钟错误数，
了解错误类型非常重要。500 个错误可能意味着代码存在严重问题，而 400 个错误则可能
意味着由于 API 设计或文档不完善而导致的用户操作错误。这意味着在设计 API 时，使用正确的 HTTP 状态码至关重要。

您可以进一步深入分析这些错误的来源。如果来自特定地理区域的大量401 未授权
错误，则可能意味着有机器人 试图入侵您的 API。

API产品指标

API不再仅仅是与微服务和SOA相关的工程术语。作为一种产品，API正变得越来越普遍，尤其是
在希望通过新的合作伙伴和收入渠道超越竞争对手的B2B企业中。以API为驱动的公司需要关注的不仅仅是
错误和延迟等工程指标，才能了解其API的使用情况（或为何其应用速度未达到预期）。确保构建正确功能的重任落在了API产品经理
身上，许多B2B企业正在争相填补这一新职位。

什么是 Moesif？Moesif是最先进的 API 分析平台，已被超过 2000 家机构使用，帮助您了解最忠实的客户如何使用您的 API，他们如何访问 API，以及从哪里访问。Moesif 专注于分析真实客户数据，而非仅仅使用合成测试，以确保您
为客户构建最佳的 API 平台。

7：API 使用量增长

对于许多产品经理来说，API 使用量（以及独立用户数）是衡量 API 采用率的黄金标准。一个优秀的 API 不仅应该没有错误，还应该逐月增长。与每分钟请求数不同，API 使用量应该以天或月为单位进行衡量，才能了解真正的趋势。如果要衡量 API 的月度增长，我们建议选择 28 天，因为它可以消除周末与工作日使用量差异以及每月天数不同造成的偏差。例如，二月份可能只有 28 天，而二月份有完整的 31 天，这会导致二月份的使用量看起来较低。

8：唯一 API 使用者

由于 API 使用量的月度增长可能仅仅源于单个客户账户，因此衡量API 的日活跃用户数 (DAU) 或API 的独立用户数量至关重要。该指标能够全面反映新客户获取和增长的健康状况。许多 API 平台团队会将 API 月活跃用户数 (MAU) 与网站月活跃用户数 (MAU) 关联起来，以全面了解产品健康状况。如果网站月活跃用户数的增长速度远高于 API 月活跃用户数，则可能意味着在集成或实施新解决方案的过程中存在转化漏斗漏洞。对于许多 B2B/SaaS 公司而言，当其核心产品是 API 时，这种情况尤为突出。
另一方面，可以将 API 月活跃用户数与 API 使用量关联起来，以了解 API 使用量的增长来源（新客户还是现有客户）。

像 Moesif 这样的工具可以跟踪调用 API 的个人用户，还可以将他们与公司或组织联系起来。

9：按 API 使用量排名的前几名客户

对于任何专注于B2B业务的公司而言，追踪API使用量最高的用户群体，能够帮助您深入了解API的使用情况以及
潜在的追加销售机会，从而获得巨大优势。许多经验丰富的产品负责人都知道，很多产品都呈现出幂律动态，少数超级用户的
使用量远超其他用户。不出所料，这些超级用户通常也是公司收入和自然流量的主要来源。

这意味着追踪前十大客户如何使用您的 API 至关重要。您可以进一步细分，分析他们调用了哪些端点以及
调用方式。他们是否比普通用户更频繁地使用某个特定端点？也许他们已经发现了您的 API 的精髓所在。

10：API保留

你应该把更多资金投入产品和工程，还是投入更多资金用于增长？用户留存率和流失率（留存率的反义词）可以告诉你应该走哪条路。
用户留存率高的产品比流失率高的产品更接近市场契合度。与订阅用户留存率不同，产品留存率追踪的是产品（例如 API）的实际使用情况。虽然两者相关，但它们并不相同。一般来说，产品流失率是订阅用户流失率的领先指标，因为那些
认为 API 没有价值的客户可能仍然被年度合同束缚，却并未积极使用 API。API 用户留存率应该高于网站用户留存率，因为网站用户留存率包含的是
已登录但尚未集成平台的客户。而 API 用户留存率关注的是集成后的客户。

11：首次Hello World（TTFHW）时间

TTFHW（首次访问所需时间）不仅是一个重要的KPI，它不仅用于追踪API产品的健康状况，还用于衡量整体开发者体验（DX）。尤其当您的API是一个开放平台，吸引第三方开发者和合作伙伴时，您需要确保他们能够
尽快上手，体验到首次使用时的“顿悟时刻”。TTFHW衡量的是从用户首次访问您的着陆页到完成MVP集成并通过您的API平台完成首次交易所需的时间
。这是一个跨职能指标，涵盖了市场营销、文档和教程，以及API本身。

12：每次业务交易的 API 调用次数

虽然对于许多产品和业务指标来说，调用次数越多越好，但尽可能降低每次业务交易的调用次数至关重要。
该指标直接反映了API 的设计。如果新客户需要进行 3 次不同的调用并拼凑数据，则可能意味着 API
没有提供正确的接口。在设计 API 时，重要的是要从业务交易的角度出发，思考客户想要实现的目标，
而不仅仅是功能和接口。这也可能意味着您的 API 在筛选和分页方面不够灵活。

13：SDK 和版本采用

许多 API 平台团队可能维护着大量的 SDK 和集成。与移动端只有 iOS 和 Android 这两个核心操作系统不同，API 平台
可能拥有数十甚至数百个 SDK。这在推出新功能时会成为维护的噩梦。您可以选择性地将关键功能推出到
最常用的 SDK，而将不太重要的功能推出到不太常用的 SDK。在弃用某些
接口和功能时，衡量 API 或 SDK 版本也至关重要。您肯定不希望在没有事先咨询客户原因的情况下，就弃用付费最高的客户正在使用的接口。

业务/增长

业务/增长指标与产品指标类似，但侧重于收入、用户采纳率和客户成功。
例如，与其查看 API 使用量排名前 10 的客户，不如查看收入排名前 10 的客户，然后再查看他们的端点使用情况。
为了跟踪业务增长，像 Moesif 这样的分析工具支持使用来自 CRM 或其他分析服务的客户数据来丰富用户画像，从而
更好地了解您的 API 用户群体。

结论：

对于任何构建和使用 API 的人来说，跟踪正确的 API 指标至关重要。大多数公司在推出新的 Web 或移动产品时，都会为工程和产品团队配备合适的工具。同样，您也不希望在没有方法进行指标检测和跟踪的情况下推出新的 API。有时，一个团队的 KPI 可能与其他团队的 KPI 相似，就像我们在 API 使用率指标中看到的那样。同一个底层指标可能有不同的解读方式。然而，团队应该始终专注于关注适合自身团队的指标。例如，产品经理不应该关注 CPU 使用率，就像基础设施团队不应该关注 API 留存率一样。像Moesif API Analytics这样的工具可以帮助您通过简单的 SDK 安装开始衡量这些指标。

本文由 Moesif 创始人兼首席执行官Derric Gilling为Moesif 博客撰写。