Azure IoT Hub常見問題,microsoft azure文字轉語音

Azure IoT Hub常見問題

使用Event訂閱Azure IoT Hub設備上下線，如果不發快遞消息，每隔一段時間會收到一次上下線通知：

所有的SDK的令牌有效期為默認60分鐘，令牌續訂有效期約為 85%，即 60*0.85= 50分鐘左右， 在默認的SAS令牌到期后，如果沒有任何流量來刷新token，則會遇到IoT Hub斷開設備，設備再重連的情況。

如果要調試該狀態，可以在IoT hub中配置 診斷設置 到Log Analytics工作區：

輸出到Log Analytics工作區中：

在日志中輸入如下指令，可以查詢到 404104 和401003的設備 deviceDisconnect 和deviceConnect的事件，事件每50分鐘左右出現一次。

AzureDiagnostics where ResourceProvider == MICROSOFT.DEVICES and ResourceType == IOTHUBS where Category == Connections extend parsedjson = parsejson(propertiess) extend SDKVersion = tostring(parsedjson.sdkVersion) , DeviceId = tostring(parsedjson.deviceId) , Protocol = tostring(parsedjson.protocol) distinct TimeGenerated, OperationName, Level, ResultType, ResultDescription, DeviceId, Protocol, SDKVersion

關于此現象官網的解釋：

https://docs.microsoft.com/zhcn/azure/iothub/iothubtroubleshootconnectivity WT.mc352">Node.js180 秒否Java230 秒否C240 秒是C#300 秒是Python60 秒否

按照 MQTT 規范，IoT 中心的 keepalive ping 時間間隔是客戶端 keepalive 值的 1.5 倍。但是，IoT 中心將服務器端最大超時限制為 29.45 分鐘（1767 秒），因為所有 Azure 服務都綁定到了 Azure 負載均衡器 TCP 空閑超時（29.45 分鐘）。

例如，使用 Java SDK 的設備會發快遞 keepalive ping，然后失去網絡連接。230 秒后，設備會由于處于脫機狀態而錯過 keepalive ping。但是，IoT 中心不會立即關閉連接 它會再等待(230 * 1.5) 230 = 115秒，然后再斷開設備的連接，并顯示錯誤 404104 DeviceConnectionClosedRemotely。

可設置的客戶端最大 keepalive 值為1767 / 1.5 = 1177秒。任何流量都將重置 keepalive。例如，成功的 SAS 令牌刷新會重置 keepalive。

參照官網：

https://docs.microsoft.com/zhcn/azure/iothub/iothubmqttsupport?WT.mc595">設備可注冊到單個 IoT 中心的設備和模塊的總數上限為 1,000,000。只能聯系 Microsoft 支持部門來提高此限制。

但請注意，100萬設備連接到云中，是需要一定時間的，這個受限于連接速率：

“設備連接” 限制控制與 IoT 中心建立新設備連接的速率。“設備連接” 限制不控制同時連接的最大設備數。設備連接 速率限制取決于為 IoT 中心預配的單位數。

例如，如果購買的是單一 S1 單位，則限制為每秒 100 個連接。因此，若要連接 100,000 臺設備，至少需要花費 1,000 秒（大約 16 分鐘）。但是，同時連接的設備數可與用戶在標識注冊表中注冊的設備數相同。

具體的連接速率參考：

限制免費、B1 和 S1B2 和 S2B3 和 S3

新設備連接（此限制適用于建立新連接的速率，而不是連接總數）	高于 100/秒或 12/秒/單位例如， 底線是100個連接/秒，兩個 S1 單位是 2*12 = 24 個新連接/秒，該值 100，則按100進行限制。 如果有 9 個 S1 單位，則你的單位就有 108 個新連接/秒 (9*12)。	120 個新連接/秒/單位	6,000 個新連接/秒/單位

此外，設備到云的消息發快遞也是有速率限制的：

在設計物聯網系統時，要充分考慮這些限制條件，才能決定是將 S1 升級到S2 或者增加S1 的單元數。

限制免費、B1 和 S1B2 和 S2B3 和 S3

設備到云的發快遞	100 個發快遞操作/秒或 12 個發快遞操作/秒/單位，具體取決于哪一個更高例如，兩個 S1 單位是 2*12 = 24/秒，但是在所有單位中至少有 100 個發快遞操作/秒。如果有 9 個 S1 單位，則你的單位就有 108 個發快遞操作/秒 (9*12)。	120 個發快遞操作/秒/單位	6,000 個發快遞操作/秒/單位
云到設備的發快遞1	1.67 個發快遞操作/秒/單位（100 條消息/分鐘/單位）	1.67 個發快遞操作/秒/單位（100 個發快遞操作/分鐘/單位）	83.33 個發快遞操作/秒/單位（5,000 個發快遞操作/分鐘/單位）
云到設備的接收1（僅當設備使用 HTTPS 時）	16.67 個接收操作/秒/單位（1,000 個接收操作/分鐘/單位）	16.67 個接收操作/秒/單位（1,000 個接收操作/分鐘/單位）	833.33 個接收操作/秒/單位（50,000 個接收操作/分鐘/單位）

流量整形

為了應對突發流量，IoT 中心可在有限的一段時間內接受超出限制的請求。其中的前幾個請求會立即得到處理。但是，如果請求數持續違反限制，IoT 中心會開始將請求放入隊列，并以限制速率對請求進行處理。此效應稱為“流量整形”。此外，此隊列的大小受到限制。如果違反限制的情況持續出現，隊列最終將會填滿，而 IoT 中心會開始拒絕請求并引發429 ThrottlingException。

例如，如果你使用模擬設備每秒將 200 條設備到云的消息發國際快遞 S1 IoT 中心（它限制為每秒發快遞 100 條 D2C 消息）。在前一兩分鐘，消息會立即得到處理。但是，由于設備發快遞的消息數持續超過限制，IoT 中心隨后將每秒處理 100 條消息，并將剩余的消息放入隊列。此時你會注意到延遲增大。最終，在隊列填滿后，你會開始收到429 ThrottlingException，并且“限制錯誤數”IoT 中心指標會開始增加。若要了解如何基于指標創建警報和圖表，請參閱監視 IoT 中心。

參考：

https://docs.microsoft.com/zhcn/azure/iothub/iothubdevguidequotasthrottling?WT.mcid=AZMVP5003757

文章推薦
AWS攜手海信聚好看科技,海信bcd270tdaws
AWS、Vmvare和Openstack三種云架構對比,openstack云主機使用
從國外進口的二手挖掘機報關,二手挖掘機進口報關流程需要資料
Azure Stack HCI 安全注意事項,azure stack知乎

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。