次の方法で共有

估算基于消耗的成本

本文介绍如何估算旧 消耗计划的计划成本。

选择最能支持您的函数执行所需功能、性能和成本要求的托管选项。 有关详细信息，请参阅 Azure Functions 缩放和托管。

本文重点介绍这两个消耗计划，因为这些计划中的计费取决于每个实例内的活动执行期。

当您的应用程序必须在 Windows 系统上、Functions 运行时版本 1.x、完整 .NET Framework 环境中运行，或完全支持 PowerShell 时，提供动态缩放和无服务器托管。 使用弹性消耗计划托管新应用，除非你的应用需要这些专用的托管条件。 有关详细信息，请参阅 Azure Functions 按需计划托管。

Durable Functions 还可以在这两个计划中运行。 有关使用 Durable Functions 时的成本注意事项的详细信息，请参阅 Durable Functions 计费。

基于消耗的成本

基于消耗的成本（包括免费给予）的计算方式视具体计划而定。 有关最新的成本和资助信息，请参阅Azure 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 存储队列，则执行时间包括将该消息写入该队列所花费的时间，而函数成本计算包括该写入时间。

  • 异步执行：函数等待异步请求await （以 C# 为单位）的结果的时间计为执行时间。 “GB 秒”计算基于函数的开始和结束时间，以及该时间段内的内存用量。 在 CPU 活动方面，在该时间发生的情况不会纳入计算中。 可能也可以使用 Durable Functions 来降低异步操作期间产生的成本。 协调器功能中的等待时间不产生费用。

从指标中查看和估算成本

在 发票中，可以查看与成本相关的数据以及实际计费成本。 但是，此发票数据是过去发票期限的每月聚合。

本部分介绍如何使用应用级和函数执行的指标来估算运行函数应用的成本。

函数应用级指标

使用 Azure Monitor 指标资源管理器以图形格式查看您的消耗计划函数应用的成本相关数据。

  1. 在Azure 门户中，访问您的函数应用。

  2. 在左侧面板中，向下滚动到 “监视 ”并选择“ 指标”。

  3. 从指标中，选择函数执行计数和总和用于聚合。 此选择将所选时间段内执行计数的总和添加到图表中。

    定义要添加到图表中的函数应用指标

  4. 选择“添加指标”并重复步骤 2-4，将“函数执行单位”添加到图表中。

生成的图表包含所选时间范围内（在本例中为 2 小时）两个执行指标的总和。

函数执行计数和执行单位图表

由于执行单位数远大于执行计数，因此图表仅显示执行单位。

此图显示两小时时间段内总共消耗了 11.1 亿个 Function Execution Units（以“MB 毫秒”度量）。 若要转换为 GB 秒，请除以 1,024,000。 在此示例中，函数应用消耗了 1,110,000,000 / 1,024,000 = 1,083.98 GB 秒。 将此值乘以 Functions 定价页上当前执行时间的价格，从而得出这两个小时的成本，假设你已经使用了所有免费提供的执行时间。

函数级指标

估算函数执行的成本时，内存使用率非常重要。 但是，内存使用量影响成本的方式取决于特定的计划类型：

在消耗计划中，计费基于合并执行时间和内存使用情况的函数执行单位。 有关详细信息，请参阅 计费。

目前无法通过 Azure Monitor 获取内存数据这一指标。 但是，如果要对应用的内存使用情况进行建模或优化，可以使用 Application Insights 收集的性能计数器数据。

如果尚未执行此操作，你可以在函数应用中启用 Application Insights。 启用此集成后，你可以在门户中查询此遥测数据。

可以使用 Azure 门户中的 Azure Monitor 指标资源管理器或使用 REST API 来获取 Monitor 指标数据。

确定内存用量

在“监视”下选择“日志(分析)”，复制以下遥测查询并将其粘贴到查询窗口中，然后选择“运行”。 此查询返回每个采样时间的总内存用量。

performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value

结果类似于以下示例：

时间戳 [UTC] 姓名 值
2019/9/12，上午 1：05：14.947 专用字节数 209,932,288
2019/9/12，上午 1：06：14.994 专用字节数 212,189,184
2019/9/12，上午 1：06：30.010 专用字节数 231,714,816
2019/9/12，上午 1：07：15.040 专用字节数 210,591,744
2019/9/12，上午 1：12：16.285 专用字节数 216,285,184
2019/9/12，上午 1：12：31.376 专用字节数 235,806,720

确定持续时间

Azure Monitor 可跟踪资源级指标，对于函数而言，就是函数应用。 Application Insights 集成会为每个函数发出指标。 下面是一个示例分析查询，可用于获取函数的平均持续时间：

customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
姓名 平均持续时间毫秒
队列触发器 平均持续时间（毫秒） 16.087
QueueTrigger MaxDurationMs 90.249
队列触发器 最短持续时间毫秒 8.522

在估算任何计划中运行函数的总体成本时，请记住，函数运行时将使用其他多个 Azure 服务，而每个服务单独计费。 在为函数应用定价时，任何与其他 Azure 服务集成的触发器和绑定都需要您创建并支付这些服务的费用。

对于在消耗计划中运行的函数，总成本是函数的执行成本加上带宽和附加服务的成本。

估算函数应用和相关服务的总体成本时，请使用 Azure 定价计算器。

相关成本 说明
存储帐户 每个函数应用都需要一个关联的常规用途Azure 存储帐户，该帐户单独计费。 函数运行时在内部使用此帐户，但你也可以将其用于存储触发器和绑定。 如果你没有存储帐户，系统会在创建函数应用时创建一个存储帐户。 有关详细信息，请参阅存储帐户要求。
Application Insights 函数依赖 Application Insights 来为函数应用提供高效的监控体验。 虽然未强制要求，但你应启用 Application Insights 集成。 每月都会免费提供遥测数据。 要了解详细信息，请参阅 Azure Monitor 定价页。
网络带宽 根据数据移动的方向和方案，可能会产生数据传输费用。 有关详细信息，请参阅带宽定价详细信息。

后续步骤

详细了解监视函数应用

  • Last updated on