昂贵地使用Azure Functions的存储帐户 [英] Expensive use of storage account from Azure Functions
问题描述
我正在消费计划上运行一个Azure功能.我已经选择了无服务器功能的使用计划，并最大程度地降低了成本.该功能使用来自服务总线主题的消息，并将一些输出写入Blob存储.
I'm running a single Azure Function on the consumption plan. I've picked the consumption plan for the serverless feature as well as to minimize cost. The function consumes messages from a service bus topic and writes some output to blob storage.
让该功能运行最近30天大约需要10美元.这是非常可以接受的，因为该函数有很多消息要使用.将输出写入Blob存储大约需要20美元.也可以接受.我不明白的是，该功能的基础存储帐户在同一时期的费用约为70美元.消耗主要是达到文件写入操作单元和文件协议操作单元.该存储帐户被创建为本地冗余通用v1.
Keeping the function running for the last 30 days is around $10. That's very acceptable, since the function has a lot of messages to consume. Writing the output to blob storage is around $20. Also acceptable. What I don't understand is, that the charge for the Function's underlying storage account is around $70 for the same period. The consumption is primarily hitting File Write Operation Units and File Protocol Operation Units. The storage account is created as locally redundant general purpose v1.
任何人都可以解释这里发生了什么吗?查看存储帐户时，有一些斑点.我相信问题出在表存储上.检查存储帐户时，有些表如下所示:
Anyone able to explain what's going on here? When looking at the storage account, there's a few blobs. I believe the problem is with tables storage. When inspecting the storage account, there are tables looking like this:
$MetricsCapacityBlob
$MetricsHourPrimaryTransactionBlob
AzureWebJobsHostLogs201804
$MetricsCapacityBlob
$MetricsHourPrimaryTransactionBlob
AzureWebJobsHostLogs201804
通过删除 AzureWebJobsDashboard 应用程序设置，我已禁用了登录功能.这样做之后，AzureWebJobsHostLogs *表似乎不再接收新行.但是$ Metrics *表仍然接收新数据.我不知道这些表的写入是否会导致我在门户网站的成本管理"视图中看到的所有文件写入活动.
I've disabled logging in my function, by removing the AzureWebJobsDashboard app setting. After doing so, the AzureWebJobsHostLogs* tables no longer seems to receive new rows. But the $Metrics* tables still receive new data. I have no clue if writes to these tables are causing all of the file write activity I see in the Costs Management view in the Portal, though.
这是怎么回事?是否真的需要通过无服务器代码维护这些表，并且表访问的价格是函数本身的价格的7倍，这听起来很正常吗?
What's going on here? Is maintaining these tables from serverless code really required and does it sound normal that the price for table access is x7 the price of the function itself?
推荐答案
您应该为此存储帐户转到Azure Portal中的Metrics，并检查如何使用文件存储事务的模式.如果一直很高，那么这与您的应用程序有关(例如，过多的日志记录到文件中).
You should go to Metrics in Azure Portal for this storage account and check the patterns of how the File storage transactions are consumed. If it's consistently high, it's something with your application (e.g. too much logging to file).
就我而言，这似乎是Azure Functions中的一个错误，我提交了一个错误
In my case, it appears to be a bug in Azure Functions, and I filed a bug here.
在任何代码更改之后，该函数开始消耗数万个读取和写入事务，无论这些更改是次要的.因此，基本上每个代码更改或部署使我花费大约0.20美元，而在您的情况下可能会更高.
The function starts consuming tens of thousands of read and write transactions after any code change, however minor. So basically each code change or deployment costs me perhaps around $0.20, and it could be more in your case.
这很容易在度量标准"图中看到，因为它看起来像是交易中的巨大峰值.
This is easy to see in the Metrics diagram because it looks like a huge spike in transactions.
因此解决方案是:不要将日志写入文件系统并且不要经常部署.
So the solution is: don't write logs to the filesystem and don't deploy often.
这篇关于昂贵地使用Azure Functions的存储帐户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
