Dela via

Kända problem: Azure IoT-åtgärder

  • Artikel

I den här artikeln visas kända problem för Azure IoT Operations.

Problem med att distribuera och avinstallera

  • Om du föredrar att inga uppdateringar görs i klustret utan uttryckligt medgivande bör du inaktivera Arc-uppdateringar när du aktiverar klustret. Detta beror på att vissa systemtillägg uppdateras automatiskt av Arc-agenten. Om du vill inaktivera uppdateringar inkluderar du --disable-auto-upgrade flaggan som en del av az connectedk8s connect kommandot.

  • Om distributionen "code":"LinkedAuthorizationFailed" misslyckas med felet innebär det att du inte har behörigheten Microsoft.Authorization/roleAssignments/write på resursgruppen som innehåller klustret.

  • Direktredigering av anpassade Resurser för SecretProviderClass och SecretSync i kubernetes-klustret kan bryta hemlighetsflödet i Azure IoT Operations. Använd användargränssnittet för driftupplevelse för alla åtgärder som rör hemligheter.

  • Under och efter distributionen av Azure IoT Operations kan du se varningar om Unable to retrieve some image pull secrets (regcred) i loggarna och Kubernetes-händelser. Dessa varningar förväntas och påverkar inte distributionen och användningen av Azure IoT-åtgärder.

  • Om distributionen misslyckas med meddelandet Error occurred while creating custom resources needed by system extensionshar du påträffat ett känt sporadiskt fel som kommer att åtgärdas i en framtida version. Som en lösning använder du kommandot az iot ops delete med --include-deps flaggan för att ta bort Azure IoT Operations från klustret. När Azure IoT Operations och dess beroenden tas bort från klustret försöker du distribuera igen.

  • Om du distribuerar Azure IoT Operations i GitHub Codespaces orsakar det ett This codespace is currently running in recovery mode due to a configuration error. problem att stänga av och starta om Codespace. För närvarande finns det ingen lösning på problemet. Om du behöver ett kluster som stöder avstängning och omstart väljer du något av alternativen i Förbereda ditt Azure Arc-aktiverade Kubernetes-kluster.

MQTT-asynkron meddelandekö

  • MQTT-koordinatorresurser som skapats i klustret med Kubernetes visas inte Azure Portal. Detta är förväntat eftersom hanteringen av Azure IoT Operations-komponenter med Kubernetes är i förhandsversion och synkronisering av resurser från gränsen till molnet inte stöds för närvarande.

  • Du kan inte uppdatera Broker-resursen efter den första distributionen. Du kan inte göra konfigurationsändringar i kardinalitet, minnesprofil eller diskbuffert.

    Som en lösning kan du när du distribuerar Azure IoT Operations med kommandot az iot ops init inkludera parametern --broker-config-file med en JSON-konfigurationsfil för MQTT-koordinatorn. Mer information finns i Advanced MQTT Broker config and Configure core MQTT broker settings (Avancerade MQTT-koordinatorkonfigurationer och Konfigurera grundläggande MQTT-koordinatorinställningar).

  • Om en broker bara har en serverdelsreplik (backendChain.redundancyFactor är inställd på 1) kan uppgradering av Azure IoT-åtgärder misslyckas. Uppgradera endast Azure IoT Operations om Broker har fler än en serverdelsreplik.

  • Även om MQTT-mäklarens diagnostik producerar telemetri i sitt eget ämne kan du fortfarande få meddelanden från självtestet när du prenumererar på # ämnet.

  • Distributionen kan misslyckas om kardinalitets- och minnesprofilvärdena är för stora för klustret. Lös problemet genom att ange antalet repliker till och använda en mindre minnesprofil, till 1 exempel low.

  • Publicera eller prenumerera inte på diagnostikavsökningsämnen som börjar med azedge/dmqtt/selftest. Publicering eller prenumeration på dessa ämnen kan påverka avsöknings- eller självtestkontrollerna, vilket resulterar i ogiltiga resultat. Ogiltiga resultat kan visas i diagnostikavsökningsloggar, mått eller instrumentpaneler. Du kan till exempel se problemet Sökvägsverifieringen misslyckades för avsökningshändelsen med åtgärdstypen "Publicera" i loggarna för diagnostikavsökning.

Azure IoT Layered Network Management (förhandsversion)

  • Om tjänsten Layered Network Management inte får någon IP-adress när K3S körs på Ubuntu-värden installerar du om K3S utan traefik-ingresskontrollant med hjälp --disable=traefik av alternativet .

    curl -sfL https://get.k3s.io | sh -s - --disable=traefik --write-kubeconfig-mode 644

    Mer information finns i Nätverk | K3s.

  • Om DNS-frågor inte matchar den förväntade IP-adressen när CoreDNS-tjänsten körs på underordnad nätverksnivå uppgraderar du till Ubuntu 22.04 och installerar om K3S.

Anslutningsprogram för OPC UA

  • Med tillgångsdefinitioner i Azure Device Registry kan du använda tal i attributavsnittet medan OPC-övervakaren endast förväntar sig strängar.

  • När du lägger till en ny tillgång med en ny tillgångsslutpunktsprofil i OPC UA-koordinatorn och utlöser en omkonfiguration, ändras distributionen opc.tcp av poddarna för att anpassa de nya hemliga monteringarna för användarnamn och lösenord. Om den nya monteringen av någon anledning misslyckas startar inte podden om och därför stoppas även det gamla flödet för korrekt konfigurerade tillgångar.

  • Ämnesnamnet och program-URI:n måste exakt matcha det angivna certifikatet. Eftersom det inte finns någon korsvalidering kan eventuella fel göra att OPC UA-servrarna avvisar programcertifikatet.

  • Om du anger ett nytt ogiltigt OPC UA-programinstanscertifikat efter en lyckad installation av AIO kan det leda till anslutningsfel. Lös problemet genom att ta bort dina Azure IoT Operations-instanser och starta om installationen.

OPC PLC-simulator

Om du skapar en tillgångsslutpunkt för OPC PLC-simulatorn, men OPC PLC-simulatorn inte skickar data till MQTT-koordinatorn, kör du följande kommando för att ange autoAcceptUntrustedServerCertificates=true för tillgångsslutpunkten:

ENDPOINT_NAME=<name-of-you-endpoint-here>
kubectl patch AssetEndpointProfile $ENDPOINT_NAME \
-n azure-iot-operations \
--type=merge \
-p '{"spec":{"additionalConfiguration":"{\"applicationName\":\"'"$ENDPOINT_NAME"'\",\"security\":{\"autoAcceptUntrustedServerCertificates\":true}}"}}'

Varning

Använd inte den här konfigurationen i produktions- eller förproduktionsmiljöer. Att exponera klustret för Internet utan korrekt autentisering kan leda till obehörig åtkomst och till och med DDOS-attacker.

Du kan korrigera alla dina tillgångsslutpunkter med följande kommando:

ENDPOINTS=$(kubectl get AssetEndpointProfile -n azure-iot-operations --no-headers -o custom-columns=":metadata.name")
for ENDPOINT_NAME in `echo "$ENDPOINTS"`; do \
kubectl patch AssetEndpointProfile $ENDPOINT_NAME \
   -n azure-iot-operations \
   --type=merge \
   -p '{"spec":{"additionalConfiguration":"{\"applicationName\":\"'"$ENDPOINT_NAME"'\",\"security\":{\"autoAcceptUntrustedServerCertificates\":true}}"}}'; \
done

Om OPC PLC-simulatorn inte skickar data till MQTT-koordinatorn när du har skapat en ny tillgång startar du om OPC PLC-simulatorpodden. Poddnamnet ser ut som aio-opc-opc.tcp-1-f95d76c54-w9v9c. Om du vill starta om podden använder du k9s verktyget för att avsluta podden eller kör följande kommando:

kubectl delete pod aio-opc-opc.tcp-1-f95d76c54-w9v9c -n azure-iot-operations

Dataflöden

  • Anpassade dataflödesresurser som skapats i klustret visas inte i användargränssnittet för driftupplevelse. Detta är förväntat eftersom hanteringen av Azure IoT Operations-komponenter med Kubernetes är i förhandsversion och synkronisering av resurser från gränsen till molnet inte stöds för närvarande.

  • X.509-autentisering för anpassade Kafka-slutpunkter stöds inte ännu.

  • Det går inte att deserialisera och verifiera meddelanden med hjälp av ett schema ännu. Om du anger ett schema i källkonfigurationen kan operations experience-portalen visa listan över datapunkter, men datapunkterna verifieras inte mot schemat.

  • Om du skapar en X.509-hemlighet i operations experience-portalen resulterar det i en hemlighet med felaktigt kodade data. Du kan undvika det här problemet genom att skapa flerradshemligheter via Azure Key Vault och sedan välja dem i listan över hemligheter i portalen för driftupplevelse.

  • När du ansluter flera IoT Operations-instanser till samma Event Grid MQTT-namnområde kan anslutningsfel uppstå på grund av klient-ID-konflikter. Klient-ID:t härleds för närvarande från dataflödesresursnamn, och när du använder IaC-mönster (Infrastruktur som kod) för distribution kan de genererade klient-ID:erna vara identiska. Som en tillfällig lösning lägger du till slumpmässighet i dataflödesnamnen i dina distributionsmallar.

  • När nätverksanslutningen avbryts kan dataflöden stöta på fel som skickar meddelanden på grund av ett felmatchat producent-ID. Om det här problemet uppstår startar du om dina Dataflöden-poddar.