问题标签 [azure-eventgrid]

我正在学习 Azure 服务总线和 Functinos。我创建了一个服务总线命名空间、命名空间下的主题和对该主题的订阅。

然后我将 Service Bus 命名空间的事件网格绑定到 Azure 函数的 EndPoint 以处理 SB 消息。

当我向服务总线主题发送几条消息时，我可以从 Azure 功能的“监视器”中看到，它大约每 2 分钟触发一次。该函数只输出消息，不会花费很长时间。我希望每当有消息发送到主题时都会触发该功能，但似乎没有，为什么会这样？

顺便说一句，如果我想保持 Azure 功能一个接一个地接收和处理消息（不是并行），我该如何配置它？

谢谢

我在我们当前的项目中使用事件网格。我为每种事件类型创建了多个主题端点，但空间不足。现在我想重用现有的主题，所以我计划以下两个选项。

1. 少数事件类型的一个主题（或）
2. 所有事件类型只有一个主题。

我有以下问题/确认。

1. 性能影响如果我采用第二种方法，那么我应该去为少数事件设置一个主题还是只保留一个主题。

我在 logicapp 中使用发布事件

所以我尝试发送示例消息

但仍然得到相同的结果。

我尝试使用 IoT 中心 -> 事件 -> + 事件订阅将某个 IoT 中心的连接/断开连接事件连接到存储队列，但从未收到任何事件或错误。事件边栏选项卡既不显示事件也不显示错误。通过诊断接收这些事件的事件中心工作正常，并且我检查了事件网格订阅在禁用诊断时也不起作用。

我已经尝试了两个具有相同和不同队列存储的不同 IoT 中心，并且它们都有效，所以我怀疑我正在尝试设置的特定 IoT 中心有些有趣，或者与其他设置的一些交互会破坏事件网格. 是否有任何调试或日志记录可以阐明这个问题？

我注意到，突然之间，主题不再作为服务总线的一部分提供。是否可以将消息写入 Azure 函数中的事件网格主题？

我需要进行设备的正常运行时间统计。我想从日志中获取有关连接/断开连接的信息，但我不知道从 IoT 中心记录这些事件的最佳方式是什么。

我已经尝试过：

• 事件网格。不是很好，因为：根据文档，“不能保证事件的顺序” 。
• IoT 中心的诊断：“IoT 中心服务使用 Azure Monitor 诊断日志发出的事件不能保证可靠或有序。某些事件可能会丢失或无序传递。”
• 设备心跳：来自文档：“仅在开发和调试期间使用 connectionState 字段”。
• 功能应用或逻辑应用：如何通过连接/断开来触发？

我还能尝试什么？

我有一个 Azure 函数应用程序，当它通过 ngrok 托管在开发机器上时，我可以创建一个 EventGrid 订阅，但完全相同的函数在发布到 Azure 时不会接受订阅。

错误是“验证提供的端点 <> 的尝试失败”。

我已经考虑了一些明显的事情，比如 url 的长度，但这似乎不是原因。两个 url 之间的唯一区别是主机，如函数应用程序的主机 url 和 ngrok 生成的主机。我已经尝试使用门户和 CLI 创建具有相同结果的订阅。

任何想法如何解决这一问题？

我正在使用 ARM 模板创建 EventGrid API 连接。它已成功创建，但是，我仍然必须通过 Azure 门户手动对其进行身份验证。

这是我的 ARM 模板：

1. 我是否遗漏了模板中负责立即验证连接的内容？

2. 有没有办法使用例如 Azure PowerShell 来验证该连接，以便我可以自动化该过程？

我正在尝试解决这个问题

我按照这个创建了服务主体

在订阅上授予服务主体 Contributor 。

当我转到 Logic 应用程序时，使用服务主体的连接成功，我

1. 选择“发生资源事件时”
2. 选择我的订阅
3. 为资源类型选择 GridTopics
4. 资源名称下拉错误“无法检索值”

在周五的客户测试期间，我注意到 Blob 存储事件的一些奇怪行为，现在我想知道是否存在导致双重事件（已创建 Blob）触发的已知情况。

所以基本上外部应用程序将 blob 写入容器。大多数 blob 像往常一样只触发一个 blob 创建事件，但由于某种原因，*.zip blob（并且只有那些）会导致两个事件彼此靠近触发（相隔 < 0.5 秒）。zip 文件大小通常约为 200-250 kB。

早些时候我看到过类似的问题，但在这些情况下，第一个事件总是伴随着

...这也使它们很容易被过滤掉。

但在这种情况下，我得到两个不同的事件，它们都具有相同（和实际）的 blob 大小。

这自然也可能是由发件人应用程序引起的，我正在努力让正确的人在线，以便能够验证和修复，或者可能重现或使用我自己的测试代码发出问题。

但是是否有更详细的规范来描述这些事件是如何从 Blob 存储中触发的。我也很好奇是否有任何方法可以避免创建有时似乎发生的 0 长度事件。

编辑：好吧，终于确认这实际上是发送系统中的一个错误，所以在这种情况下我们没有问题。但是，如果有人知道究竟是什么触发了那些可能的“零内容长度”事件，那也将有助于规划未来的解决方案。