Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
Questo articolo offre indicazioni generali sulla risoluzione dei problemi per gli hook del servizio Azure DevOps. Fornisce anche risposte alle domande frequenti .
Visualizzare i problemi relativi all'attività e al debug
La pagina Service Hooks nell'amministratore dell'accesso Web riepiloga l'attività degli ultimi sette giorni per ogni sottoscrizione. La pagina mostra anche se ogni sottoscrizione è abilitata, disabilitata o limitata.
Per ogni sottoscrizione, è possibile accedere a una cronologia dettagliata che include i dati di richiesta e risposta completi per ogni evento. Queste informazioni consentono di eseguire il debug di un servizio o una sottoscrizione problematica.
Per visualizzare l'attività e lo stato delle sottoscrizioni, vai alla pagina Service Hooks.
Per visualizzare attività dettagliate per una sottoscrizione, inclusi i dati completi relativi a richiesta, risposta e payload degli eventi, selezionare una sottoscrizione nella tabella e quindi selezionare Cronologia.
Fallimenti delle sottoscrizioni e periodi di prova (con restrizioni)
Se la risposta HTTP a una richiesta di notifica indica un errore, la gravità dell'errore determina la risposta di Azure DevOps. Alcuni tipi di errori possono disabilitare gli abbonamenti o metterli in sospensione.
Tipi di errore
Gli errori delle notifiche hook del servizio sono raggruppati nelle categorie seguenti:
- Errori del terminale
- Errori temporanei
- Errori durevoli
Il codice di errore della risposta HTTP determina il modo in cui Azure DevOps classifica l'errore.
Errori del terminale
L'unico codice di stato HTTP classificato come errore del terminale è 410 (Gone).
Quando si verifica un errore del terminale in una sottoscrizione, la sottoscrizione viene disabilitata automaticamente indipendentemente dallo stato precedente.
Errori temporanei
Le risposte HTTP con i codici di stato seguenti sono classificate come errori temporanei:
- 408 (Timeout richiesta)
- 502 (Gateway non valido)
- 503 (Servizio non disponibile)
- 504 (Timeout del gateway)
Quando si verifica un errore temporaneo in una sottoscrizione, Azure DevOps tenta di inviare nuovamente la notifica fino a otto volte, con un ritardo crescente tra ogni tentativo.
Nella tabella seguente sono elencate le informazioni sui tentativi tentati dopo un errore temporaneo. Incluso è il tempo di backoff approssimativo o il tempo di attesa prima di tentare di inviare di nuovo una notifica. Il tempo massimo di backoff è di 60 secondi. La tabella mostra anche il ritardo totale per ogni tentativo.
| Numero di ripetizioni | Tempo di backoff in secondi | Ritardo totale in secondi |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 3 |
| 3 | 4 | 7 |
| 4 | 8 | 15 |
| 5 | 16 | 31 |
| 6 | 32 | 63 |
| 7 | 60 | 123 |
| 8 | 60 | 183 |
Se tutti i tentativi per una notifica vengono esauriti e ogni tentativo genera un errore temporaneo, la notifica non viene più inviata. Viene invece categorizzato come un errore permanente.
Errori durevoli
Tutti gli altri codici di errore HTTP, ad esempio 404 (Non trovato) e 500 (errore interno del server), generano errori durevoli.
Quando si verifica un errore permanente in una sottoscrizione, la sottoscrizione viene inserita in prova.
Libertà vigilata
Quando una sottoscrizione è in prova, eventuali nuovi eventi vengono persi. Il sistema effettua un numero limitato di tentativi di inviare nuovamente la notifica non riuscita.
Nella tabella seguente sono elencati i tempi di backoff approssimativi e i tempi totali di rinvio per i tentativi effettuati durante il periodo di prova. Al massimo vengono effettuati sette tentativi e il tempo massimo di backoff per un tentativo di riprova è di 15 ore.
| Numero di ripetizioni | Tempo di backoff | Tempo totale di prova in ore |
|---|---|---|
| 1 | 20 minuti | 0.33 |
| 2 | 40 minuti | 1 |
| 3 | 1 ora 20 minuti | 2.33 |
| 4 | 2 ore 40 minuti | 5 |
| 5 | 5 ore 20 minuti | 10,33 |
| 6 | 10 ore 40 minuti | 21 |
| 7 | 15 ore | 36 |
Se la sottoscrizione riceve una risposta con esito positivo durante il periodo di prova, viene ripristinata in uno stato completamente abilitato e gli eventi vengono nuovamente pubblicati. Se tutti e sette i tentativi hanno esito negativo, lo stato della sottoscrizione viene impostato su DisabledBySystem.
Domande frequenti
Qual è il limite di payload di un service hook?
A: Il limite del carico utile è di 2 MB. I payload più grandi causano riduzioni di prestazioni e affidabilità. Come procedura consigliata, gli hook del servizio devono limitare il payload a 2 MB.
D: Cosa significa lo stato Abilitato (con restrizioni) ?
A: Se si verificano troppi fallimenti, una sottoscrizione viene limitata. Essere nello stato Abilitato (con restrizioni) equivale a essere in fase di probe.
D: Cosa significa lo stato Disabilitato (a causa di errori)
A: Una sottoscrizione viene disabilitata automaticamente nei casi seguenti:
- Si verifica un errore del terminale.
- Una serie di errori consecutivi si verifica in un periodo prolungato.
Le notifiche che causano errori temporanei vengono ritentate più volte prima di essere dichiarate errori permanenti. Le notifiche di errore durature vengono ripetute un numero limitato di volte durante il periodo di prova. Se tutti i tentativi di prova hanno esito negativo, la sottoscrizione viene disabilitata.
I codici di stato seguenti forniscono esempi di ogni tipo di errore:
- Temporaneo: 408 (timeout richiesta), 502 (gateway non valido), 503 (servizio non disponibile), 504 (timeout del gateway)
- Terminale: 410 (Non Disponibile)
- Permanenti: tutti gli errori che non sono temporanei o terminali
D: Cosa significa lo stato Disabilitato (progetto lasciato dall'utente)
Un: L'utente che ha creato la sottoscrizione non è più membro del team.
D: Cosa è consigliabile provare se un hook del servizio non funziona?
Un: Controllare gli elementi seguenti:
- Verificare che la sottoscrizione sia abilitata.
- Verificare che le impostazioni della sottoscrizione siano corrette. Controllare i filtri e le azioni degli eventi.
- Esaminare la cronologia, soprattutto in caso di errori.
D: È possibile concedere a un utente normale del progetto la possibilità di visualizzare e gestire le sottoscrizioni hook del servizio per un progetto?
Un: Per impostazione predefinita, solo gli amministratori del progetto dispongono di queste autorizzazioni. Per concederli direttamente ad altri utenti, è possibile usare lo strumento da riga di comando o l'API REST di Sicurezza.
D: È possibile creare sottoscrizioni a livello di codice?
Un: Sì, usare le API REST.