我在消费计划上运行一个Azure功能。我已经选择了无服务器功能的消费计划以及最小化成本。该函数使用来自服务总线主题的消息,并将一些输出写入blob存储。
保持功能运行最近30天大约是10美元。这是非常可以接受的,因为该函数有很多消息要消耗。将输出写入blob存储大约是20美元。也可以接受。我不明白的是,功能的底层存储帐户的费用在同一时期约为70美元。消耗主要是命中文件写入操作单元和文件协议操作单元。存储帐户创建为本地冗余通用v1。
任何人都能解释这里发生了什么?查看存储帐户时,会有一些blob。我认为问题在于表存储。检查存储帐户时,有如下表格:
$MetricsCapacityBlob
$MetricsHourPrimaryTransactionBlob
AzureWebJobsHostLogs201804
通过删除 AzureWebJobsDashboard 应用设置,我已禁用我的功能中的日志记录。执行此操作后,AzureWebJobsHostLogs *表似乎不再接收新行。但$ Metrics *表仍然会收到新数据。如果对这些表的写入导致我在Portal中的Costs Management视图中看到的所有文件写入活动,我都不知道。
这里发生了什么?是否真的需要从无服务器代码维护这些表,并且表访问的价格是函数本身价格的x7听起来是否正常?
答案 0 :(得分:1)
有趣且不寻常的是,您的存储成本要高得多。我认为仪表板日志记录可能是罪魁祸首,因此如果您在接下来的几天内看到它已关闭,那将是很好的理解。
我会在Azure门户的成本分析部分花费更多时间,看看您是否可以获得有关存储使用的哪个方面正在推动大部分成本的更多详细信息。即它是关于表操作,blob操作等。此屏幕截图显示了每米分类的成本历史记录视图。请注意此屏幕截图中的工具提示:
$ Metrics表不是由Azure Functions编写的,它们由Azure存储本身生成。如果这些指标对您的总体成本有显着贡献,我会感到惊讶。但是,如果您想进行实验,我认为您可以通过此UX禁用它们:
为了给出关于存储成本与功能执行成本的比率预期的基线,您可能需要查看我在此博客文章中所做的成本编写: https://blogs.msdn.microsoft.com/appserviceteam/2017/09/19/processing-100000-events-per-second-on-azure-functions/
您会注意到存储成本低于功能,并且由于事件中心处理需要将检查点写入存储,因此包括大量存储操作。我注意到这些测试是在仪表板注销的情况下运行的(再次让我怀疑是主要的成本驱动因素)。所以不,你的存储成本是你的功能成本的7倍是不正常的!
答案 1 :(得分:1)
您应该在Azure门户中为此存储帐户转到Metrics
,并检查如何使用文件存储事务的模式。如果一直很高,则说明您的应用程序有问题(例如,过多的日志记录到文件中)。
就我而言,它似乎是Azure Functions中的一个错误,我提交了一个错误here。
在任何代码更改之后,该函数开始消耗数万个读取和写入事务,无论这些更改多么小。因此,基本上每个代码更改或部署都可能使我花费约0.20美元,并且在您的情况下可能更多。
这很容易在“度量标准”图中看到,因为它看起来像是交易中的巨大峰值。
因此解决方案是:不要将日志写入文件系统并且不要经常部署。