# 监控并发
Lambda 会发送 Amazon CloudWatch 指标，以帮助监控函数的并发。本主题解释了这些指标以及如何解读指标。
**Topics**
+ [一般并发指标](#general-concurrency-metrics)
+ [预配置并发指标](#provisioned-concurrency-metrics)
+ [使用 `ClaimedAccountConcurrency` 指标](#claimed-account-concurrency)
## 一般并发指标
使用以下指标监控 Lambda 函数并发。各指标的粒度为 1 分钟。
+ `ConcurrentExecutions` – 给定时间点处于活动状态的并发调用数。Lambda 会针对所有函数、别名和版本发送该指标。对于 Lambda 控制台中的任何函数，Lambda 会在**指标**下的**监控**选项卡中原生显示 `ConcurrentExecutions` 的图表。使用 **MAX** 查看该指标。
+ `UnreservedConcurrentExecutions` – 使用非预留并发的处于活动状态的并发调用数。Lambda 会向区域中所有函数发出该指标。使用 **MAX** 查看该指标。
+ `ClaimedAccountConcurrency` – 不可用于按需调用的并发数。`ClaimedAccountConcurrency` 等于 `UnreservedConcurrentExecutions` 加上分配的并发数（即总预留并发数加上总预置并发数）。如果 `ClaimedAccountConcurrency` 超出账户并发限制，则可以[申请更高的账户并发数限制](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)。使用 **MAX** 查看该指标。有关更多信息，请参阅 [使用 `ClaimedAccountConcurrency` 指标](#claimed-account-concurrency)。
## 预配置并发指标
使用预置并发时，使用以下指标监控 Lambda 函数。各指标的粒度为 1 分钟。
+ `ProvisionedConcurrentExecutions` – 正在积极处理预置并发调用的执行环境实例的数目。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **MAX** 查看该指标。
`ProvisionedConcurrentExecutions` 与您分配的预置并发总数不同。例如，假设您为某个函数版本分配了 100 个单位的预置并发。在任何给定的一分钟内，如果这 100 个执行环境中最多有 50 个会同时处理调用，则 **MAX** (`ProvisionedConcurrentExecutions`) 的值为 50。
+ `ProvisionedConcurrencyInvocations` – Lambda 使用预置并发调用函数代码的次数。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **SUM** 查看该指标。
`ProvisionedConcurrencyInvocations` 与 `ProvisionedConcurrentExecutions` 的不同之处在于，`ProvisionedConcurrencyInvocations` 会计算调用总次数，而 `ProvisionedConcurrentExecutions` 会计算处于活动状态的环境的数量。要理解这种区别，请考虑以下情形：
![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
在本例中，假设您每分钟收到 1 次调用，并且每次调用需要 2 分钟才能完成。每个橙色水平条形代表一个请求。假设您为该函数分配 10 个单位的预置并发，此时每个请求都会在预置并发上运行。
在 0 到 1 分钟之间，`Request 1` 会传入。**在第 1 分钟**，**MAX** (`ProvisionedConcurrentExecutions`) 的值为 1，因为在过去一分钟内，至多 1 个执行环境处于活动状态。**SUM** (`ProvisionedConcurrencyInvocations`) 的值也为 1，因为在过去一分钟内传入了 1 个新请求。
在第 1 分钟到第 2 分钟之间，`Request 2` 会传入，并且 `Request 1` 会继续运行。**在第 2 分钟**，**MAX** (`ProvisionedConcurrentExecutions`) 的值为 2，因为在过去一分钟内至多 2 个执行环境处于活动状态。但是，**SUM** (`ProvisionedConcurrencyInvocations`) 的值为 1，因为在过去一分钟内只传入了 1 个新请求。这种指标行为一直持续到示例结束。
+ `ProvisionedConcurrencySpilloverInvocations` – 当所有预置并发均处于使用状态时，Lambda 根据标准（预留或非预留）并发调用函数的次数。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **SUM** 查看该指标。`ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` 的值应等于函数调用的总次数（即 `Invocations` 指标）。
`ProvisionedConcurrencyUtilization` – 正在使用的预置并发的百分比（即 `ProvisionedConcurrentExecutions` 除以分配的预置并发总量的值）。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **MAX** 查看该指标。
例如，假设您为某个函数版本预置了 100 个单位的预置并发。在任何给定的一分钟内，如果这 100 个执行环境中最多有 60 个同时处理调用，则 **MAX** (`ProvisionedConcurrentExecutions`) 的值为 60，**MAX** (`ProvisionedConcurrencyUtilization`) 的值为 0.6。
`ProvisionedConcurrencySpilloverInvocations` 的值较高可能表示您需要为函数分配限额外的预置并发。或者，您可以[配置 Application Auto Scaling 以根据预定义的阈值处理预置并发的自动扩缩](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency)。
相反，`ProvisionedConcurrencyUtilization` 的值持续较低可能表明您为函数分配了过多的预置并发。
## 使用 `ClaimedAccountConcurrency` 指标
Lambda 使用 `ClaimedAccountConcurrency` 指标来确定您的账户可用于按需调用的并发数。Lambda 将使用以下公式计算 `ClaimedAccountConcurrency`：
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions` 指使用非预留并发的处于活动状态的并发调用数。分配的并发是以下两部分的总和（将 `RC` 替换为“预留并发”，`PC` 替换为“预置并发”）：
+ 区域中所有函数的总 `RC`。
+ 一个区域中所有使用 `PC` 的函数的总 `PC`，不包括使用 `RC` 的函数。
**注意**
为一个函数分配的 `PC` 不能超过 `RC`。因此，函数的 `RC` 总是大于或等于其 `PC`。为了计算同时使用 `PC` 和 `RC` 的此类函数对分配并发的贡献，Lambda 只考虑两者中最大的 `RC`。
Lambda 使用 `ClaimedAccountConcurrency` 指标，而不是 `ConcurrentExecutions` 指标，来确定可用于按需调用的并发数。虽然 `ConcurrentExecutions` 指标非常适用于跟踪活动并发调用数，但其并不总是能反映真实的并发可用性。这是因为 Lambda 还会考虑预留并发和预置并发来确定可用性。
要说明 `ClaimedAccountConcurrency`，假设在一个场景中，您在基本上未使用的函数中配置了大量预留并发和预置并发。在以下示例中，假设您的账户并发数限制为 1000，并且账户中有两个主要函数：`function-orange` 和 `function-blue`。您为 `function-orange` 分配了 600 个单位的预留并发。您为 `function-blue` 分配了 200 个单位的预置并发。假设随着时间的推移，您会部署其他函数并观测到以下流量模式：
![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/claimed-account-concurrency.png)
在上图中，黑线表示一段时间内的实际并发使用情况，红线表示一段时间内的 `ClaimedAccountConcurrency` 值。尽管各函数的实际并发利用率较低，但在整个场景中，`ClaimedAccountConcurrency` 至少为 800。这是因为您总共为 `function-orange` 和 `function-blue` 分配了 800 个单位的并发。从 Lambda 的角度来看，您已经“申请”了此并发以供使用，因此其他函数实际上只剩下 200 个单位的并发。
该场景中，`ClaimedAccountConcurrency` 公式中分配的并发数为 800。然后我们可以推导出图中不同点处的 `ClaimedAccountConcurrency` 值：
+ `t1` 点处，`ClaimedAccountConcurrency` 等于 800 (800 \$1 0 `UnreservedConcurrentExecutions`)。
+ `t2` 点处，`ClaimedAccountConcurrency` 等于 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。
+ `t3` 点处，`ClaimedAccountConcurrency` 又等于 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。
### 在 CloudWatch 中设置 `ClaimedAccountConcurrency` 指标
Lambda 在 CloudWatch 中发出 `ClaimedAccountConcurrency` 指标。使用此指标以及 `SERVICE_QUOTA(ConcurrentExecutions)` 值可以获得账户中并发利用率的百分比，如以下公式所示：
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
以下屏幕截图说明了如何在 CloudWatch 中绘制此公式的图表。绿 `claim_utilization` 线表示此账户中的并发利用率，约为 40%：
![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
上一个屏幕截图还包括 CloudWatch 警报，当并发利用率超过 70% 时，该警报会进入 `ALARM` 状态。您可以使用 `ClaimedAccountConcurrency` 指标以及类似警报来主动确定何时可能需要请求更高的账户并发数限制。