Znane problemy dotyczące Operacje Azure IoT

W tym artykule wymieniono bieżące znane problemy, które mogą wystąpić podczas korzystania z Operacje Azure IoT. Wskazówki ułatwiają identyfikowanie tych problemów i zapewnia obejścia tam, gdzie są dostępne.

Aby uzyskać ogólne wskazówki dotyczące rozwiązywania problemów, zobacz Troubleshoot Operacje Azure IoT.

Problemy z brokerem MQTT

W tej sekcji wymieniono bieżące znane problemy dotyczące brokera MQTT.

Zasoby brokera MQTT nie są widoczne w portalu Azure

Identyfikator problemu: 4257

Podpis dziennika: nie dotyczy

Zasoby brokera MQTT utworzone w klastrze przy użyciu platformy Kubernetes nie są widoczne w portalu Azure. Ten wynik jest oczekiwany, ponieważ zarządzanie składnikami Operacje Azure IoT przy użyciu platformy Kubernetes służy tylko do debugowania i testowania, a synchronizowanie zasobów z krawędzi do chmury nie jest obecnie obsługiwane.

Obecnie nie ma obejścia tego problemu.

Ogólne problemy z łącznikiem

W tej sekcji wymieniono bieżące znane problemy, które mają wpływ na wszystkie łączniki.

Nazwy przychodzących punktów końcowych zapisane wielkimi literami uniemożliwiają synchronizację stanu urządzeń

Identyfikator problemu: 0202

Dotyczy: Operacje Azure IoT 2610 public preview, zgłoszone w wersji v1.6.0-preview.57 z łącznikiem dla ONVIF.

Poprawka planowana na wydanie 2612.

Sygnatura dziennika: W portalu Azure Dziennik aktywności, Microsoft.DeviceRegistry/namespaces/devices/write kończy się niepowodzeniem z błędem InvalidRequestContent:

The request body contains a duplicate JSON key '<endpoint name in lowercase>'. Each property name may appear at most once.

Możesz utworzyć urządzenie z nazwą punktu końcowego ruchu przychodzącego, która zawiera wielkie litery, ale kolejne zapisy statusu urządzenia nie przechodzą. Stan konfiguracji używa nazwy punktu końcowego zapisanej małymi literami, podczas gdy stan środowiska uruchomieniowego zachowuje oryginalną wielkość liter. Azure odrzuca powstałe duplikaty kluczy.

Widok operacyjny może raportować, że urządzenie zostało stworzone i zsynchronizowane, podczas gdy jego stan pozostaje nieznany. Rzeczywisty stan punktu końcowego i błędy łączności nie są widoczne w Azure.

Obejście: używaj małych liter, cyfr i myślników w nazwach punktów końcowych ruchu przychodzącego. W przypadku istniejącego urządzenia, którego dotyczy problem, zapisz jego konfigurację, zidentyfikuj zależne zasoby i obciążenia oraz zaplanuj przerwę przed usunięciem i ponownym utworzeniem urządzenia z nazwą punktu końcowego zapisaną małymi literami. Sprawdź, czy zapisy statusu są pomyślne, a stan zdrowia jest raportowany po rekreacji.

Łącznik nie wykrywa aktualizacji poświadczeń urządzenia w Azure Key Vault

Identyfikator problemu: 6514

N/A

Naprawiono w wersji 2605 lub nowszej

Łącznik nie otrzymuje powiadomienia, gdy poświadczenia urządzenia przechowywane w Azure Key Vault są aktualizowane. W związku z tym łącznik nadal używa starych poświadczeń do momentu ponownego uruchomienia.

Obejście: Uruchom ponownie łącznik, aby wymusić pobranie zaktualizowanych poświadczeń z Azure Key Vault.

Łącznik do rozwiązywania problemów z OPC UA

W tej sekcji wymieniono bieżące znane problemy dotyczące łącznika OPC UA.

Nie można używać znaków specjalnych w nazwach zdarzeń

Identyfikator problemu: 1532

Naprawiono w wersji 1.3.36 (2603) i nowszej

Podpis logu: 2025-10-22T14:51:59.338Z aio-opc-opc.tcp-1-68ff6d4c59-nj2s4 - Updated schema information for Boiler#1Notifier skipped!

Generowanie schematu kończy się niepowodzeniem, jeśli nazwy zdarzeń zawierają znaki specjalne, takie jak #, %lub &. Unikaj używania tych znaków w nazwach zdarzeń, aby zapobiec problemom z generowaniem schematu.

Brak szablonu złącza OPC

ID wydania: 1330

Poprawione w wersji 1.4.73 (2608) i późniejszych

Podpis dziennika: nie dotyczy

Wdrożenie instancji Operacje Azure IoT powinno domyślnie zainstalować szablon OPC ConnectorTemplate. Po wdrożeniu szablon łącznika jest niedostępny w witrynie Azure Portal, a zasób ConnectorTemplate nie jest obecny w klastrze.

Łącznik multimediów i łącznik dla ONVIF

W tej sekcji wymieniono bieżące znane problemy dotyczące łącznika multimediów i łącznika onVIF.

ContinuousMove zgłasza powodzenie, mimo że kamera się nie porusza

ID problemu: 0205

Dotyczy: środowiska operacji przedprodukcyjnych używanego z publiczną wersją zapoznawczą Operacje Azure IoT. Wpływ w środowisku operacji produkcyjnych nie został potwierdzony.

Poprawka planowana na wydanie 2612.

Sygnatura logu: Akcja PTZ>ContinuousMove zwraca Succeeded z pustym wynikiem:

{"Result": {}}

Formularz wykonania wymaga Zoom>X, mimo że Velocity.Zoom jest opcjonalny w schemacie żądania akcji. W przypadku kamery pan-tilt dotkniętej problemem, bez zoomu optycznego, przesłanie formularza zgłasza sukces, ale kamera się nie porusza.

Obejście: Wywołaj działanie zasobu PTZ>ContinuousMove przez Azure Resource Manager executeAction z ładunkiem, który zawieraPanTilt, ale pomija .Zoom Na przykład użyj poniższej treści żądania, zastępując Media>GetProfiles tokenem zwróconym przez działanie kamery:

{
  "managementGroupName": "PTZ",
  "managementActionName": "ContinuousMove",
  "payload": {
    "ContinuousMove": {
      "ProfileToken": "<media-profile-token>",
      "Velocity": {
        "PanTilt": {
          "x": 0.3,
          "y": 0
        }
      },
      "Timeout": "PT1S"
    }
  }
}

Wyślij payload jako obiekt JSON, a nie jako ciąg znaków zakodowany przez JSON. Użyj wartości ruchu wspieranych przez kamerę i weryfikuj wynik za pomocą PTZ>GetStatus; sam pusty, udany wynik nie potwierdza ruchu.

Odkrywanie mediów przekracza limit punktu końcowego odkrytego urządzenia

Identyfikator problemu: 5382

Dotyczy: Operacje Azure IoT 2610 public preview, zgłoszony w wersji v1.6.0-preview.57 z łącznikiem dla ONVIF v1.6.5.

Poprawka planowana na wydanie 2612.

Sygnatura logu: W dzienniku aktywności Activity Log portalu Azure Microsoft.DeviceRegistry/namespaces/discoveredDevices/write kończy się niepowodzeniem z InvalidRequestContent, z MaxProperties skierowanym na properties.endpoints.inbound:

The object must not contain more than 10 properties.

Złącze dla ONVIF generuje punkty końcowe mediów dla wielu transportów na profil mediów. Azure Device Registry odrzuca odkryte urządzenia przekraczające 10 punktów końcowych przychodzących. Kamera z trzema profilami multimedialnymi może przekroczyć ten limit.

Punkt końcowy ONVIF kamery może zgłaszać Dostępność, a jego odkryty zasób ONVIF może się pojawić, ale urządzenie z odkrytymi punktami multimedialnymi nie pojawia się w Azure. Nie możesz zaimportować tych punktów końcowych, aby skonfigurować złącze multimedialne przez odkrywanie.

Obejście: Ręcznie utwórz urządzenie z przychodzącym punktem końcowym Microsoft.Media, używając adresu URL strumienia RTSP kamery z dokumentacji producenta, na przykład rtsp://<camera-ip>:554/<stream-path>. Skonfiguruj dane uwierzytelniające za pomocą obsługiwanych odwołań do sekretów, a następnie utwórz zasób multimedialny oraz potrzebne strumienie migawek lub klipów. Zobacz Konfiguruj łącznik dla multimediów.

Konflikt tajnej synchronizacji

Identyfikator problemu: 0606

Podpis dziennika: nie dotyczy

Podczas korzystania z synchronizacji wpisów tajnych upewnij się, że nazwy wpisów tajnych są globalnie unikatowe. Jeśli istnieje lokalny wpis tajny o tej samej nazwie, łączniki mogą nie pobrać zamierzonego wpisu tajnego.

Problemy z konektorem MQTT

Niezgodność wersji szablonu łącznika MQTT podczas aktualizacji

Identyfikator problemu: 1533

Podpis dziennika: nie dotyczy

Naprawiono w wersji 2606 i późniejszych

Podczas aktualizowania do wersji 2605 istniejące szablony łączników MQTT mogą wyświetlać niezgodne wersje metadanych w portalu. Aby rozwiązać ten problem, usuń i ponownie utwórz szablon łącznika. Alternatywnie użyj Azure CLI, aby zaktualizować łącznik.

Łącznik MQTT nie może nawiązać połączenia z zewnętrznymi brokerami MQTT, które mają prywatne adresy IP

Identyfikator problemu: 7791

Podpis dziennika: nie dotyczy

Naprawione w wersji 2607 i późniejszych

Od wersji 2605 złącze MQTT nie może łączyć się z zewnętrznymi brokerami MQTT korzystającymi z prywatnych adresów IP.

Problemy z przepływami danych

W tej sekcji wymieniono bieżące znane problemy dotyczące przepływów danych.

Aktualizacja nie powiodła się z powodu niezgodności parametru audience punktu końcowego rejestru ACR

Identyfikator problemu: 3245

Podpis dziennika: nie dotyczy

Aktualizacja Operacje Azure IoT może zakończyć się niepowodzeniem i cofnąć się, jeśli graf przepływu danych korzysta z punktu końcowego rejestru Azure Container Registry (ACR) z wyraźnie skonfigurowanym odbiorcą lub zakresem Azure Resource Manager (ARM). Wcześniejsze przykłady dokumentacji korzystały z odbiorców ARM, więc istniejąca konfiguracja działająca przed aktualizacją może przestać działać poprawnie.

Operator Dataflows rejestruje błąd niezgodności odbiorców podobny do poniższego:

audience 'https://management.azure.com/' does not match the expected audience 'https://containerregistry.azure.net'

Rozwiązanie obejściowe: Zaktualizuj istniejący zasób platformy Azure dla punktu końcowego rejestru za pomocą usługi Azure Resource Manager przed ponowną próbą aktualizacji:

  • Dla uwierzytelniania zarządzanej tożsamości przypisanej systemowo, zmień properties.authentication.systemAssignedManagedIdentitySettings.audience z https://management.azure.com/ na https://containerregistry.azure.net.
  • Dla uwierzytelniania zarządzanej tożsamości przypisanej przez użytkownika zmień properties.authentication.userAssignedManagedIdentitySettings.scope z https://management.azure.com/.default na https://containerregistry.azure.net/.default.

Zachowaj pozostałe właściwości punktu końcowego rejestru oraz ustawienia uwierzytelniania. Zaktualizuj istniejący zasób, zamiast tylko zmieniać lokalny plik wdrożenia lub pomijać argument z polecenia aktualizacji. Po tym, jak zasób Azure i odpowiadająca mu konfiguracja klastra odzwierciedlą nową wartość, ponów aktualizację.

Przykłady konfiguracji punktów końcowych rejestru można znaleźć w artykule Konfiguruj punkty końcowe rejestru.

Interfejs internetowy środowiska operacyjnego wyświetla tylko artefakty grafu przepływu danych pochodzące z usługi Azure Container Registry (ACR) i witryny mcr.microsoft.com

Numer wydania: 8895

Podpis dziennika: nie dotyczy

Nawet jeśli skonfigurujesz punkt końcowy rejestru kontenerów dla rejestru kontenerów innego niż ACR, na przykład GHCR:

  • Artefakty grafu przepływu danych z rejestru innego niż ACR nie pojawiają się w interfejsie internetowym Operations Experience, więc nie można utworzyć grafu przepływu danych wykorzystującego te artefakty.

  • Wybranie wykresu przepływu danych z listy przepływów danych w internetowym interfejsie użytkownika obszaru operacyjnego, który zawiera elementy z rejestru innego niż ACR, powoduje błąd podobny do: Can't load data flow graph. The contents of this data flow graph are unavailable. Please ensure that it still exists, then work with your administrator to get 'AcrPull' access to required registry endpoints.

Obejście: Masz dwie opcje:

  • Jeśli nie musisz korzystać z interfejsu użytkownika do obsługi operacji, użyj narzędzia Azure CLI do wykonywania operacji CRUD na grafach przepływu danych zdefiniowanych w plikach JSON lub plikach Bicep, które zawierają artefakty pochodzące z rejestrów innych niż ACR.

  • Jeśli chcesz korzystać z interfejsu webowego Operations Experience, zaimportuj artefakty przepływu danych i wykresy z rejestrów nie-ACR do rejestru ACR. Aby dowiedzieć się więcej, zobacz moduły Push do swojego rejestru.

Zasoby przepływu danych tworzone za pomocą Kubernetes nie są widoczne w interfejsie webowym doświadczenia operacyjnego

Identyfikator problemu: 8724

Podpis dziennika: nie dotyczy

Zasoby niestandardowe przepływu danych utworzone w Twoim klastrze przy użyciu Kubernetes nie są widoczne w interfejsie webowym doświadczenia operacyjnego. Ten wynik jest oczekiwany, ponieważ zarządzanie składnikami Operacje Azure IoT przy użyciu platformy Kubernetes służy tylko do debugowania i testowania, a synchronizowanie zasobów z krawędzi do chmury nie jest obecnie obsługiwane.

Obecnie nie ma obejścia tego problemu.

Nie można wielokrotnie używać tej samej definicji grafu w scenariuszu grafu łańcuchowego

Identyfikator problemu: 1352

Naprawiono w wersji 1.3.36 (2603) i nowszej

Nie można wysłać konfiguracji

Scenariusz grafu łańcuchowego jest tworzony przy użyciu danych wyjściowych jednego grafu przepływu danych jako danych wejściowych do innego grafu przepływu danych. Jeśli jednak spróbujesz użyć tej samej definicji grafu wiele razy w tym scenariuszu, obecnie nie będzie działać zgodnie z oczekiwaniami. Na przykład poniższy kod kończy się niepowodzeniem w przypadku używania tej samej definicji grafu (graph-passthrough:1.3.6) dla obu graph-1 oraz graph-2.

      {
          nodeType: 'Graph'
          name: 'graph-1'
          graphSettings: {
            registryEndpointRef: dataflowRegistryEndpoint.name
            artifact: 'graph-passthrough:1.3.6'
            configuration: []
            }
      }
      {
          nodeType: 'Graph'
          name: 'graph-2'
          graphSettings: {
            registryEndpointRef: dataflowRegistryEndpoint.name
            artifact: 'graph-passthrough:1.3.6'
            configuration: graphConfiguration
            }
      }
  nodeConnections: [
      {
          from: {name: 'source'}
          to: {name: 'graph-1'}
      }
      {
          from: {name: 'graph-1'}
          to: {name: 'graph-2'}
      }
      {
          from: {name: 'graph-2'}
          to: {name: 'destination'}
      }
  ]

Aby rozwiązać ten błąd, wypchnij definicję grafu do usługi ACR tyle razy, ile jest to konieczne, przy użyciu scenariusza z inną nazwą lub tagiem za każdym razem. Na przykład, w opisanym scenariuszu definicja grafu musi zostać dwukrotnie przesłana z różną nazwą lub różnym tagiem, takim jak graph-passthrough-one:1.3.6 i graph-passthrough-two:1.3.6.

Problemy z rejestrem krawędzi

Ta sekcja zawiera aktualne znane problemy z rejestrem brzegowym.

Konfiguracja tożsamości przypisanej przez użytkownika używa niewłaściwego konta usługi rejestru

Identyfikator problemu: 3467

Dotyczy: Operacje Azure IoT 2610 publiczna wersja zapoznawcza. Zgłoszono w wersji 1.6.0-preview.57; niedopasowanie CLI występuje także w rozszerzeniu CLI v2.11.2, którego profil podglądu wdrożenia używa v1.6.0-preview.60.

Poprawka planowana na wydanie 2612.

Podpis dziennika: nie dotyczy

Gdy uruchamiasz az iot ops identity assign --usage schema na dotkniętej instancji podglądu, CLI tworzy federowane dane uwierzytelniające o wartości pola subject system:serviceaccount:azure-iot-operations:adr-schema-registry. Rejestr krawędzi podglądu działa jako konto usługi aio-edge-registry, więc dane uwierzytelniające nie pasują do obciążenia.

Polecenie może zgłaszać sukces, mimo że konto serwisowe rejestru brzegowego nie ma pasującego poświadczenia federacyjnego. Rejestr może nadal korzystać z istniejącej tożsamości zarządzanej przypisanej przez system, ukrywając niezgodność konfiguracji.

Obejście problemu:

  1. W zarządzanej tożsamości przypisanej przez użytkownika, przeznaczonej dla rejestru brzegowego, dodaj poświadczenie federacyjne o następujących wartościach:
    • Wystawca: Adres URL wystawcy OIDC połączonego klastra.
    • Temat:system:serviceaccount:azure-iot-operations:aio-edge-registry podmiot dla domyślnej przestrzeni nazw. Jeśli używasz innej przestrzeni nazw, zastąp ją rzeczywistą nazwą przestrzeni nazw.
    • Odbiorcy:api://AzureADTokenExchange.
  2. Sprawdź, czy dane uwierzytelniające zgadzają się z kontem serwisowym używanym przez pod rejestru brzegowego. Jeśli musisz zrestartować rejestr podglądowy, jego StatefulSet to aio-edge-registry, a nie adr-schema-registry.

Dodanie tego poświadczenia koryguje niedopasowanie trustu, ale przyjęcie zmiany tożsamości przez działający rejestr jest osobno badane. Dodanie poświadczenia nie potwierdza, że rejestr przełączył się na inną tożsamość. Wybór spośród wielu tożsamości przypisanych przez użytkownika jest również badany.

Problemy z akcjami zarządzania

Ta sekcja zawiera aktualne znane problemy związane z działaniami zarządczymi.

Subskrypcja Event Grid nie jest gotowa natychmiast po włączeniu działań zarządczych

Identyfikator problemu: 0208

Dotyczy: rozszerzenia CLI v2.11.0 w Operacje Azure IoT 2610 public preview, zgłoszone na v1.6.0-preview.57.

Poprawka planowana na wydanie 2612.

Sygnatura logu: Pod przepływu danych rejestruje awarie subskrypcji, a metryka Mqtt.FailedSubscriptionOperations przestrzeni nazw Event Grid raportuje Error=AuthorizationError.

Polecenie az iot ops mgmt-actions enable tworzy wykres przepływu danych żądania przed przypisaniem ról Publisher i Subscriber usługi Event Grid TopicSpaces. Graf może próbować subskrybować, zanim zostanie autoryzowany. Podejmuje ponowne próby z mechanizmem backoff, a niepowodzenia autoryzacji mogą krótko trwać po zgłoszeniu sukcesu przez CLI.

Działania zarządcze mogą nie dotrzeć do węzła brzegowego, dopóki subskrypcja grafu żądań nie zakończy się sukcesem.

Obejście: Odczekaj około minuty po zwróceniu przez az iot ops mgmt-actions enable, zanim wyślesz pierwszą akcję. Sprawdź logi grafu żądań, aby potwierdzić, że jego subskrypcja zakończyła się powodzeniem. Jeśli awarie autoryzacji będą się powtarzać, zweryfikuj wymagane przypisania ról i odczekaj dodatkowy czas na propagację ról. Nie odtwarzaj automatycznie działań nieidempotentnych, których wynik wykonania jest nieznany.

Problemy tożsamości federacyjnej

W tej sekcji wymieniono aktualnie znane problemy dotyczące federacji tożsamości.

Niezgodność wystawcy federacyjnego poświadczenia tożsamości może powodować błędy uwierzytelniania podczas synchronizacji wpisów tajnych

Numer numeru: 1190

Naprawione w wersji 2607 i późniejszych

Sygnatura dziennika: Podobnie jak AADSTS700211: No matching federated identity record found for presented assertion issuer 'https://northamerica.oic.prod-arc.azure.com/1f5f7baf-633d-4eb5-9be1-8cf1e9c6fcc9/f512e8f6-0c47-48a1-91f3-aeb5422dd766'. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion.

Operacje Azure IoT napotyka 401 nieautoryzowanych błędów przy pobieraniu sekretów z Azure Key Vault.

Główna przyczyna: Błąd występuje, ponieważ adres URL wystawcy federacyjnych poświadczeń tożsamości nie jest zgodny z oświadczeniem wystawcy (iss) w tokenie konta usługi Kubernetes.

Gdy polecenie az iot ops secretsync enable tworzy poświadczenie federacyjnej tożsamości (FIC) dla zarządzanej tożsamości przypisanej przez użytkownika, której usługa Operacje Azure IoT używa do uzyskiwania dostępu do usługi Azure Key Vault, ustawia adres URL emitenta FIC na adres URL emitenta OIDC klastra. W niektórych wdrożeniach ten adres URL zawiera końcowy ukośnik („/”), którego brakuje w oświadczeniu „iss” (wystawca) tokena konta usługi wydanego przez klaster.

Ponieważ problem dotyczy wymiany tokenów podczas odzyskiwania sekretów, awaria zazwyczaj nie występuje podczas uruchamiania az iot ops secretsync enable. Zamiast tego pojawia się później, gdy Operacje Azure IoT próbuje uzyskać dostęp do sekretu, co może utrudnić identyfikację przyczyny.

Obejście: Sprawdź, czy adres URL wydawcy skonfigurowany na federowanym identyfikatorze nie kończy się ukośnikiem. Jeśli tak, zaktualizuj poświadczenie federacyjne tożsamości, aby usunąć końcowy ukośnik.

Możesz użyć poleceń interfejsu wiersza polecenia platformy Azure az identity federated-credential, aby wyświetlić i, w razie potrzeby, zaktualizować wartość wystawcy poświadczenia federacyjnej tożsamości, na przykład:

az identity federated-credential show --name <fic-name> --identity-name <managed-identity-name> --resource-group <resource-group-name>

az identity federated-credential update --name <fic-name> --identity-name <managed-identity-name> --resource-group <resource-group> --issuer <new-issuer-url-without-trailing-slash>

Najlepszą praktyką jest wykonanie tej weryfikacji podczas konfiguracji po uruchomieniu az iot ops secretsync enable polecenia, aby uniknąć potencjalnie trudnych do diagnozowania awarii uwierzytelniania w przyszłości.

Problemy z protokołem Model Context Protocol (MCP)

Ta sekcja zawiera aktualne znane problemy MCP.

Wdrożenie z certyfikatami zarządzanymi przez klienta kończy się niepowodzeniem, gdy włączone jest MCP

Identyfikator problemu: 3314

Dotyczy: Operacje Azure IoT 2610 wersja zapoznawcza.

Poprawka planowana na wydanie 2612.

Podpis dziennika: nie dotyczy

Gdy używasz własnego wystawcy certyfikatów, wdrożenie Operacje Azure IoT kończy się niepowodzeniem, jeśli MCP jest włączone. Komponenty MCP odwołują się do domyślnego emitenta certyfikatu i pakietu zaufania zamiast skonfigurowanych zasobów.

Obejście: Aby ocenić inne funkcje Operacje Azure IoT za pomocą certyfikatów zarządzanych przez klienta, jawnie ustaw features.mcp.mode na Disabled w konfiguracji wdrożenia przed wdrożeniem. MCP jest domyślnie włączone. Zobacz Wyłącz MCP, aby uzyskać informacje o ustawieniu konfiguracji.

  • Ostatnia aktualizacja o