Azure IoT Hub常見問題,azure iot優(yōu)勢-ESG跨境

Azure IoT Hub常見問題,azure iot優(yōu)勢

Azure IoT Hub常見問題

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

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

如果要調試該狀態(tài)，可以在IoT hub中配置 診斷設置 到Log Analytics工作區(qū)：

輸出到Log Analytics工作區(qū)中：

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

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

關于此現(xiàn)象官網的解釋：

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

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

例如，使用 Java SDK 的設備會發(fā)快遞 keepalive ping，然后失去網絡連接。230 秒后，設備會由于處于脫機狀態(tài)而錯過 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.mc_595">設備可注冊到單個 IoT 中心的設備和模塊的總數上限為 1,000,000。只能聯(lián)系 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 個新連接/秒/單位

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

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

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

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

流量整形

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

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

參考：

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

文章推薦
Android平臺集成華為AGC性能管理服務問題處理指南,華為agc性能解決方案
Audience Network 流程類型 常見用戶互動模式介紹,audience network是什么
Google AdMob原生廣告模板,google 效果最大化廣告系列
AppLovin深圳分享會干貨總結

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