Rozwiązywanie problemów i diagnozowanie błędów przepływów pracy w usłudze Azure Logic Apps

Dotyczy: Azure Logic Apps (Zużycie + Standardowa)

Przepływ pracy aplikacji logiki generuje informacje, które mogą pomóc w diagnozowaniu i debugowaniu problemów w aplikacji. Przepływ pracy można zdiagnozować, przeglądając dane wejściowe, wyjściowe i inne informacje dla każdego kroku przepływu pracy przy użyciu witryny Azure Portal. Możesz też dodać kilka kroków do przepływu pracy na potrzeby debugowania środowiska uruchomieniowego.

Sprawdzanie historii wyzwalacza

Każde uruchomienie przepływu pracy rozpoczyna się od wyzwalacza, który jest uruchamiany zgodnie z harmonogramem lub czeka na przychodzące żądanie lub zdarzenie. Historia wyzwalacza zawiera listę wszystkich prób wyzwalacza wykonanych przez przepływ pracy oraz informacje o danych wejściowych i wyjściowych dla każdej próby wyzwalacza. Jeśli wyzwalacz nie zostanie wyzwolony, spróbuj wykonać następujące czynności.

Zużycie

1. Aby sprawdzić stan wyzwalacza w aplikacji logiki Zużycie, zapoznaj się z historią wyzwalacza. Aby wyświetlić więcej informacji o próbie wyzwalacza, wybierz to zdarzenie wyzwalacza, na przykład:

   

2. Sprawdź dane wejściowe wyzwalacza, aby potwierdzić, że są one wyświetlane zgodnie z oczekiwaniami. W okienku Historia w obszarze Dane wejściowe wybierz link, który zawiera okienko Dane wejściowe.

   Dane wejściowe wyzwalacza obejmują dane oczekiwane przez wyzwalacz i wymagają uruchomienia przepływu pracy. Przejrzenie tych danych wejściowych może pomóc w ustaleniu, czy dane wejściowe wyzwalacza są poprawne i czy warunek został spełniony, aby przepływ pracy mógł kontynuować.

   

3. Sprawdź dane wyjściowe wyzwalaczy, jeśli istnieją, aby potwierdzić, że są one wyświetlane zgodnie z oczekiwaniami. W okienku Historia w obszarze Dane wyjściowe wybierz link, który zawiera okienko Dane wyjściowe.

   Dane wyjściowe wyzwalacza obejmują dane, które wyzwalacz przekazuje do następnego kroku w przepływie pracy. Przejrzenie tych danych wyjściowych może pomóc w ustaleniu, czy poprawne lub oczekiwane wartości zostały przekazane do następnego kroku w przepływie pracy.

   Na przykład komunikat o błędzie wskazuje, że kanał informacyjny RSS nie został znaleziony:

   

   Napiwek

   Jeśli znajdziesz dowolną zawartość, której nie rozpoznajesz, dowiedz się więcej o różnych typach zawartości w usłudze Azure Logic Apps.

Standardowa

1. Aby sprawdzić stan wyzwalacza w aplikacji logiki w warstwie Standardowa, przejrzyj historię wyzwalaczy. Aby wyświetlić więcej informacji o próbie wyzwalacza, wybierz to zdarzenie wyzwalacza, na przykład:

   

2. Sprawdź dane wejściowe wyzwalacza, aby potwierdzić, że są one wyświetlane zgodnie z oczekiwaniami. W okienku Historia w obszarze Dane wejściowe wybierz link, który zawiera okienko Dane wejściowe.

   Dane wejściowe wyzwalacza obejmują dane oczekiwane przez wyzwalacz i wymagają uruchomienia przepływu pracy. Przejrzenie tych danych wejściowych może pomóc w ustaleniu, czy dane wejściowe wyzwalacza są poprawne i czy warunek został spełniony, aby przepływ pracy mógł kontynuować.

   

3. Sprawdź dane wyjściowe wyzwalaczy, jeśli istnieją, aby potwierdzić, że są one wyświetlane zgodnie z oczekiwaniami. W okienku Historia w obszarze Dane wyjściowe wybierz link, który zawiera okienko Dane wyjściowe.

   Dane wyjściowe wyzwalacza obejmują dane, które wyzwalacz przekazuje do następnego kroku w przepływie pracy. Przejrzenie tych danych wyjściowych może pomóc w ustaleniu, czy poprawne lub oczekiwane wartości zostały przekazane do następnego kroku w przepływie pracy.

   Na przykład komunikat o błędzie wskazuje, że kanał informacyjny RSS nie został znaleziony:

   

   Napiwek

   Jeśli znajdziesz dowolną zawartość, której nie rozpoznajesz, dowiedz się więcej o różnych typach zawartości w usłudze Azure Logic Apps.

Sprawdzanie historii uruchamiania przepływu pracy

Za każdym razem, gdy wyzwalacz jest uruchamiany, usługa Azure Logic Apps tworzy wystąpienie przepływu pracy i uruchamia to wystąpienie. Jeśli przebieg zakończy się niepowodzeniem, spróbuj wykonać następujące czynności, aby sprawdzić, co się stało podczas tego przebiegu. Możesz przejrzeć stan, dane wejściowe i wyjściowe dla każdego kroku w przepływie pracy.

Zużycie

1. Aby sprawdzić stan uruchomienia przepływu pracy w aplikacji logiki Zużycie, zapoznaj się z historią przebiegów. Aby wyświetlić więcej informacji na temat uruchomienia, w tym wszystkich kroków w tym przebiegu w ich stanie, wybierz przebieg, który zakończył się niepowodzeniem.

   

2. Po pojawieniu się wszystkich kroków w przebiegu wybierz każdy krok, aby rozwinąć kształty.

   

3. Przejrzyj dane wejściowe, dane wyjściowe i wszelkie komunikaty o błędach dla kroku, który zakończył się niepowodzeniem.

   

   Na przykład poniższy zrzut ekranu przedstawia dane wyjściowe z nieudanej akcji RSS.

   

Standardowa

1. Aby sprawdzić stan uruchomienia przepływu pracy w aplikacji logiki w warstwie Standardowa, zapoznaj się z historią przebiegów. Aby wyświetlić więcej informacji na temat uruchomienia, w tym wszystkich kroków w tym przebiegu w ich stanie, wybierz przebieg, który zakończył się niepowodzeniem.

   

2. Po pojawieniu się wszystkich kroków w przebiegu wybierz każdy krok, aby przejrzeć ich szczegóły.

   

3. Przejrzyj dane wejściowe, dane wyjściowe i wszelkie komunikaty o błędach dla kroku, który zakończył się niepowodzeniem.

   

   Na przykład poniższy zrzut ekranu przedstawia dane wyjściowe z nieudanej akcji RSS.

   

Wykonywanie debugowania środowiska uruchomieniowego

Aby ułatwić debugowanie, możesz dodać kroki diagnostyczne do przepływu pracy aplikacji logiki oraz przejrzeć historię wyzwalacza i przebiegów. Możesz na przykład dodać kroki korzystające z usługi Tester elementu webhook, aby sprawdzić żądania HTTP i określić ich dokładny rozmiar, kształt i format.

1. W przeglądarce przejdź do witryny testera elementu webhook i skopiuj wygenerowany unikatowy adres URL.

2. W aplikacji logiki dodaj akcję HTTP POST z zawartością treści, którą chcesz przetestować, na przykład wyrażenie lub inne dane wyjściowe kroku.

3. Wklej adres URL z testera elementu webhook do akcji HTTP POST.

4. Aby sprawdzić, jak usługa Azure Logic Apps generuje i tworzy żądanie, uruchom przepływ pracy aplikacji logiki. Następnie możesz ponownie zapoznać się z witryną testera elementu webhook, aby uzyskać więcej informacji.

Wydajność — często zadawane pytania

Dlaczego czas trwania przebiegu przepływu pracy jest dłuższy niż suma wszystkich czasów trwania akcji przepływu pracy?

Planowanie obciążenia istnieje podczas uruchamiania akcji, a czas oczekiwania między akcjami może wystąpić z powodu obciążenia systemu zaplecza. Czas trwania przebiegu przepływu pracy obejmuje te czasy planowania i czas oczekiwania wraz z sumą wszystkich czasów trwania akcji.

Zwykle mój przepływ pracy kończy się w ciągu 10 sekund. Ale czasami ukończenie może trwać znacznie dłużej. Jak upewnić się, że przepływ pracy zawsze kończy się w ciągu 10 sekund?

• Brak gwarancji SLA w przypadku opóźnienia.

• Przepływy pracy użycia działają w wielodostępnej usłudze Azure Logic Apps, więc obciążenia innych klientów mogą negatywnie wpłynąć na wydajność przepływu pracy.

• Aby uzyskać bardziej przewidywalną wydajność, warto rozważyć utworzenie standardowych przepływów pracy uruchamianych w usłudze Azure Logic Apps z jedną dzierżawą. Będziesz mieć większą kontrolę nad skalowaniem w górę lub w poziomie w celu zwiększenia wydajności.

Mój czas akcji upływa po 2 minutach. Jak mogę zwiększyć wartość limitu czasu?

Nie można zmienić wartości limitu czasu akcji i jest stała o 2 minutach. Jeśli używasz akcji HTTP i jesteś właścicielem usługi wywoływanej przez akcję HTTP, możesz zmienić usługę, aby uniknąć 2-minutowego limitu czasu przy użyciu wzorca asynchronicznego. Aby uzyskać więcej informacji, zobacz Wykonywanie długotrwałych zadań za pomocą wzorca akcji sondowania.

Typowe problemy — standardowe aplikacje logiki

Niedostępne artefakty na koncie usługi Azure Storage

Standardowe aplikacje logiki przechowują wszystkie artefakty na koncie usługi Azure Storage. Jeśli te artefakty nie są dostępne, mogą wystąpić następujące błędy. Na przykład samo konto magazynu może być niedostępne lub konto magazynu znajduje się za zaporą, ale nie skonfigurowaliśmy prywatnego punktu końcowego dla usług magazynu do użycia.

Lokalizacja witryny Azure Portal	Błąd
Okienko przeglądu	- System.private.corelib:Odmowa dostępu do ścieżki "C:\home\site\wwwroot\hostj.son" - Azure.Storage.Blobs: to żądanie nie jest autoryzowane do wykonania tej operacji
Okienko Przepływy pracy	- Nie można uzyskać dostępu do środowiska uruchomieniowego hosta. Szczegóły błędu, Kod: "BadRequest", Komunikat: "Napotkano błąd (InternalServerError) ze środowiska uruchomieniowego hosta. - Nie można uzyskać dostępu do środowiska uruchomieniowego hosta. Szczegóły błędu, Kod: "BadRequest", Komunikat: "Napotkano błąd (ServiceUnavailable) ze środowiska uruchomieniowego hosta. - Nie można uzyskać dostępu do środowiska uruchomieniowego hosta. Szczegóły błędu, Kod: "BadRequest", Komunikat: "Napotkano błąd (BadGateway) ze środowiska uruchomieniowego hosta.
Podczas tworzenia i wykonywania przepływu pracy	- Nie można zapisać przepływu pracy - Błąd w projektancie: GetCallFailed. Nieudane operacje pobierania - Wywołanie ajaxExtended nie powiodło się

Opcje rozwiązywania problemów

Poniższa lista zawiera możliwe przyczyny tych błędów i kroków, które ułatwiają rozwiązywanie problemów.

• W przypadku konta magazynu publicznego sprawdź dostęp do konta magazynu w następujący sposób:

  • Sprawdź łączność konta magazynu przy użyciu Eksplorator usługi Azure Storage.

  • W ustawieniach aplikacji aplikacji logiki potwierdź parametry połączenia konta magazynu w ustawieniach aplikacji AzureWebJobsStorage i WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Aby uzyskać więcej informacji, zapoznaj się z tematem Host i ustawienia aplikacji dla aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.

  Jeśli łączność nie powiedzie się, sprawdź, czy klucz sygnatury dostępu współdzielonego (SAS) w parametry połączenia jest najnowszy.

  Ważne

  Jeśli masz poufne informacje, takie jak parametry połączenia zawierające nazwy użytkowników i hasła, upewnij się, że jest dostępny najbezpieczniejszy przepływ uwierzytelniania. Na przykład w standardowych przepływach pracy aplikacji logiki bezpieczne typy danych, takie jak securestring i secureobject, nie są obsługiwane. Firma Microsoft zaleca uwierzytelnianie dostępu do zasobów platformy Azure przy użyciu tożsamości zarządzanej, jeśli to możliwe, i przypisanie roli, która ma najmniejsze uprawnienia niezbędne.

  Jeśli ta funkcja jest niedostępna, upewnij się, że zabezpieczenia parametry połączenia za pomocą innych miar, takich jak

Usługa Azure Key Vault, której można używać z ustawieniami aplikacji. Następnie można bezpośrednio odwoływać się do bezpiecznych ciągów, takich jak parametry połączenia i klucze. Podobnie jak w przypadku szablonów usługi ARM, gdzie można zdefiniować zmienne środowiskowe w czasie wdrażania, można zdefiniować ustawienia aplikacji w definicji przepływu pracy aplikacji logiki. Następnie można przechwytywać dynamicznie generowane wartości infrastruktury, takie jak punkty końcowe połączenia, parametry magazynu i inne. Aby uzyskać więcej informacji, zobacz Typy aplikacji dla Platforma tożsamości Microsoft.

• W przypadku konta magazynu, które znajduje się za zaporą, sprawdź dostęp do konta magazynu w następujący sposób:

  • Jeśli na koncie magazynu są włączone ograniczenia zapory, sprawdź, czy prywatne punkty końcowe są skonfigurowane dla usług Blob, File, Table i Queue Storage.

  • Sprawdź łączność konta magazynu przy użyciu Eksplorator usługi Azure Storage.

  Jeśli znajdziesz problemy z łącznością, wykonaj następujące czynności:

  1. W tej samej sieci wirtualnej zintegrowanej z aplikacją logiki utwórz maszynę wirtualną platformy Azure, którą można umieścić w innej podsieci.

  2. W wierszu polecenia uruchom polecenie nslookup , aby sprawdzić, czy usługi Blob, File, Table i Queue Storage są rozpoznawane jako oczekiwane adresy IP.

     Składnia: nslookup [StorageaccountHostName] [OptionalDNSServer]

     Blob: nslookup {StorageaccountName}.blob.core.windows.net

     Plik: nslookup {StorageaccountName}.file.core.windows.net

     Stół: nslookup {StorageaccountName}.table.core.windows.net

     Kolejka: nslookup {StorageaccountName}.queue.core.windows.net

     • Jeśli usługa magazynu ma punkt końcowy usługi, usługa jest rozpoznawana jako publiczny adres IP.

     • Jeśli usługa magazynu ma prywatny punkt końcowy, usługa rozpoznaje odpowiednie prywatne adresy IP kontrolera interfejsu sieciowego.

  3. Jeśli poprzednie zapytania serwera nazw domen (DNS) zostały pomyślnie rozwiązane, uruchom polecenia psping lub tcpping , aby sprawdzić łączność z kontem magazynu za pośrednictwem portu 443:

     Składnia: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

     Blob: psping {StorageaccountName}.blob.core.windows.net:443

     Plik: psping {StorageaccountName}.file.core.windows.net:443

     Stół: psping {StorageaccountName}.table.core.windows.net:443

     Kolejka: psping {StorageaccountName}.queue.core.windows.net:443

  4. Jeśli każda usługa magazynu jest rozpoznawalna z maszyny wirtualnej platformy Azure, znajdź system DNS używany przez maszynę wirtualną do rozpoznawania.

     1. Ustaw ustawienie aplikacji WEBSITE_DNS_SERVER aplikacji logiki na dns i upewnij się, że system DNS działa pomyślnie.

     2. Upewnij się, że integracja z siecią wirtualną jest poprawnie skonfigurowana z odpowiednią siecią wirtualną i podsiecią w aplikacji logiki w warstwie Standardowa.

  5. Jeśli używasz prywatnych stref DNS platformy Azure dla prywatnych usług punktu końcowego konta magazynu, sprawdź, czy łącze sieci wirtualnej zostało utworzone w zintegrowanej sieci wirtualnej aplikacji logiki.

Aby uzyskać więcej informacji, zobacz Deploy Standard logic app to a storage account behind a firewall using service or private endpoints (Wdrażanie standardowej aplikacji logiki na koncie magazynu za zaporą przy użyciu usługi lub prywatnych punktów końcowych).

Następne kroki

• Monitorowanie aplikacji logiki