Azure Functions: timer trigger and consumption plan issue(Azure Functions:计时器触发器和消费计划问题)
问题描述
在我的开发环境中,我有一个包含 21 个函数的 Azure Functions,应用计划是消费.
In my dev environment, I have an Azure Functions with 21 functions and the app plan is consumption.
一些函数有一个计时器触发器,并且在进程结束时每个函数都会发送一封电子邮件.我有 2 种类型的计时器触发器:
Some functions have a timer trigger and at the end of the process each function sends an email. I have 2 type of timer trigger:
- 每 20 分钟运行一次函数
- 在夜间的特定时间运行一次函数
每隔 20 分钟,该功能就会按照我的预期进行.太好了.
Every 20 minutes the function is doing what I expect. Great.
我面临的问题是他们必须在特定时间启动的功能.基本上,直到我打开门户并在 Azure Function 上执行某些操作(例如打开其中一个监视器),它们才会启动.
The problem I'm facing is with the function that they have to start at a particular time. Basically, they don't start until I open the portal and do something on the Azure Function (for example open the monitor for one of them).
从代码上看,所有带定时器触发的函数都是这样定义的:
In the code point of view, all functions with the timer trigger are defined like that:
[FunctionName("invoiceMonthlyGeneratorTimer")]
public void Run([TimerTrigger("%Timers:GenerateMonthlyInvoices%")] TimerInfo myTimer)
{
// ..
}
[FunctionName("invoiceDunningTimer")]
public async Task Run([TimerTrigger("%Timers:DunningTimer%")] TimerInfo timer)
{
// ...
}
定时器的配置在设置文件中,如:
The configuration of the timer is in the settings file like:
"Timers": {
"DunningTimer": "0 0 4 * * *",
"GenerateMonthlyInvoices": "0 0 4 * * *"
}
一般来说,这种方法在开发环境中运行良好,在生产环境中运行良好.
Generally, speaking, this approach was working in dev environment and it is working perfectly in the production environment.
因为每个函数都会发送一封电子邮件,我希望每天早上都能在我的收件箱中找到一些电子邮件,但它并没有发生.然后,我打开 Azure 门户以查看日志和监视器.
Because each function sends an email, I expect each morning to find in my inbox some emails but it doesn't happen. Then, I open the Azure portal to see the logs and the monitor.
在门户中打开 Azure 功能.
Open the Azure function in the portal.
打开一个函数的监视器
瞧,几秒钟后,我开始收到所有服务的电子邮件!在生产环境中,我没有 dev 中的所有功能,因为我想在部署之前进行测试.在 prod 中,这些功能运行良好,并且在正确的时间启动.
Voila, after a couple of seconds, I start to receive the email for all services! In the production environment I don't have all the function I have in dev because I want to test before deploying. In prod the functions are working fine and start at the right time.
如果我查看 Application Insights,我只能找到打开监视器时的日志.
If I look at Application Insights, I can find only the logs for the time I opened the monitor.
日志中有一件有趣的事情:
There is one interesting thing in the log:
触发器详细信息:UnscheduledInvocationReason:IsPastDue,OriginalSchedule:2020-07-24T05:00:00.0000000+00:00
Trigger Details: UnscheduledInvocationReason: IsPastDue, OriginalSchedule: 2020-07-24T05:00:00.0000000+00:00
显然,在同一个 Azure Functions 中不能有多个计时器触发器.我在 Github 上打开了一个问题,所以如果其他开发人员也面临同样的问题.与 HTTP 触发器类似的东西,看看这个 post.
Apparently, you can't have more than a couple of timer triggers in the same Azure Functions. I opened an issue on Github, so if other devs are facing the same. Something similar with HTTP triggers, look this post.
推荐答案
您的函数应用中的函数太多,它们可能会相互交互.我遇到了类似的问题,在这种情况下,计时器触发器在一个功能应用程序中起作用并且不起作用.但是当我将它们部署到不同的功能应用程序时,它们工作正常.因此您可以尝试将您的第二个函数部署到另一个函数应用.
There are too many functions in your function app, they may interact each other. I met similar problem with this, in that case, the timer trigger functions in one function app and did not work. But when i deploy them to different function apps, they work fine. so you can try to deploy your second function to another function app.
而且我建议你把这个问题报告给微软,他们可以知道更多关于这个问题的信息,并且可能有更好的解决方案.
And I suggest you report this problem to Microsoft, they can know more information about this problem, and may have a better solution.
这篇关于Azure Functions:计时器触发器和消费计划问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:Azure Functions:计时器触发器和消费计划问题
基础教程推荐
- 有没有办法忽略 2GB 文件上传的 maxRequestLength 限制? 2022-01-01
- 将 Office 安装到 Windows 容器 (servercore:ltsc2019) 失败,错误代码为 17002 2022-01-01
- MS Visual Studio .NET 的替代品 2022-01-01
- SSE 浮点算术是否可重现? 2022-01-01
- rabbitmq 的 REST API 2022-01-01
- 为什么Flurl.Http DownloadFileAsync/Http客户端GetAsync需要 2022-09-30
- c# Math.Sqrt 实现 2022-01-01
- 如何在 IDE 中获取 Xamarin Studio C# 输出? 2022-01-01
- 如何激活MC67中的红灯 2022-01-01
- 将 XML 转换为通用列表 2022-01-01