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.
servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Questo articolo offre indicazioni generali sulla risoluzione dei problemi per gli hook di servizio di 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 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 come Azure DevOps classifica il fallimento.
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, perde tutti i nuovi eventi. Il sistema effettua un numero limitato di tentativi di inviare nuovamente la notifica non riuscita.
La tabella seguente elenca i tempi di backoff approssimativi e i tempi totali di probation per i nuovi tentativi effettuati dal sistema durante il periodo di probation. Il sistema effettua al massimo sette tentativi e il tempo massimo di backoff per un nuovo tentativo in periodo di prova è 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, il sistema la ripristina a uno stato pienamente abilitato e riprende a pubblicare eventi. Se tutti e sette i tentativi hanno esito negativo, il sistema imposta lo stato della sottoscrizione su DisabledBySystem.
Sottoscrizioni disabilitate a causa dell'inattività
Azure DevOps disabilita automaticamente un abbonamento quando l’ultima notifica recapitata correttamente risale a più di sei mesi fa. La sottoscrizione interrompe la ricezione di eventi fino a quando un utente non lo abilita nuovamente.
Questo controllo di inattività considera solo l'ultima consegna riuscita. Non viene considerato quando la sottoscrizione è stata creata o l'ultima modifica o il numero di eventi corrispondenti alla sottoscrizione. Una sottoscrizione che continua a recapitare correttamente le notifiche non viene disabilitata a causa dell'inattività, indipendentemente dalla sua età. Una sottoscrizione senza consegne riuscite registrate non è interessata dal controllo dell'inattività.
Usare l'intelligenza artificiale per risolvere i problemi relativi a un hook del servizio
Il seguente prompt di esempio per Copilot Chat consente a Copilot di risolvere il codice di errore e il messaggio. Copiare e incollare questa richiesta in Copilot Chat, sostituendo il segnaposto con il messaggio di errore specifico.
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.
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: Perché una sottoscrizione può diventare disabilitata?
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.
- L’ultima consegna riuscita della notifica risale a più di sei mesi fa.
- L'utente che ha creato la sottoscrizione non è più membro del team.
D: Cosa significa lo stato Disabilitato (a causa di errori)
R: 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 (a causa dell'inattività)
R: L'ultima consegna riuscita di una notifica della sottoscrizione risale a più di sei mesi fa, quindi Azure DevOps l'ha disabilitata. Questo stato è diverso da Disabled (a causa di errori), il che significa che Azure DevOps ha tentato il recapito e che il recapito non è andato a buon fine più volte. Riabilitare la sottoscrizione se l'integrazione è ancora necessaria.
D: Perché le sottoscrizioni inattive sono disabilitate?
R: Azure DevOps valuta ogni sottoscrizione quando viene pubblicato un evento corrispondente, anche quando l'integrazione ricevente non è più attiva. Nel corso del tempo, le organizzazioni possono accumulare sottoscrizioni inattive quando le pipeline vengono ritirate e le integrazioni vengono abbandonate. Alcune organizzazioni hanno decine di migliaia di sottoscrizioni che non hanno recapitato notifiche in anni. La disabilitazione delle sottoscrizioni inattive consente di mantenere gli hook di servizio veloci e affidabili per le sottoscrizioni ancora in uso.
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, usa lo strumento da riga di comando o l'API REST Security.
D: È possibile creare sottoscrizioni a livello di codice?
Un: Sì, usare le API REST.