Решения распространенных проблем с Azure IoT Edge

Область применения: IoT Edge 1.5 IoT Edge 1.4

Используйте эту статью для выявления и устранения распространенных проблем при использовании решений IoT Edge. Если вам нужна информация о том, как найти журналы и ошибки на устройстве IoT Edge, см. статью "Устранение неполадок устройства IoT Edge".

Подготовка и развертывание

Модуль IoT Edge успешно развертывается, но затем исчезает с устройства

Симптомы

После настройки модули для устройства IoT Edge развертываются успешно, но через несколько минут исчезают с устройства, а сведения о них исчезают из раздела сведений об устройстве на портале Azure. На устройстве могут также появляться другие модули, которые не настраивались.

Причина

Если для устройства задано автоматическое развертывание, оно получает приоритет над ручной настройкой модулей для этого устройства. Функции наборов модулей в портал Azure или создании развертывания для отдельных функций устройств в Visual Studio Code вступает в силу в течение некоторого момента. При этом можно видеть, что заданные модули запускаются на устройстве. Затем приоритет автоматического развертывания запускается и перезаписывает требуемые свойства устройства.

Решение

Используйте для каждого устройства только один механизм развертывания: либо автоматическое развертывание, либо развертывание отдельных устройств. Если устройство задано в качестве цели нескольких автоматических развертываний, вы можете изменить приоритет или описания целей развертывания, чтобы к данному устройству применялось то из них, которое нужно. Можно также обновить двойник устройства так, чтобы он более не соответствовал описанию цели автоматического развертывания.

Дополнительные сведения см. в статье Общие сведения об автоматических развертываниях IoT Edge для отдельных устройств или в большом масштабе.

Среда выполнения IoT Edge

Агент IoT Edge останавливается через минуту

Симптомы

Модуль edgeAgent запускается и успешно выполняется около минуты, а затем останавливается. Согласно записям в журналах, что агент IoT Edge пытается установить подключение к Центру Интернета вещей по протоколу AMQP, а затем по тому же протоколу AMQP поверх WebSocket. Когда это осуществить не удается, агент IoT Edge завершает свою работу.

Примеры журналов edgeAgent:

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

Причина

Доступу агента IoT Edge в сеть препятствует конфигурация сети узла. Сначала агент пытается подключиться через AMQP (порт 5671). Если это не удается, он пытается подключиться через WebSocket (порт 443).

Среда выполнения IoT Edge настраивает сеть для всех модулей, с которыми нужно взаимодействовать. В Linux этой сетью является мостовая сеть. В Windows используется NAT. Эта проблема чаще всего встречается на устройствах с Windows, использующих контейнеры Windows с сетью NAT.

Решение

Убедитесь, что есть маршрут к Интернету для IP-адресов, назначенных этой сети моста или сети NAT. Иногда конфигурация VPN на узле переопределяет сеть IoT Edge.

Модуль агента IoT Edge сообщает о "пустом файле конфигурации", и на устройстве не запускаются модули

Симптомы

• Устройству не удается запустить модули, определенные в параметрах развертывания. Выполняется только edgeAgent, но и сообщает пустой файл конфигурации....

• При запуске sudo iotedge check на устройстве он сообщает, что подсистема контейнеров не настроена с параметром DNS-сервера, что может повлиять на подключение к Центр Интернета вещей. Ознакомьтесь https://aka.ms/iotedge-prod-checklist-dns с рекомендациями.

Причина

• По умолчанию IoT Edge запускает модули в собственной изолированной сети контейнеров. Возможно, у устройства возникли проблемы с разрешением DNS-имен в этой частной сети.
• При использовании оснастки установки IoT Edge файл конфигурации Docker отличается. См. вариант решения 3.

Решение

Вариант 1. Настройка DNS-сервера в параметрах подсистемы контейнеров

Укажите DNS-сервер для среды в параметрах обработчика контейнеров, которые применяются ко всем модулям контейнеров, запущенным подсистемой. Создайте файл с именем daemon.json, а затем укажите DNS-сервер для использования. Например:

{
    "dns": ["1.1.1.1"]
}

Этот DNS-сервер имеет общедоступную службу DNS. Однако некоторые сети, такие как корпоративные сети, имеют собственные DNS-серверы и не разрешают доступ к общедоступным DNS-серверам. Таким образом, если пограничное устройство не может получить доступ к общедоступному DNS-серверу, замените его доступным DNS-адресом.

Поместите файл daemon.json в каталог /etc/docker на своем устройстве.

Если в этом расположении уже есть файл daemon.json, добавьте в него ключ dns с нужными параметрами и сохраните файл.

Перезапустите подсистему контейнера, чтобы обновления вступили в силу.

sudo systemctl restart docker

Вариант 2. Настройка DNS-сервера для каждого модуля в параметрах развертывания IoT Edge

Вы можете задать DNS-сервер в параметре createOptions каждого модуля при развертывании IoT Edge. Например:

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

То же самое необходимо сделать для модулей edgeAgent и edgeHub.

Вариант 3. Передача расположения файла конфигурации Docker для проверки команды

Если IoT Edge установлен в качестве привязки, используйте --container-engine-config-file параметр, чтобы указать расположение файла конфигурации Docker. Например, если файл конфигурации Docker расположен по /var/snap/docker/current/config/daemon.jsonадресу, выполните следующую команду: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'

В настоящее время предупреждение по-прежнему отображается в выходных данных проверки iotedge даже после установки расположения файла конфигурации. Проверьте сообщение об ошибке, так как привязка IoT Edge не имеет доступа на чтение к оснастке Docker. Если вы используете проверку iotedge в процессе выпуска, вы можете отключить предупреждающее сообщение с помощью --ignore container-engine-dns container-engine-logrotate параметра.

Модуль агента Edge с подключением LTE сообщает о пустой конфигурации агента пограничных вычислений и приводит к "временной сетевой ошибке".

Симптомы

Устройство, настроенное с подключением LTE, имеет проблемы с начальными модулями, определенными в развертывании. EdgeAgent не может подключиться к Центр Интернета вещей и сообщает о пустой конфигурации пограничного агента и временной сетевой ошибке.

Причина

Некоторые сети имеют нагрузку на пакеты, что делает сеть Docker по умолчанию MTU (1500) слишком высокой и вызывает фрагментацию пакетов, предотвращающую доступ к внешним ресурсам.

Решение

1. Проверьте параметр MTU для сети Docker.

   docker network inspect <network name>

2. Проверьте параметр MTU для адаптера физической сети на устройстве.

   ip addr show eth0

Если для сети Docker и устройства отображается другой размер MTU, попробуйте выполнить следующее обходное решение:

1. Создайте новую сеть. Например,

   docker network create --opt com.docker.network.driver.mtu=1430 test-mtu

   В примере параметр MTU для устройства равен 1430. Поэтому MTU для сети Docker имеет значение 1430.

2. Остановите и удалите сеть Azure.

   docker network rm azure-iot-edge

3. Повторно создайте сеть Azure.

   docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge

4. Удалите все контейнеры и перезапустите службу aziot-edged .

   sudo iotedge system stop && sudo docker rm -f $(docker ps -aq -f "label=net.azure-devices.edge.owner=Microsoft.Azure.Devices.Edge.Agent") && sudo iotedge config apply

Агент IoT Edge не может получить доступ к образу модуля (403)

Симптомы

Не удается запустить контейнер, и журналы edgeAgent сообщают об ошибке 403.

Причина

Модуль агента IoT Edge не имеет разрешений на доступ к образу модуля.

Решение

Убедитесь, что учетные данные реестра контейнеров исправляют манифест развертывания устройства.

Агент IoT Edge делает чрезмерные вызовы удостоверений

Симптомы

Агент IoT Edge делает чрезмерные вызовы удостоверений для Центр Интернета вещей Azure.

Причина

Неправильное настройка манифеста развертывания устройств приводит к неудачной развертыванию на устройстве. Логика повторных попыток агента IoT Edge продолжает повторное развертывание. Каждая повторная попытка выполняет вызовы удостоверений до тех пор, пока развертывание не будет выполнено успешно. Например, если манифест развертывания задает универсальный код ресурса (URI) модуля, который не существует в реестре контейнеров или нетипичен, агент IoT Edge повторяет развертывание, пока манифест развертывания не будет исправлен.

Решение

Проверьте манифест развертывания в портал Azure. Исправьте все ошибки и повторно разверните манифест на устройстве.

Не удается запустить центр IoT Edge

Симптомы

Не удается запустить модуль edgeHub. В журналах может появиться сообщение об ошибке, подобное одному из следующих:

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

Or

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:
        The process cannot access the file because it is being used by another process. (0x20)

Причина

Порт, привязку которого пытается выполнить модуль edgeHub, уже привязан к другому процессу на хост-компьютере. Центр IoT Edge сопоставляет порты 443, 5671 и 8883 для использования с шлюзами в различных сценариях. Если один из этих портов уже привязан к какому-то другому процессу, модуль не запускается.

Решение

Вы можете устранить эту проблему двумя способами.

Если устройство IoT Edge работает как шлюз, необходимо найти и остановить процесс, использующий порт 443, 5671 или 8883. Номера порта 443 в сообщении об ошибке обычно означает, что другой процесс является веб-сервером.

Если не требуется использовать устройство IoT Edge в качестве шлюза, можно удалить привязки портов из параметров создания модуля edgeHub. Изменить эти параметры можно на портале Azure или непосредственно в файле deployment.json.

На портале Azure выполните следующие действия:

1. Перейдите в центр Интернета вещей и выберите "Устройства" в меню управления устройствами .

2. Выберите устройство IoT Edge, которое требуется обновить.

3. Щелкните Set Modules (Настроить модули).

4. Выберите Параметры среды выполнения.

5. В параметрах модуля Edge Hub удалите все элементы из текстового поля "Параметры создания контейнера".

6. Нажмите кнопку "Применить" , чтобы сохранить изменения и создать развертывание.

В файле deployment.json:

1. Откройте файл deployment.json, который вы применили к этому устройству IoT Edge.

2. Найдите параметры модуля edgeHub в разделе требуемых свойств модуля edgeAgent:

     "edgeHub": {
         "restartPolicy": "always",
         "settings": {
            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
         },
         "status": "running",
         "type": "docker"
      }
   

3. Удалите строку createOptions и добавьте запятую в конец предшествующей строки image:

     "edgeHub": {
         "restartPolicy": "always",
         "settings": {
         "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
         "status": "running",
         "type": "docker"
   }
   

4. Нажмите кнопку "Создать", чтобы применить его к устройству IoT Edge еще раз.

Модулю IoT Edge не удается отправить сообщение в адрес edgeHub, и возникает ошибка 404

Симптомы

Настраиваемому модулю IoT Edge не удается отправить сообщение в адрес edgeHub, в результате чего возникает ошибка 404 Module not found. Среда выполнения IoT Edge выводит следующее сообщение в журналы:

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

Причина

Среда выполнения IoT Edge применяет идентификацию процесса для всех модулей, подключающихся к edgeHub по соображениям безопасности. Таким образом проверяется, что все сообщения, которые отправляются модулем, поступают с идентификатора основного процесса модуля. Если сообщение отправляется модулем из другого идентификатора процесса, отличного от первоначально установленного, оно отклоняет сообщение с сообщением об ошибке 404.

Решение

Начиная с версии 1.0.7, подключение разрешено для всех процессов модуля. Дополнительные сведения см. в журнале изменений для версии 1.0.7.

Если обновление до версии 1.0.7 невозможно, выполните следующие действия. Убедитесь, что для отправки сообщений в edgeHub пользовательский модуль IoT Edge всегда использует один и тот же идентификатор процесса. Например, используйте в файле DOCKER команду ENTRYPOINT вместо CMD. Команда CMD создает один идентификатор процесса для модуля и еще один для команды оболочки bash, в которой выполняется основная программа, а команда ENTRYPOINT — всего один идентификатор процесса.

Нестабильная работа небольших устройств

Симптомы

Вы можете столкнуться с нестабильной работой некоторых устройств с ограниченными ресурсами, таких как Raspberry Pi, особенно если они используются в качестве шлюза. Для такой ситуации характерны исключения с сообщением о нехватке памяти в модуле центра IoT Edge, сбои подключения подчиненных устройств и прекращение потока телеметрии через несколько часов работы устройства.

Причина

Центр IoT Edge, входящий в состав среды выполнения IoT Edge, по умолчанию оптимизирован для высокой производительности и всегда пытается выделить большие блоки памяти. Эта оптимизация не идеально подходит для ограниченных пограничных устройств и может привести к проблемам стабильности.

Решение

Для переменной среды OptimizeForPerformance центра IoT Edge задайте значение false. Переменные среды можно задавать двумя способами.

На портале Azure выполните следующие действия:

1. В центре Интернета вещей выберите свое устройство IoT Edge и на странице сведений об устройстве выберите Настроить модули > Параметры времени выполнения.

2. Создайте переменную среды для модуля центра IoT Edge с именем OptimizeForPerformance с типом True/False, который имеет значение False.

3. Нажмите кнопку "Применить" , чтобы сохранить изменения, а затем нажмите кнопку "Проверить и создать".

   Переменная среды теперь находится в edgeHub свойстве манифеста развертывания:

      "edgeHub": {
         "env": {
               "OptimizeForPerformance": {
                  "value": false
               }
         },
         "restartPolicy": "always",
         "settings": {
               "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
               "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
         },
         "status": "running",
         "type": "docker"
      }
   

4. Нажмите кнопку "Создать", чтобы сохранить изменения и развернуть модуль.

Управляющая программа безопасности не могла успешно запуститься

Симптомы

Управляющая программа безопасности не запускается, а контейнеры модулей не создаются. edgeHub Пользовательские edgeAgentмодули не запускались службой IoT Edge. В aziot-edged журналах отображается эта ошибка:

• Управляющая программа не удалось запустить успешно: не удалось запустить службу управления.
• причина: ошибка для пути /var/run/iotedge/mgmt.sock
• вызвано: разрешение запрещено (ошибка ос 13)

Причина

Для всех дистрибутивов Linux, кроме CentOS 7, конфигурация IoT Edge по умолчанию предназначена для использования systemd активации сокета. Ошибка разрешения возникает, если вы измените файл конфигурации, чтобы не использовать активацию сокетов, но оставьте URL-адреса /var/run/iotedge/*.sockкак, так как пользователь не может записывать данные в /var/run/iotedge значение, что iotedge не может разблокировать и подключить сокеты.

Решение

Вам не нужно отключить активацию сокета в дистрибутиве, где поддерживается активация сокета. Однако если вы предпочитаете не использовать активацию сокетов вообще, поместите сокеты в /var/lib/iotedge/.

1. Запустите systemctl disable iotedge.socket iotedge.mgmt.socket , чтобы отключить единицы сокета, чтобы система не запускала их без необходимости.
2. Изменение конфигурации iotedge для использования /var/lib/iotedge/*.sock в обоих connect listen разделах
3. Если у вас уже есть модули, они имеют старые /var/run/iotedge/*.sock подключения, поэтому docker rm -f они.

Очистка очереди сообщений замедляется

Симптомы

Очередь сообщений не очищается после обработки сообщений. Очередь сообщений растет со временем и в конечном итоге приводит к нехватке памяти среды выполнения IoT Edge.

Причина

Интервал очистки сообщений управляется TTL (время жизни) и переменной среды EdgeHub MessageCleanupIntervalSecs . Значение TTL сообщения по умолчанию — два часа, а значение MessageCleanupIntervalSecs по умолчанию — 30 минут. Если приложение использует значение TTL, которое меньше значения по умолчанию, и вы не настраиваете значение MessageCleanupIntervalSecs , истекшие сообщения не будут очищаться до следующего интервала очистки.

Решение

Если изменить значение TTL для приложения, которое меньше значения по умолчанию, измените значение MessageCleanupIntervalSecs . Значение MessageCleanupIntervalSecs должно быть значительно меньше, чем наименьшее значение TTL, используемое клиентом. Например, если клиентское приложение определяет срок жизни в течение пяти минут в заголовке сообщения, задайте значение MessageCleanupIntervalSecs равным одной минуте. Эти параметры гарантируют очистку сообщений в течение шести (5 + 1) минут.

Чтобы настроить значение MessageCleanupIntervalSecs , задайте переменную среды в манифесте развертывания для модуля Центра IoT Edge. Дополнительные сведения о настройке переменных среды выполнения см. в разделе "Пограничный агент" и "Переменные среды Edge Hub".

Сеть

Сбой управляющей программы безопасности IoT Edge с недопустимым именем узла

Симптомы

Попытка проверить журналы диспетчера безопасности IoT Edge завершается сбоем, в результате чего выводится следующее сообщение:

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

Причина

Среда выполнения IoT Edge поддерживает только имена узлов, которые короче 64 символов. Физические компьютеры обычно не имеют длинных имен узлов. Эта ошибка более типична для виртуальных машин. Автоматически создаваемые имена узлов для виртуальных машин Windows, размещенных в Azure, часто бывают длинными.

Решение

Эту ошибку можно устранить, настроив DNS-имя виртуальной машины, а затем задав DNS-имя в качестве имени узла в команде установки.

1. На портале Azure перейдите к странице обзора виртуальной машины.

2. Откройте панель конфигурации, выбрав ссылку "Не настроено" (если виртуальная машина новая) или выберите существующее DNS-имя в разделе Essentials>DNS-имя. Если для виртуальной машины уже настроено DNS-имя, настраивать новое не нужно.

3. Укажите значение для метки DNS-имени, если у вас еще нет имени и нажмите кнопку "Сохранить".

4. Скопируйте новое DNS-имя, которое должно быть в формате:
   <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. Откройте файл конфигурации на устройстве IoT Edge.

   sudo nano /etc/aziot/config.toml
   

6. Замените значение hostname новым DNS-именем.

7. Сохраните и закройте файл, а затем примените изменения к IoT Edge.

   sudo iotedge config apply
   

Модуль IoT Edge сообщает об ошибках подключения

Симптомы

Модули IoT Edge, которые подключаются непосредственно к облачным службам, включая модули среды выполнения, перестают работать должным образом и возвращают ошибки при подключении или сбоях сети.

Причина

Контейнеры полагаются на пересылку IP-пакетов для подключения к Интернету, чтобы они могли взаимодействовать с облачными службами. Переадресация IP-пакетов включена по умолчанию в Docker, но если она отключена, все модули, подключающиеся к облачным службам, не будут работать должным образом. Дополнительные сведения см. в разделе "Общие сведения о взаимодействии с контейнерами" в документации по Docker.

Решение

Чтобы включить перенаправление IP-пакетов, выполните следующие действия.

1. Откройте файл sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Добавьте следующую строку в файл.

   net.ipv4.ip_forward=1
   

3. Сохранить и закрыть файл.

4. Перезапустите сетевую службу и службу Docker, чтобы применить изменения.

Службе IoT Edge, расположенной за шлюзом, не удается выполнить HTTP-запросы и запустить модуль edgeAgent

Симптомы

Среда выполнения IoT Edge активна с допустимым файлом конфигурации, но не может запустить модуль edgeAgent . Команда iotedge list возвращает пустой список. Отчеты Could not perform HTTP request среды выполнения IoT Edge в журналах.

Причина

Устройства IoT Edge, расположенные за шлюзом, получают свои образы модулей с родительского устройства IoT Edge, указанного в поле parent_hostname файла конфигурации. Ошибка Could not perform HTTP request означает, что нижнее устройство не может получить доступ к родительскому устройству через HTTP.

Решение

Убедитесь, что родительское устройство IoT Edge может получать входящие запросы от нижестоящего устройства IoT Edge. Откройте сетевой трафик на портах 443 и 6617 для запросов, поступающих от подчиненного устройства.

Службе IoT Edge, расположенной за шлюзом, не удается выполнить HTTP-запросы и запустить модуль edgeAgent

Симптомы

Управляющая программа IoT Edge активна с допустимым файлом конфигурации, но не может запустить модуль edgeAgent. Команда iotedge list возвращает пустой список. Журналы управляющей программы IoT Edge содержат сообщение об ошибке Could not perform HTTP request.

Причина

Устройства IoT Edge, расположенные за шлюзом, получают свои образы модулей с родительского устройства IoT Edge, указанного в поле parent_hostname файла конфигурации. Ошибка Could not perform HTTP request означает, что нижнее устройство не может получить доступ к родительскому устройству через HTTP.

Решение

Убедитесь, что родительское устройство IoT Edge может получать входящие запросы от нижестоящего устройства IoT Edge. Откройте сетевой трафик на портах 443 и 6617 для запросов, поступающих от подчиненного устройства.

IoT Edge за шлюзом не удается подключиться при миграции из одного центра Интернета вещей в другой

Симптомы

При попытке перенести иерархию устройств IoT Edge из одного центра Интернета вещей в другой, родительское устройство Верхнего уровня IoT Edge может подключаться к Центр Интернета вещей, но подчиненные устройства IoT Edge не могут. Отчет Unable to authenticate client downstream-device/$edgeAgent with module credentialsжурналов.

Причина

Учетные данные для подчиненных устройств не были обновлены должным образом при миграции в новый центр Интернета вещей. Из-за этого edgeAgent edgeHub для модулей задан тип none проверки подлинности (значение по умолчанию, если оно не задано явным образом). Во время подключения модули на подчиненных устройствах используют старые учетные данные, что приводит к сбою проверки подлинности.

Решение

При миграции в новый Центр Интернета вещей (при условии, что он не использует DPS), выполните следующие действия.

1. Следуйте инструкциям из этого руководства по экспорту и импорту удостоверений устройств из старого Центра Интернета вещей в новый.
2. Перенастройка всех развертываний и конфигураций IoT Edge в новом Центре Интернета вещей
3. Перенастройка всех связей устройств с родительским дочерним устройством в новом Центре Интернета вещей
4. Обновите каждое устройство, чтобы указать новое имя узла Центра Интернета вещей (iothub_hostnameв config.tomlразделе [provisioning] )
5. Если вы решили исключить ключи проверки подлинности во время экспорта устройства, перенастройку каждого устройства с новыми ключами, заданными новым центром Интернета вещей (device_id_pkв config.toml)[provisioning.authentication]
6. Сначала перезапустите родительское устройство верхнего уровня Edge, убедитесь, что оно запущено и запущено.
7. Перезапустите каждое устройство на уровне иерархии на уровне сверху вниз

IoT Edge имеет низкую пропускную способность сообщений, если географически далеко от Центр Интернета вещей

Симптомы

Устройства Azure IoT Edge, географически удаленные от Центр Интернета вещей Azure, имеют более низкую пропускную способность сообщения.

Причина

Высокая задержка между устройством и Центр Интернета вещей может привести к снижению пропускной способности сообщения. IoT Edge использует размер пакета сообщений по умолчанию 10. Это ограничивает количество сообщений, отправляемых в одном пакете, что увеличивает количество круговых путей между устройством и Центр Интернета вещей.

Решение

Попробуйте увеличить переменную среды MaxUpstreamBatchSize Центра IoT Edge. Это позволяет отправлять больше сообщений в одном пакете, что снижает количество циклов между устройством и Центр Интернета вещей.

Чтобы задать переменные среды Azure Edge Hub в портал Azure:

1. Перейдите к Центр Интернета вещей и выберите "Устройства" в меню управления устройствами.
2. Выберите устройство IoT Edge, которое требуется обновить.
3. Щелкните Set Modules (Настроить модули).
4. Выберите Параметры среды выполнения.
5. На вкладке параметров модуля Edge Hub добавьте переменную среды MaxUpstreamBatchSize в качестве типа Number со значением 20.
6. Выберите Применить.

Следующие шаги

Считаете, что обнаружили ошибку в платформе IoT Edge? Отправьте запрос, чтобы мы как можно скорее устранили неисправность.

Если у вас есть другие вопросы, создайте запрос в службу поддержки для получения справки.