我有一个使用 EventGridTrigger
运行时 v2
和语言 C#
的 Azure 函数应用。该函数订阅源自 azure 订阅的所有事件。我的主要目标是处理有关虚拟机的 start
和 stop
操作的事件,然后在收到这些事件时执行某些操作。
但是,我注意到事件中记录的 EventTime
与函数应用中接收该事件的时间之间存在大约 30 - 120 秒的延迟。我通过确保在触发事件之前重新启动应用程序来验证这不是冷启动问题。对我来说,这听起来更像是一个 azure 的计算问题。
例如,我重新启动了我的应用程序。然后,我在 Azure 门户中点击了虚拟机的 Start
按钮。一段时间后,当虚拟机启动时, azure 计算会向事件网格发送一个事件,我的函数应用程序会接收该事件并仅记录该事件以及事件时间。 (见下图)。
请注意,EventTime (12:44:05 AM) 与函数接收并记录事件时间 (12:45:52 AM) 之间存在大约 107 秒的延迟。
为了更深入地研究,我尝试检查在推送自己的事件时是否看到类似的延迟。我创建了一个自定义主题,并订阅了该主题的另一个函数。然后我使用 Azure Cloud Shell 将事件推送到我的自定义主题。在本例中,我可以看到我的函数几乎立即收到了该事件。 延迟小于1秒。
这向我表明,EventGrid 本身很快,但 Azure 计算(VM 基础设施)推送事件的速度很慢。例如,如果它使用 EventTime
t
创建一个事件对象,但随后在 (t+t1)
时间发布它,那么当然是 EventGrid对于事件到达 EventGrid 之前引入的 t1
延迟无能为力。
我的理解(/推测)正确吗?有没有办法更快地收到通知(<10 秒延迟)?
最佳答案
我同意@SeanFeldman 的观点。我已经测试了不同位置的五个虚拟机和服务总线队列的 AEG 订阅者。
我已经使用了REST API用于启动和取消分配虚拟机。要了解已使用 VM 的状态,请使用 REST Get Instance View请求。
结果如下:
启动虚拟机示例:
实例查看响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:18:15.8833099-07:00"
},
{
"code": "PowerState/running",
"level": "Info",
"displayStatus": "VM running"
}
]
有趣的(可用)时间:
"time": "2019-08-10T11:18:15.8833099-07:00"
"eventTime": "2019-08-10T18:18:29.5645489Z",
EnqueuedTimeUtc: 8/10/2019 6:19:54 PM
以上时间显示,当 VM 运行时 (time),AEG 事件消息已在 ~15 秒 (eventTime) 后创建)。 AEG 在 ~100 秒 (EnqueuedTimeUtc) 后将事件消息推送到订阅者队列。
解除分配虚拟机示例:
实例查看响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:51:11.9832611-07:00"
},
{
"code": "PowerState/deallocated",
"level": "Info",
"displayStatus": "VM deallocated"
}
]
有趣的(可用的)时间:
"time": "2019-08-10T11:51:11.9832611-07:00"
"eventTime": "2019-08-10T18:51:24.7467938Z",
EnqueuedTimeUtc: 8/10/2019 6:52:58 PM
请注意,上述延迟也可以在 VM/Active 日志门户页面中看到。
关于azure - Azure 计算将事件推送到 Azure EventGrid 时是否很慢?有没有办法更快地获取事件?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57438989/