你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
估算消耗计划成本
对于在 Azure Functions 中运行的应用，目前有三种类型的托管计划，每种计划都有自己的定价模型：
| 计划 | 说明 |
|---|---|
| 消耗 | 只根据函数应用的运行时间收费。 此计划包括基于订阅的免费授予。 |
| 高级 | 提供与“消耗”计划相同的功能和缩放机制，但具有增强的性能和 VNET 访问权限。 成本取决于所选的定价层。 若要了解详细信息，请参阅 Azure Functions 高级计划。 |
| 专用（应用服务） （基本或更高层） |
需要在专用 VM 或隔离的环境中运行、自定义映像，或想要使用超额的应用服务计划容量时。 使用常规应用服务计划计费。 成本取决于所选的定价层。 |
选择对函数性能和成本要求最有利的计划。 若要了解详细信息，请参阅 Azure Functions 的缩放和托管。
本文仅涉及到消耗计划，因为此计划产生可变的成本。 本文将取代消耗计划成本计费常见问题解答一文。
Durable Functions 也可以在消耗计划中运行。 若要详细了解使用 Durable Functions 时的成本注意事项，请参阅 Durable Functions 计费。
消耗计划成本
单个函数执行的执行成本以“GB 秒”来度量。 执行成本是通过将其内存用量与执行时间相结合计算得出的。 函数的运行时间越长，其成本越高；同理，函数消耗的内存越多，其成本越高。
假设函数使用的内存量保持恒定。 在这种情况下，进行简单的相乘即可计算成本。 例如，假设函数运行了 3 秒，消耗了 0.5 GB。 那么，执行成本为 0.5GB * 3s = 1.5 GB-seconds。
由于内存用量会不断变化，计算结果实质上是不同时间的内存用量的积分。 进行这种计算时，系统会按固定的时间间隔对进程（及其子进程）的内存用量采样。 如定价页中所述，内存用量将向上舍入到最近似的 128-MB 桶。 如果进程使用 160 MB，则你需要按 256 MB 的用量付费。 计算中会考虑并发性，即，同一进程中的多个并发函数执行。
注意
尽管执行成本中不直接考虑 CPU 用量，但如果该用量会影响函数的执行时间，则也会影响成本。
对于 HTTP 触发的函数，在函数代码开始执行之前发生错误时，不会收取执行费用。 这意味着由于 API 密钥验证或应用服务身份验证/授权功能，来自平台的 401 响应不会计入你的执行成本。 同样，在函数处理请求之前，5xx 状态代码响应在平台中发生时不会计入成本。 在函数代码开始执行后，平台生成的 5xx 响应仍算作执行，即使函数代码未引发错误。
其他相关成本
在估算任何计划中运行函数的总体成本时，请记住，函数运行时将使用其他多个 Azure 服务，而每个服务单独计费。 计算函数应用的定价时，对于与其他 Azure 服务集成的任何触发器和绑定，需要创建这些附加的服务并为其付费。
对于在消耗计划中运行的函数，总成本是函数的执行成本加上带宽和附加服务的成本。
估算函数应用和相关服务的总体成本时，请使用 Azure 定价计算器。
| 相关成本 | 描述 |
|---|---|
| 存储帐户 | 需要为每个函数应用提供一个关联的常规用途 Azure 存储帐户，该帐户单独计费。 函数运行时在内部使用此帐户，但你也可以将其用于存储触发器和绑定。 如果你没有存储帐户，系统会在创建函数应用时创建一个存储帐户。 有关详细信息，请参阅存储帐户要求。 |
| Application Insights | 函数依靠 Application Insights 为函数应用提供高性能的监视体验。 虽然未强制要求，但你应启用 Application Insights 集成。 每月会免费授予遥测数据。 要了解详细信息，请参阅 Azure Monitor 定价页。 |
| 网络带宽 | 根据数据移动的方向和方案，可能会产生数据传输费用。 有关详细信息，请参阅带宽定价详细信息。 |
影响执行时间的行为
函数的以下行为可能会影响执行时间：
触发器和绑定：从函数绑定读取输入以及向其写入输出所花费的时间计为执行时间。 例如，如果函数使用某个输出绑定将消息写入 Azure 存储队列，则执行时间包括将该消息写入该队列所花费的时间，而函数成本计算包括该写入时间。
异步执行：函数等待异步请求（在 C# 中为
await）结果的时间计为执行时间。 “GB 秒”计算基于函数的开始和结束时间，以及该时间段内的内存用量。 计算中不考虑该时间段内发生的 CPU 活动。 也许可以使用 Durable Functions 来降低异步操作期间产生的成本。 业务流程协调程序函数中的等待时间不产生费用。
查看与成本相关的数据
在你的发票中，可以查看“执行总次数 - 函数”和“执行时间 - 函数”的与成本相关的数据，以及实际的计费费用。 但是，此发票数据是过去发票期限的每月聚合。
函数应用级指标
若要更好地了解函数对成本的影响，可以使用 Azure Monitor 查看函数应用当前生成的成本相关指标。
使用 Azure Monitor 指标资源管理器可以图形格式查看消耗计划函数应用的成本相关数据。
在 Azure 门户中，导航到你的函数应用。
在左侧面板中，向下滚动至“监视”，然后选择“指标” 。
在“指标”中，为“聚合”选择“函数执行计数”和“求和”。 这会在图表中将所选时间段内的执行计数之和相加。
选择“添加指标”并重复步骤 2-4，将“函数执行单位”添加到图表中。
生成的图表包含所选时间范围内（在本例中为 2 小时）两个执行指标的总和。
由于执行单位数远远大于执行计数，因此图表只显示执行单位。
此图显示两小时时间段内总共消耗了 11.1 亿个 Function Execution Units（以“MB 毫秒”度量）。 若要转换为 GB 秒，请除以 1024000。 在此示例中，函数应用消耗了 1110000000 / 1024000 = 1083.98 GB 秒。 可以将此值乘以 Functions 定价页上执行时间的当前价格，从而得出这两个小时的成本（假设已用完了所有免费授予的执行时间）。
函数级指标
函数执行单位是执行时间与内存用量的组合，因此很难使用此指标来了解内存用量。 目前无法通过 Azure Monitor 获取内存数据这一指标。 但是，如果要优化应用的内存用量，可以使用 Application Insights 收集的性能计数器数据。
如果尚未执行此操作，你可以在函数应用中启用 Application Insights。 启用此集成后，你可以在门户中查询此遥测数据。
可以使用 Azure 门户中的 Azure Monitor 指标资源管理器或使用 REST API 来获取 Monitor 指标数据。
确定内存用量
在“监视”下选择“日志(分析)”，复制以下遥测查询并将其粘贴到查询窗口中，然后选择“运行”。 此查询返回每个采样时间的总内存用量。
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
结果类似于以下示例：
| timestamp [UTC] | name | 值 |
|---|---|---|
| 9/12/2019, 1:05:14.947 AM | 专用字节数 | 209,932,288 |
| 9/12/2019, 1:06:14.994 AM | 专用字节数 | 212,189,184 |
| 9/12/2019, 1:06:30.010 AM | 专用字节数 | 231,714,816 |
| 9/12/2019, 1:07:15.040 AM | 专用字节数 | 210,591,744 |
| 9/12/2019, 1:12:16.285 AM | 专用字节数 | 216,285,184 |
| 9/12/2019, 1:12:31.376 AM | 专用字节数 | 235,806,720 |
确定持续时间
Azure Monitor 可跟踪资源级指标，对于函数来说，就是跟踪函数应用指标。 Application Insights 集成会发出每个函数的指标。 下面是一个示例分析查询，可用于获取函数的平均持续时间：
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| QueueTrigger AvgDurationMs | 16.087 |
| QueueTrigger MaxDurationMs | 90.249 |
| QueueTrigger MinDurationMs | 8.522 |