让我们假设，在给定的时间，特定Lambda函数的多个实例已被异步调用，
然后，是否可以找到当前正在运行的Lambda函数的活动个并发实例？
在控制台的帐户级别指标中，我们可以找到并发执行的次数。另外，我认为对于每个新的Lambda容器创建，Cloudwatch都会为Lambda函数创建一个新的日志流。也许可以以某种方式使用它们。
但是我想知道是否存在以其他方式通过编程方式获取这些数字的方法，例如使用boto3 api等。
答案 0 :(得分：1)
简短的回答是“否”。
您可以以编程方式访问cloudwatch指标（请参阅：boto3 CloudWatch.Client.get_metric_data），但是这些指标落后一分钟。更糟的是，尽管单个lambda返回invocations，但您只能在整个帐户中获得ConcurrentExecutions-这意味着您最好的办法就是将lambda放在自己的AWS中帐户，即使这样，您仍然要落后一分钟-通常比平均Lambda寿命更长。
不过，我应该指出，lambda通过“保留并发”确实提供了一种至少基本控制并发的方法。此示例用例是，如果您正在调用连接池有限的外部服务/数据库。
答案 1 :(得分：1)
我通过让每个正在运行的 lambda 实例将名为 {task}{request_id}.json 的状态 json 文件写入到跟踪 lambda 的存储桶中的特定 s3 文件夹来完成此操作。我有三个子文件夹，/Running、/Completed、/Failed，所以我可以跟踪完成和失败的总数。找出有多少正在运行相当于列出 /Running 文件夹中的文件，这非常快，不需要实际获取或打开文件。
每个 lambda 首先在 /Running 中创建一个状态文件。它在 try/except 块中工作，捕获所有 Python 异常，然后读取该请求的 Running 文件夹中的字典，并使用其他信息更新它，例如总持续时间和任何错误详细信息。然后删除 /Running 中的状态文件，并在 /Completed 或 /Failed 中创建状态文件。
我会说我的应用程序有持续时间通常为 400 秒的 lambda 实例，因此这种跟踪的开销还不错，而且在任何一项工作中它往往只运行大约几千个 lambda。如果您的应用程序以高频率启动小型 lambda，那么这可能会造成过多的开销。
就我而言，请求是在代码中明确提出的（而不是被触发），但每个请求都是异步并行运行的。 AWS Lambda 系统将对超过并发限制的请求进行排队，然后进行节流。一旦 lambda 可用，排队和限制的请求将启动一个实例，达到并发限制。
我还引入了另一个名为 runtoken{parent_pid}.json 的文件，它建立在一个已知的 s3 文件夹中，每个 lambda 都可以检查它是否有权运行。提供 {parent_pid} 是为了防止 lambda 混淆旧授权的新授权。但基本上，如果由于某种原因我需要停止执行，我需要做的就是删除 runtoken 文件。内部循环中的每个 lambda 都会检查文件是否存在以及 parent_pid（进程 ID）是否与启动它的那个相匹配。如果没有，它会正常退出并向 AWS lambda 返回成功状态代码，同时将状态发布到 /Failed 文件夹。如果 lambda 退出并出现错误，例如 sys.exit(1)，则 AWS lambda 启动器将重试 lambda 函数。所有 lambda 都检查 Running 文件夹以确保它们没有被重试。 request_id 在重试的 lambdas 中是相同的。