일반적인 Azure IoT Edge 문제에 대한 해결 방법

아티클
04/11/2024

주의

이 문서에서는 EOL(수명 종료) 상태에 가까워진 Linux 배포판인 CentOS를 참조하세요. 이에 따라 사용 및 계획을 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조 하세요.

적용 대상: IoT Edge 1.4

Important

IoT Edge 1.4는 지원되는 릴리스입니다. 이전 릴리스에 있는 경우 IoT Edge 업데이트를 참조하세요.

이 문서를 사용하여 IoT Edge 솔루션을 사용할 때 발생하는 일반적인 문제를 식별하고 확인합니다. IoT Edge 서비스에서 로그 및 오류를 발견하는 방법에 대한 자세한 내용은 IoT Edge 디바이스 문제 해결을 참조하세요.

프로비전 및 배포

IoT Edge 모듈이 성공적으로 배포된 후 디바이스에서 사라짐

증상

IoT Edge 서비스에 대해 모듈을 설정한 후 모듈이 성공적으로 배포되지만 몇 분 후 디바이스 및 Azure Portal의 디바이스 세부 정보에서 사라집니다. 정의된 것 이외의 다른 모듈이 디바이스에 표시될 수도 있습니다.

원인

자동 배포가 대상 디바이스를 선택하는 경우 단일 디바이스에 대해 모듈을 수동으로 설정하는 것보다 우선 적용됩니다. Azure Portal의 모듈 설정 기능 또는 Visual Studio Code의 단일 디바이스에 대한 배포 만들기 기능이 잠시 동안 적용됩니다. 정의한 모듈이 디바이스에서 시작되는 것을 확인할 수 있습니다. 그런 후 자동 배포가 우선 시작되면서 디바이스의 원하는 속성을 덮어씁니다.

솔루션

자동 배포 또는 개별 디바이스 배포 중에서 배포 메커니즘을 디바이스당 한 가지 유형만 사용해야 합니다. 한 디바이스를 대상으로 하는 자동 배포가 여럿인 경우 올바른 항목이 지정된 디바이스에 적용되도록 우선 순위 또는 대상 설명을 변경할 수 있습니다. 또한 자동 배포의 대상 설명과 더 이상 일치하지 않도록 디바이스 트윈을 업데이트할 수 있습니다.

자세한 내용은 단일 디바이스 또는 대규모 IoT Edge 자동 배포에 대한 이해를 참조하세요.

IoT Edge 런타임

IoT Edge 에이전트가 1분 후에 중지됨

증상

edgeAgent 모듈이 시작되고 1분 정도 성공적으로 실행되고 나서 중지됩니다. 로그에는 IoT Edge 에이전트가 AMQP를 통해 IoT 허브에 연결하려고 시도한 후 WebSocket을 통해 AMQP를 사용하여 연결하려고 시도한다고 표시됩니다. 이것이 실패했을 때 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)를 통해 먼저 연결을 시도합니다. 이 연결이 실패하면 WebSockets(포트 443)을 시도합니다.

IoT Edge 런타임은 각 모듈이 통신할 네트워크를 설정합니다. Linux에서 이 네트워크는 브리지 네트워크입니다. Windows에서는 NAT를 사용합니다. 이 문제는 NAT 네트워크를 사용하는 Windows 컨테이너를 사용하는 Windows 디바이스에서 좀 더 자주 발생합니다.

솔루션

이 브리지/NAT 네트워크에 할당된 IP 주소가 인터넷에 연결되는 경로가 있는지 확인합니다. 경우에 따라 호스트의 VPN 구성은 IoT Edge 네트워크를 재정의합니다.

Edge 에이전트 모듈이 ‘빈 구성 파일’을 보고하고 모듈이 디바이스에서 시작되지 않음

증상

디바이스가 배포에 정의된 모듈을 시작하는 데 문제가 있습니다. edgeAgent만 실행 중이지만 빈 구성 파일...을 보고합니다.
디바이스에서 sudo iotedge check을 실행하는 경우 컨테이너 엔진이 DNS 서버 설정으로 구성되지 않아 IoT Hub에 대한 연결에 영향을 미칠 수 있다고 보고합니다. 모범 사례는 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: 모듈별로 IoT Edge 배포에서 DNS 서버 설정

IoT Edge 배포에서 각 모듈의 createOptions에 대해 DNS 서버를 설정할 수 있습니다. 예시:

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

Warning

이 방법을 사용하고 잘못된 DNS 주소를 지정하면 edgeAgent에서 IoT Hub와의 연결이 끊어지고 문제를 해결하기 위해 새 배포를 받을 수 없습니다. 이 문제를 해결하기 위해 IoT Edge 런타임을 다시 설치할 수 있습니다. IoT Edge의 새 인스턴스를 설치하기 전에 이전 설치에서 모든 edgeAgent 컨테이너를 제거해야 합니다.

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 경고 메시지를 표시하지 않을 수 있습니다.

LTE가 연결된 에지 에이전트 모듈은 ‘빈 에지 에이전트 구성’을 보고하고 ‘일시적인 네트워크 오류’가 발생합니다.

증상

LTE 연결로 구성된 디바이스에 배포 시 정의된 모듈을 시작하는 데 문제가 있습니다. edgeAgent는 IoT Hub에 연결할 수 없으며 빈 에지 에이전트 구성 및 일시적인 네트워크 오류가 발생했다고 보고합니다.

원인

일부 네트워크에는 패킷 오버헤드가 있으므로 기본 Docker 네트워크 MTU(1500)가 너무 높고 패킷 조각화로 인해 외부 리소스에 대한 액세스가 차단됩니다.

솔루션

Docker 네트워크에 대한 MTU 설정을 확인합니다.

docker network inspect <network name>
디바이스의 물리적 네트워크 어댑터에 대한 MTU 설정을 확인합니다.

ip addr show eth0

참고 항목

Docker 네트워크의 MTU는 디바이스의 MTU보다 클 수 없습니다. 자세한 내용은 ISP에 문의하세요.

Docker 네트워크 및 디바이스에 대해 다른 MTU 크기가 표시되는 경우 다음 해결 방법을 시도해 보세요.

새 네트워크를 만듭니다. 예를 들면 다음과 같습니다.

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

예제에서 디바이스의 MTU 설정은 1430입니다. 따라서 Docker 네트워크의 MTU는 1430으로 설정됩니다.
Azure 네트워크를 중지하고 제거합니다.

docker network rm azure-iot-edge
Azure 네트워크를 다시 만듭니다.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
모든 컨테이너를 제거하고 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 에이전트가 과도한 ID 호출을 합니다.

증상

IoT Edge 에이전트는 Azure IoT Hub에 과도한 ID 호출을 합니다.

원인

디바이스 배포 매니페스트가 잘못 구성되면 디바이스에서 배포에 실패합니다. IoT Edge 에이전트 재시도 논리는 배포를 계속 다시 시도합니다. 각 재시도는 배포가 성공할 때까지 ID 호출을 수행합니다. 예를 들어 배포 매니페스트가 컨테이너 레지스트리에 없거나 잘못 입력된 모듈 URI를 지정하는 경우 IoT Edge 에이전트는 배포 매니페스트가 수정될 때까지 배포를 다시 시도합니다.

솔루션

Azure Portal에서 배포 매니페스트를 확인합니다. 오류를 수정하고 매니페스트를 디바이스에 다시 배포합니다.

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)

또는

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 Portal에서 또는 deployment.json 파일에서 만들기 옵션을 변경할 수 있습니다.

Azure Portal에서 다음을 수행합니다.

IoT Hub로 이동하여 디바이스 관리 메뉴에서 디바이스를 선택합니다.
업데이트하려는 IoT Edge 디바이스를 선택합니다.
모듈 설정을 선택합니다.
런타임 설정을 선택합니다.
Edge 허브 모듈 설정에서 컨테이너 만들기 옵션 텍스트 상자에 있는 모든 항목을 삭제합니다.
적용을 선택하여 변경 내용을 저장하고 배포를 만듭니다.

deployment.json 파일에서 다음을 수행합니다.

IoT Edge 디바이스에 적용한 deployment.json 파일을 엽니다.

edgeAgent의 원하는 속성 섹션에서 edgeHub 설정을 찾습니다.

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

createOptions 줄을 제거하고 그 앞의 image 줄의 끝에 있는 후행 쉼표를 제거합니다.

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

만들기를 선택하여 IoT Edge 디바이스에 다시 적용합니다.

404 오류로 IoT Edge 모듈이 edgeHub에 메시지를 보내지 못함

증상

사용자 지정 IoT Edge 모듈이 404 Module not found 오류로 인해 IoT Edge 허브에 메시지를 보내지 못합니다. 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에 연결하는 모든 모듈에 대해 프로세스 확인을 적용합니다. 이 디먼은 모듈이 전송하는 모든 메시지가 해당 모듈의 기본 프로세스 ID에서 온 것인지 확인합니다. 처음에 설정한 것과 다른 프로세스 ID의 모듈에서 메시지를 보내는 경우 404 오류 메시지와 함께 메시지를 거부합니다.

솔루션

1.0.7 버전부터는 모든 모듈 프로세스에 연결 권한이 부여됩니다. 자세한 내용은 1.0.7 릴리스 변경 로그를 참조하세요.

1.0.7로 업그레이드할 수 없으면 다음 단계를 완료합니다. 사용자 지정 IoT Edge 모듈이 edgeHub에 메시지를 보내는 데 항상 동일한 프로세스 ID를 사용하는지 확인합니다. 예를 들어 Docker 파일에서 CMD 명령 대신 ENTRYPOINT 명령을 사용합니다. CMD 명령은 모듈에 대한 프로세스 ID 하나와 기본 프로그램에서 실행되는 bash 명령에 대한 또 다른 프로세스 ID로 이어지지만 ENTRYPOINT 명령은 단일 프로세스 ID로 이어집니다.

작은 디바이스에서의 안정성 문제

증상

특히 게이트웨이로 사용될 때 Raspberry Pi와 같은 리소스가 제한된 디바이스에서 안정성 문제가 발생할 수 있습니다. 증상에는 IoT Edge 허브 모듈의 메모리 부족 예외, 다운스트림 디바이스의 연결 실패 또는 몇 시간 후 디바이스의 원격 분석 메시지 전송 실패가 포함됩니다.

원인

IoT Edge 런타임에 속하는 IoT Edge 허브는 기본적으로 성능에 최적화되어 있으며 많은 양의 메모리를 할당하려고 합니다. 이 최적화는 제한된 에지 디바이스에 대해 이상적이지 않으며 안정성 문제를 유발할 수 있습니다.

솔루션

IoT Edge 허브의 경우 OptimizeForPerformance 환경 변수를 false로 설정합니다. 환경 변수를 설정하는 방법은 두 가지입니다.

Azure Portal에서 다음을 수행합니다.

IoT 허브에서 IoT Edge 디바이스를 선택하고 디바이스 세부 정보 페이지에서 모듈 선택>런타임 설정을 선택합니다.
True/False 형식이 False로 설정된 OptimizeForPerformance라는 IoT Edge 허브 모듈에 대해 환경 변수를 만듭니다.

적용을 선택하여 변경 내용을 저장한 다음, 검토 + 만들기를 선택합니다.

환경 변수는 이제 배포 매니페스트의 edgeHub 속성에 있습니다.

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

만들기를 선택하여 변경 내용을 저장하고 모듈을 배포합니다.

보안 디먼을 성공적으로 시작할 수 없습니다.

증상

보안 디먼이 시작되지 않고 모듈 컨테이너가 만들어지지 않습니다. edgeAgent, edgeHub 및 기타 사용자 지정 모듈은 IoT Edge 서비스에서 시작되지 않습니다. aziot-edged 로그에 다음 오류가 표시됩니다.

디먼을 성공적으로 시작할 수 없습니다. 관리 서비스를 시작할 수 없습니다.

원인: /var/run/iotedge/mgmt.sock 경로에 오류가 발생했습니다.

원인: 권한 거부됨(os 오류 13)

원인

CentOS 7을 제외한 모든 Linux 배포판의 경우 IoT Edge의 기본 구성은 systemd 소켓 활성화를 사용하는 것입니다. 소켓 활성화를 사용하지 않도록 구성 파일을 변경하고 URL을 /var/run/iotedge/*.sock로 남겨두면 iotedge 사용자가 /var/run/iotedge에 쓸 수 없으므로 소켓 자체를 잠금 해제하고 탑재할 수 없기 때문에 권한 오류가 발생합니다.

솔루션

소켓 활성화가 지원되는 배포판에서는 소켓 활성화를 사용하지 않도록 설정할 필요가 없습니다. 그러나 소켓 활성화를 전혀 사용하지 않으려면 소켓을 /var/lib/iotedge/에 두세요.

systemctl disable iotedge.socket iotedge.mgmt.socket을 실행하여 소켓 장치를 사용하지 않도록 설정하여 systemd가 소켓 장치를 불필요하게 시작하지 않도록 합니다.
connect 및 listen 섹션 모두에서 /var/lib/iotedge/*.sock를 사용하도록 iotedge 구성을 변경합니다.
모듈이 이미 있는 경우 이전 /var/run/iotedge/*.sock 탑재가 있으므로 docker rm -f합니다.

네트워킹

IoT Edge 보안 디먼이 유효하지 않은 호스트 이름으로 실패합니다.

증상

IoT Edge 보안 관리자 로그를 확인하려는 시도가 실패하고 다음 메시지가 출력됩니다.

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

원인

IoT Edge 런타임은 64자 미만인 호스트 이름만을 지원할 수 있습니다. 물리적 머신은 일반적으로 긴 호스트 이름을 사용하지 않지만 문제는 가상 머신에서 자주 발생합니다. 특히 Azure에서 호스팅되는 Windows 가상 머신에 자동으로 생성된 호스트 이름이 너무 긴 경향이 있습니다.

솔루션

이 오류를 표시하는 경우 가상 머신의 DNS 이름을 구성한 다음, 설정 명령에서 DNS 이름을 호스트 이름으로 설정하여 해결할 수 있습니다.

Azure Portal에서 가상 머신의 개요 페이지로 이동합니다.
DNS 이름 아래에서 구성되지 않음(새 가상 머신의 경우)을 선택하여 구성 패널을 열거나 기존 DNS 이름을 선택합니다. 가상 머신에 DNS 이름이 이미 구성되어 있으면 새 이름을 구성할 필요가 없습니다.
DNS 이름 레이블이 아직 없는 경우 값을 제공하고 저장을 선택합니다.
새 DNS 이름을 복사합니다. 이름 형식은 다음과 같습니다.
<DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
IoT Edge 디바이스에서 구성 파일을 엽니다.
```
sudo nano /etc/aziot/config.toml
```
hostname의 값을 DNS 이름으로 바꿉니다.
파일을 저장하고 닫은 후 변경 사항을 IoT Edge에 적용합니다.
```
sudo iotedge config apply
```

IoT Edge 모듈에서 연결 오류 보고

증상

런타임 모듈을 포함하여 클라우드 서비스에 직접 연결하는 IoT Edge 모듈은 예상대로 작동을 중지하고 연결 또는 네트워킹 실패에 대한 오류를 반환합니다.

원인

컨테이너는 클라우드 서비스와 통신할 수 있도록 인터넷에 연결하기 위해 IP 패킷 전달에 의존합니다. IP 패킷 전달은 Docker에서 기본적으로 사용하도록 설정되지만 사용하지 않도록 설정되면 클라우드 서비스에 연결하는 모든 모듈이 예상대로 작동하지 않습니다. 자세한 내용은 Docker 설명서의 컨테이너 통신 이해를 참조하세요.

솔루션

다음 단계에서 IP 패킷 전달을 사용하도록 설정합니다.

sysctl.conf 파일을 엽니다.
```
sudo nano /etc/sysctl.conf
```
파일에 다음 줄을 추가합니다.
```
net.ipv4.ip_forward=1
```
파일을 저장 후 닫습니다.
변경 내용을 적용하려면 네트워크 서비스와 Docker 서비스를 다시 시작합니다.

게이트웨이 뒤의 IoT Edge가 HTTP 요청을 수행하고 edgeAgent 모듈을 시작할 수 없음

증상

IoT Edge 런타임이 유효한 구성 파일로 활성 상태이지만 edgeAgent 모듈을 시작할 수 없습니다. iotedge list 명령이 빈 목록을 반환합니다. IoT Edge 런타임은 로그에 Could not perform HTTP request를 보고합니다.

원인

게이트웨이 뒤의 IoT Edge 디바이스가 구성 파일의 parent_hostname 필드에 지정된 부모 IoT Edge 디바이스에서 모듈 이미지를 가져옵니다. 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 Hub에서 다른 IoT Hub로 마이그레이션할 때 게이트웨이 뒤에 있는 IoT Edge를 연결할 수 없음

증상

한 IoT Hub에서 다른 IoT Hub로 IoT Edge 디바이스의 계층 구조를 마이그레이션하려고 하면 최상위 부모 IoT Edge 디바이스는 IoT Hub에 연결할 수 있지만 다운스트림 IoT Edge 디바이스는 연결할 수 없습니다. 로그 보고서 Unable to authenticate client downstream-device/$edgeAgent with module credentials.

원인

새 IoT Hub로 마이그레이션할 때 다운스트림 디바이스에 대한 자격 증명이 제대로 업데이트되지 않았습니다. 이 때문에 edgeAgent 및 edgeHub 모듈은 인증 유형 none(명시적으로 설정되지 않은 경우 기본값)으로 설정되었습니다. 연결하는 동안 다운스트림 디바이스의 모듈은 이전 자격 증명을 사용하여 인증에 실패합니다.

솔루션

새 IoT Hub로 마이그레이션할 때(DPS를 사용하지 않는다고 가정) 다음 단계를 순서대로 따릅니다.

이 가이드에 따라 디바이스 ID를 내보낸 다음 이전 IoT Hub에서 새 디바이스로 가져오기합니다.
새 IoT Hub에서 모든 IoT Edge 배포 및 구성 다시 구성
새 IoT Hub에서 모든 부모-자식 디바이스 관계 다시 구성
새 IoT Hub 호스트 이름(config.toml의 [provisioning] 아래 iothub_hostname)을 가리키도록 각 디바이스를 업데이트합니다.
디바이스를 내보내는 동안 인증 키를 제외하도록 선택한 경우 새 IoT Hub에서 제공한 새 키(config.toml의 [provisioning.authentication] 아래 device_id_pk)로 각 디바이스를 다시 구성합니다.
최상위 부모 Edge 디바이스를 먼저 다시 시작하고 실행 중인지 확인합니다.
계층 구조 수준의 각 디바이스를 위에서 아래로 다시 시작합니다.

IoT Edge는 IoT Hub에서 지리적으로 멀리 떨어져 있는 경우 메시지 처리량이 낮습니다.

증상

Azure IoT Hub에서 지리적으로 멀리 떨어져 있는 Azure IoT Edge 디바이스의 메시지 처리량은 예상보다 낮습니다.

원인

디바이스와 IoT Hub 간의 대기 시간이 높으면 예상보다 낮은 메시지 처리량이 발생할 수 있습니다. IoT Edge는 기본 메시지 일괄 처리 크기인 10을 사용합니다. 그러면 단일 일괄 처리로 전송되는 메시지 수가 제한되어 디바이스와 IoT Hub 간의 왕복 수가 증가합니다.

솔루션

IoT Edge Hub MaxUpstreamBatchSize 환경 변수를 늘려 보세요. 그러면 더 많은 메시지를 단일 일괄 처리로 보낼 수 있으므로 디바이스와 IoT Hub 간의 왕복 수가 줄어듭니다.

Azure Portal에서 Azure Edge Hub 환경 변수를 설정하려면 다음을 수행합니다.

IoT Hub로 이동하여 디바이스 관리 메뉴에서 디바이스를 선택합니다.
업데이트하려는 IoT Edge 디바이스를 선택합니다.
모듈 설정을 선택합니다.
런타임 설정을 선택합니다.
Edge Hub 모듈 설정 탭에서 MaxUpstreamBatchSize 환경 변수를 값이 20인 숫자 형식으로 추가합니다.
적용을 선택합니다.

다음 단계

IoT Edge 플랫폼에서 버그를 찾았나요? 지속적인 제품 개선을 위해 문제를 제출하세요.

추가 질문이 있으면 지원 요청을 만들어 도움을 받으세요.

일반적인 Azure IoT Edge 문제에 대한 해결 방법

프로비전 및 배포

IoT Edge 모듈이 성공적으로 배포된 후 디바이스에서 사라짐

증상

원인

솔루션

IoT Edge 런타임

IoT Edge 에이전트가 1분 후에 중지됨

증상

원인

솔루션

Edge 에이전트 모듈이 ‘빈 구성 파일’을 보고하고 모듈이 디바이스에서 시작되지 않음

증상

원인

솔루션

LTE가 연결된 에지 에이전트 모듈은 ‘빈 에지 에이전트 구성’을 보고하고 ‘일시적인 네트워크 오류’가 발생합니다.

증상

원인

솔루션

IoT Edge 에이전트가 모듈의 이미지에 액세스할 수 없음(403)

증상

원인

솔루션

IoT Edge 에이전트가 과도한 ID 호출을 합니다.

증상

원인

솔루션

IoT Edge 허브 시작 실패

증상

원인

솔루션

404 오류로 IoT Edge 모듈이 edgeHub에 메시지를 보내지 못함

증상

원인

솔루션

작은 디바이스에서의 안정성 문제

증상

원인

솔루션

보안 디먼을 성공적으로 시작할 수 없습니다.

증상

원인

솔루션

네트워킹

IoT Edge 보안 디먼이 유효하지 않은 호스트 이름으로 실패합니다.

증상

원인

솔루션

IoT Edge 모듈에서 연결 오류 보고

증상

원인

솔루션

게이트웨이 뒤의 IoT Edge가 HTTP 요청을 수행하고 edgeAgent 모듈을 시작할 수 없음

증상

원인

솔루션

게이트웨이 뒤의 IoT Edge가 HTTP 요청을 수행하고 edgeAgent 모듈을 시작할 수 없음

증상

원인

솔루션

한 IoT Hub에서 다른 IoT Hub로 마이그레이션할 때 게이트웨이 뒤에 있는 IoT Edge를 연결할 수 없음

증상

원인

솔루션

IoT Edge는 IoT Hub에서 지리적으로 멀리 떨어져 있는 경우 메시지 처리량이 낮습니다.

증상

원인

솔루션

다음 단계

추가 리소스