我有一个Azure IoT中心应用程序，并且一个设备刚刚开始每隔一秒钟发送一次消息，该消息指示所报告的设备孪生属性发生了变化。在短短几个小时内，当天的总消息量超过了5万。当这个数字达到40k时，IoT集线器对所有客户的响应变得非常慢-不仅是在关闭设备之前，而且直到所有这些消息都设法在整个系统中节流为止，这似乎是在几个小时之后或直到第二天早上
因此，如果发生这种类型的洪水，则所有客户的整个系统都会因运行缓慢而停止运行。
这是一个设备错误，需要修复，但是我想知道是否有办法（如果发生这种情况）使整个IoT中心恢复正常，并且速度不慢？诸如踢问题设备或重新启动集线器之类的东西。或更好的是-有什么方法可以防止设备泛滥集线器的速度快于每分钟x消息之类的速度？
答案 0 :(得分：0)
您可以构建一些逻辑，以便在有问题的设备开始向您的集线器发送垃圾邮件时将其踢出。一种方法可能是将所有twinChangeEvents路由到一个单独的端点，并编写一个Stream Analytics Job来对每个deviceId的消息进行分组，并将事件计数保持在X分钟的滑动窗口中。当计数达到您设置的阈值后，您可以调用Azure函数以禁用设备并发送通知。
有一个警告，docs状态：
如果变化率太高，或其他原因，例如 内部故障，IoT中心可能仅发送一条通知 包含所有更改。
我不知道您的设备是否达到了该速度，但是我认为这是一种合适的方法来踢问题设备。
答案 1 :(得分：0)
根据您购买的等级和单位，一旦达到限制，物联网中心将开始拒绝您的消息。现在，要处理过多的消息，要么达到限制，要么IoT中心在处理消息you should auto-scale your IoT hub时很慢。
根据上面提供的链接中的文档：-
本文概述的示例解决方案提供了监视IoT中心的功能，以防当前消息数超过设置的阈值（例如，所允许消息的90％），并且在这种情况下，以自动将IoT中心扩展到下一个容量单位。
最终，您还需要自动缩小IoT中心的规模，以使在获得低流量的情况下IoT中心的成本不高。检查上方文章链接中的Scaling down部分。