Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Azure DevOps Serviços | Azure DevOps Server | Azure DevOps Server 2022
Este artigo oferece orientações gerais para resolução de problemas para ganchos de serviço Azure DevOps. Também fornece respostas a perguntas frequentes (FAQs).
Ver atividade e depurar problemas
A página Ganchos de Serviço no administrador de acesso à Web resume a atividade dos últimos sete dias para cada assinatura. A página também mostra se cada assinatura está habilitada, desabilitada ou restrita.
Para cada assinatura, você pode acessar um histórico detalhado que inclui os dados completos de solicitação e resposta para cada evento. Essas informações podem ajudá-lo a depurar um serviço ou assinatura problemático.
Para ver a atividade e o estado das suas subscrições, aceda à página Ganchos de Serviço.
Para ver a atividade detalhada de uma subscrição, incluindo dados completos de pedido, resposta e carga útil de eventos, selecione uma subscrição na tabela e, em seguida, selecione Histórico.
Falhas de subscrição e liberdade condicional (restrita)
Se a resposta HTTP a um pedido de notificação indicar um erro, a gravidade da falha determina como o Azure DevOps responde. Certos tipos de falhas podem desativar assinaturas ou colocá-las em liberdade condicional.
Tipos de falha
As falhas das notificações de gancho de serviço são agrupadas nas seguintes categorias:
- Falhas no terminal
- Falhas transitórias
- Falhas duradouras
O código de erro da resposta HTTP determina como o Azure DevOps categoriza a falha.
Falhas no terminal
O único código de status HTTP que é categorizado como uma falha de terminal é 410 (Gone).
Quando ocorre uma falha de terminal numa subscrição, a subscrição é automaticamente desativada, independentemente do seu estado anterior.
Falhas transitórias
As respostas HTTP com os seguintes códigos de status são categorizadas como falhas transitórias:
- 408 (Tempo limite de solicitação)
- 502 (Gateway incorreto)
- 503 (Serviço indisponível)
- 504 (Tempo limite do gateway)
Quando ocorre uma falha transitória numa subscrição, o Azure DevOps tenta reenviar a notificação até oito vezes, com um atraso crescente entre cada tentativa.
A tabela a seguir lista informações sobre novas tentativas após a ocorrência de uma falha transitória. Está incluído o tempo de atraso aproximado, ou o tempo de espera antes de tentar reenviar uma notificação. O tempo máximo de backoff é de 60 segundos. A tabela também mostra o atraso total para cada nova tentativa.
| Número de tentativa | Tempo de recuo em segundos | Atraso total em segundos |
|---|---|---|
| 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 todas as novas tentativas de uma notificação forem esgotadas e cada tentativa resultar em uma falha transitória, a notificação não será mais enviada. Em vez disso, é categorizado como um fracasso duradouro.
Falhas duradouras
Todos os outros códigos de falha HTTP, por exemplo, 404 (Não encontrado) e 500 (Erro interno do servidor), resultam em falhas duradouras.
Quando ocorre uma falha duradoura em uma assinatura, a assinatura é colocada em suspensão.
Período de prova
Quando uma subscrição está em liberdade condicional, quaisquer novos eventos são perdidos. O sistema faz um número limitado de tentativas para reenviar a notificação com falha.
A tabela a seguir lista os tempos aproximados de backoff e os tempos totais de liberdade condicional para novas tentativas durante a liberdade condicional. No máximo sete tentativas são tentadas, e o tempo máximo de recuo para uma nova tentativa de liberdade condicional é de 15 horas.
| Número de tentativa | Tempo de recuo | Tempo total de liberdade condicional em horas |
|---|---|---|
| 1 | 20 minutos | 0,33 |
| 2 | 40 minutos | 1 |
| 3 | 1 hora 20 minutos | 2.33 |
| 4 | 2 horas 40 minutos | 5 |
| 5 | 5 horas 20 minutos | 10.33 |
| 6 | 10 horas 40 minutos | 21 |
| 7 | 15 horas | 36 |
Se a assinatura receber uma resposta bem-sucedida durante a liberdade condicional, ela será restaurada para um estado totalmente habilitado e os eventos serão publicados novamente. Se todas as sete tentativas falharem, o estado da assinatura será definido como DisabledBySystem.
Use IA para resolver problemas de um gancho de serviço
O seguinte prompt de exemplo para o Copilot Chat ajuda o Copilot a diagnosticar o seu código de erro e a sua mensagem. Copie e cole este prompt no Copilot Chat, substituindo o marcador de posição pela sua mensagem de erro específica.
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.
Perguntas frequentes
P: Qual é o limite de carga útil de um gancho de serviço?
R: O limite de carga útil é de 2 MB. Os payloads maiores resultam numa degradação no desempenho e na fiabilidade. Como prática recomendada, os ganchos de serviço devem limitar a carga útil a 2 MB.
P: O que significa o estado Ativado (restrito)?
R: Uma subscrição torna-se restrita se ocorrerem demasiadas falhas. Estar no estado Habilitado (restrito) é o mesmo que estar em liberdade condicional.
P: O que significa o estado Desativado (devido a falhas)?
A: Uma subscrição é automaticamente desativada nos seguintes casos:
- É encontrada uma falha terminal.
- Uma série de falhas consecutivas ocorre durante um período prolongado.
As notificações que resultam em falhas transitórias são repetidas várias vezes antes de serem declaradas falhas duradouras. As notificações de falhas duradouras são repetidas um número limitado de vezes durante o período de avaliação. Se todas as tentativas de liberdade condicional falharem, a assinatura será desativada.
Os códigos de status a seguir fornecem exemplos de cada tipo de falha:
- Transitório: 408 (tempo limite de solicitação), 502 (Bad Gateway), 503 (serviço indisponível), 504 (tempo de espera do Gateway)
- Terminal: 410 (Desaparecido)
- Duradouro: Todas as falhas que não são transitórias ou terminais
P: O que significa o estado Desativado (projeto deixado pelo usuário)?
R: O usuário que criou a assinatura não é mais um membro da equipe.
P: O que devo tentar se um gancho de serviço não estiver funcionando?
R : Verifique os seguintes itens :
- Confirme se a subscrição está ativada.
- Confirme se as configurações de assinatura estão corretas. Verifique os filtros e ações de eventos.
- Olhe para a história, especialmente se houver falhas.
P: Posso conceder a um(a) utilizador(a) regular do projeto a capacidade para visualizar e gerir assinaturas de webhooks para um projeto?
R: Por padrão, apenas os administradores de projeto têm essas permissões. Para concedê-los diretamente a outros usuários, você pode usar a ferramenta de linha de comando ou a API REST de segurança .
P: Posso criar subscrições programaticamente?
R: Sim, use APIs de REST.