Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Ten artykuł zawiera ogólne wskazówki dotyczące rozwiązywania problemów dotyczących punktów zaczepienia usługi Azure DevOps. Zawiera również odpowiedzi na często zadawane pytania.
Wyświetlanie aktywności i debugowanie problemów
Strona Service Hooks w panelu administracyjnym dostępu internetowego zawiera podsumowanie aktywności z ostatnich siedmiu dni dla każdej subskrypcji. Strona pokazuje również, czy każda subskrypcja jest włączona, wyłączona, czy ograniczona.
Dla każdej subskrypcji można uzyskać dostęp do szczegółowej historii zawierającej pełne dane żądania i odpowiedzi dla każdego zdarzenia. Te informacje mogą pomóc w debugowaniu problematycznej usługi lub subskrypcji.
Aby wyświetlić aktywność i stan subskrypcji, przejdź do strony Service Hooks.
Aby wyświetlić szczegółowe działania dla subskrypcji, w tym pełne dane żądania, odpowiedzi i ładunku zdarzenia, wybierz subskrypcję w tabeli, a następnie wybierz pozycję historia.
Błędy subskrypcji i okres próbny (ograniczony)
Jeśli odpowiedź HTTP na żądanie powiadomienia wskazuje błąd, ważność błędu określa, jak Azure DevOps odpowiada. Niektóre typy niepowodzeń mogą wyłączać subskrypcje lub umieszczać je w stanie zawieszenia.
Typy błędów
Błędy z powiadomień punktów zaczepienia usługi są pogrupowane w następujące kategorie:
- Błędy terminalu
- Awarie przejściowe
- Trwałe błędy
Kod błędu z odpowiedzi HTTP określa, jak Azure DevOps kategoryzuje błąd.
Błędy terminalu
Jedynym kodem stanu HTTP, który jest sklasyfikowany jako błąd terminalu, jest 410 (Gone).
Gdy w subskrypcji wystąpi błąd terminalu, subskrypcja zostanie automatycznie wyłączona bez względu na jej poprzedni stan.
Awarie przejściowe
Odpowiedzi HTTP z następującymi kodami stanu są klasyfikowane jako błędy przejściowe:
- 408 (Limit czasu żądania)
- 502 (Zła brama)
- 503 (Usługa niedostępna)
- 504 (Limit czasu bramy)
Gdy w subskrypcji wystąpi błąd przejściowy, Azure DevOps próbuje ponownie wysłać powiadomienie do ośmiu razy, z rosnącym opóźnieniem między poszczególnymi próbami.
W poniższej tabeli wymieniono informacje o ponownych próbach po wystąpieniu błędu przejściowego. Uwzględniony jest przybliżony czas wycofywania lub czas oczekiwania przed podjęciem próby ponownego uruchomienia powiadomienia. Maksymalny czas wycofywania wynosi 60 sekund. W tabeli przedstawiono również łączne opóźnienie dla każdej próby ponowienia.
| Numer ponawiania próby | Czas opóźnienia w sekundach | Łączne opóźnienie w sekundach |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 3 |
| 3 | 4 | 7 |
| 4 | 8 | 15 |
| 5 | 16 | 31 |
| 6 | 32 | 63 |
| 7 | 60 | 123 |
| 8 | 60 | 183 |
Jeśli wszystkie ponawianie próby powiadomienia zostaną wyczerpane i każda próba spowoduje wystąpienie błędu przejściowego, powiadomienie nie zostanie już wysłane. Zamiast tego jest klasyfikowany jako trwały błąd.
Trwałe błędy
Wszystkie inne kody błędów HTTP, na przykład 404 (Nie znaleziono) i 500 (wewnętrzny błąd serwera), powodują trwałe błędy.
Gdy w subskrypcji wystąpi trwały błąd, subskrypcja zostanie umieszczona w okresie próbnym.
Okres próbny / Nadzór kuratorski
Gdy subskrypcja jest objęta okresem próbnym, traci wszelkie nowe zdarzenia. System wykonuje ograniczoną liczbę prób ponownego wysłanie powiadomienia, które zakończyło się niepowodzeniem.
W poniższej tabeli przedstawiono przybliżone czasy opóźnienia oraz łączne czasy trwania okresu próbnego dla ponownych prób podejmowanych przez system w okresie próbnym. System podejmuje maksymalnie siedem prób ponowienia, a maksymalne opóźnienie dla ponowienia w okresie próbnym wynosi 15 godzin.
| Numer ponawiania próby | Czas wycofywania | Łączny czas próbny w godzinach |
|---|---|---|
| 1 | 20 minut | 0.33 |
| 2 | 40 minut | 1 |
| 3 | 1 godzina 20 minut | 2.33 |
| 4 | 2 godziny 40 minut | 5 |
| 5 | 5 godzin 20 minut | 10.33 |
| 6 | 10 godzin 40 minut | dwadzieścia jeden |
| 7 | 15 godzin | 36 |
Jeśli subskrypcja otrzymuje prawidłową odpowiedź w okresie próbnym, system przywraca ją do stanu pełnej aktywności i ponownie publikuje zdarzenia. Jeśli wszystkie siedem ponownych prób nie powiedzie się, system ustawia stan subskrypcji na DisabledBySystem.
Subskrypcje wyłączone z powodu braku aktywności
Azure DevOps automatycznie wyłącza subskrypcję, gdy ostatnie pomyślne dostarczanie powiadomień było ponad sześć miesięcy temu. Subskrypcja przestaje odbierać zdarzenia, dopóki użytkownik nie włączy go ponownie.
To sprawdzenie bezczynności uwzględnia tylko ostatnią pomyślnie zrealizowaną próbę dostarczenia. Nie uwzględnia ona momentu utworzenia lub ostatniej edycji subskrypcji ani liczby zdarzeń pasowanych do subskrypcji. Subskrypcja, która nadal dostarcza powiadomienia, nie jest wyłączona z powodu braku aktywności, niezależnie od wieku. Na subskrypcję bez zarejestrowanych pomyślnych dostaw nie ma wpływu sprawdzanie braku aktywności.
Użyj sztucznej inteligencji do rozwiązywania problemów z hakiem serwisowym
Poniższy przykładowy monit dla Copilot Chat pomaga Copilotowi w rozwiązywaniu problemów z kodem błędu i komunikatem. Skopiuj i wklej ten monit do Copilot Chat, zastępując symbol zastępczy określonym komunikatem o błędzie.
I'm getting this Azure DevOps service hook error: [PASTE YOUR ERROR MESSAGE HERE]
Can you help me troubleshoot this issue? Please provide step-by-step instructions to:
1. Identify the root cause
2. Fix the issue
3. Verify the solution works
Context: This is for a service hook in Azure DevOps.
Często zadawane pytania
.: Jaki jest limit ładunku elementu zaczepienia usługi?
A: Limit ładunku wynosi 2 MB. Większe ładunki powodują obniżenie wydajności i niezawodności. Najlepszą praktyką jest ograniczenie ładunku serwisowych haków do 2 MB.
.: Co oznacza stan Włączone (ograniczone)?
A: Subskrypcja staje się ograniczona, jeśli wystąpi zbyt wiele awarii. Bycie w stanie Włączone (ograniczone) jest takie samo jak w okresie próbnym.
Pyt.: Dlaczego subskrypcja może zostać wyłączona?
A: Subskrypcja jest automatycznie wyłączona w następujących przypadkach:
- Napotkano błąd terminalu.
- Szereg kolejnych awarii występuje w dłuższym okresie.
- Ostatnie pomyślne dostarczenie powiadomienia miało miejsce ponad sześć miesięcy temu.
- Użytkownik, który utworzył subskrypcję, nie jest już członkiem zespołu.
Co oznacza stan Wyłączony (z powodu awarii)?
A: Powiadomienia, które powodują błędy przejściowe, są ponawiane kilka razy przed zadeklarowaniem trwałych błędów. Trwałe powiadomienia o niepowodzeniu są ponawiane ograniczoną liczbę razy podczas okresu próbnego. Jeśli wszystkie próby próbne nie ponawiają się, subskrypcja zostanie wyłączona.
Następujące kody stanu zawierają przykłady każdego typu awarii:
- Przejściowy: 408 (limit czasu żądania), 502 (zła brama), 503 (usługa niedostępna), 504 (limit czasu bramy)
- Terminal: 410 (zniknęły)
- Trwałe: wszystkie błędy, które nie są przejściowe lub terminalowe
Pyt.: Co oznacza stan „Wyłączone” (z powodu nieaktywności)?
A: Ostatnie pomyślne dostarczenie powiadomienia dla tej subskrypcji miało miejsce ponad sześć miesięcy temu, więc usługa Azure DevOps ją wyłączyła. Ten stan różni się od Wyłączony (z powodu błędów), co oznacza, że usługa Azure DevOps podjęła próbę dostarczenia, ale dostarczenie wielokrotnie kończyło się niepowodzeniem. Włącz ponownie subskrypcję, jeśli integracja jest nadal potrzebna.
Pyt.: Dlaczego subskrypcje nieaktywne są wyłączone?
A: Azure DevOps ocenia każdą subskrypcję, gdy zostanie opublikowane pasujące zdarzenie, nawet jeśli integracja odbierająca nie jest już aktywna. Z czasem w organizacjach mogą się nagromadzić nieaktywne subskrypcje, gdy potoki przetwarzania są wycofywane, a integracje przestają być używane. Niektóre organizacje mają dziesiątki tysięcy subskrypcji, które nie dostarczały powiadomień od lat. Wyłączenie nieaktywnych subskrypcji pomaga zapewnić szybkie i niezawodne punkty zaczepienia usług dla subskrypcji, które są nadal używane.
Jaki jest stan Wyłączone (użytkownik opuścił projekt)?
A: Użytkownik, który utworzył subskrypcję, nie jest już członkiem zespołu.
.: Co należy wypróbować, jeśli punkt zaczepienia usługi nie działa?
A: Sprawdź następujące elementy:
- Potwierdź, że subskrypcja jest włączona.
- Upewnij się, że ustawienia subskrypcji są poprawne. Sprawdź filtry i akcje zdarzeń.
- Przyjrzyj się historii, zwłaszcza jeśli występują błędy.
Czy mogę przyznać zwykłemu użytkownikowi projektu możliwość wyświetlania i zarządzania subskrypcjami webhooków dla projektu?
A: Domyślnie tylko administratorzy projektu mają te uprawnienia. Aby przyznać je bezpośrednio innym użytkownikom, użyj narzędzia wiersza polecenia lub interfejsu API REST Security.
.: Czy mogę programowo tworzyć subskrypcje?
A: Tak, użyj interfejsów API REST .