Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Este artigo oferece diretrizes gerais de solução de problemas para ganchos de serviço do Azure DevOps. Ele também fornece respostas para perguntas frequentes (perguntas frequentes).
Visualizar atividade e depurar problemas
A página Service Hooks 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 exibir a atividade e o status de suas assinaturas, vá para a página Service Hooks.
Para exibir a atividade detalhada de uma assinatura, incluindo dados completos de solicitação, resposta e conteúdo do evento, selecione uma assinatura na tabela e selecione Histórico.
Falhas de assinatura e avaliação (restrito)
Se a resposta HTTP a uma solicitação de notificação indicar um erro, a gravidade da falha determinará como o Azure DevOps responde. Certos tipos de falhas podem desabilitar assinaturas ou colocá-las em avaliação.
Tipos de falha
Falhas de notificações de gancho de serviço são agrupadas nas seguintes categorias:
- Falhas de terminal
- Falhas temporárias
- Falhas duradouras
O código de erro da resposta HTTP determina como o Azure DevOps categoriza a falha.
Falhas de terminal
O único código de status HTTP categorizado como uma falha de terminal é 410 (desaparecido).
Quando ocorre uma falha de terminal em uma assinatura, a assinatura é desabilitada automaticamente, independentemente do estado anterior.
Falhas temporárias
As respostas HTTP com os seguintes códigos de status são categorizadas como falhas transitórias:
- 408 (Tempo limite da solicitação)
- 502 (Gateway inválido)
- 503 (Serviço Indisponível)
- 504 (Tempo limite do gateway)
Quando ocorre uma falha transitória em uma assinatura, 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 realizadas após a ocorrência de uma falha transitória. Incluído é o tempo de retirada aproximado ou o tempo de espera antes de tentar reenviar uma notificação. O tempo máximo de retirada é de 60 segundos. A tabela também mostra o atraso total para cada repetição.
| Número de Repetições | Tempo de espera em segundos | Atraso total em segundos |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 3 |
| 3 | 4 | 7 |
| 4 | oito | 15 |
| 5 | 16 | 31 |
| 6 | 32 | 63 |
| 7 | 60 | 123 |
| oito | 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. Ao invés disso, é classificado como uma falha persistente.
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 avaliação.
Avaliação
Quando uma assinatura está em período de avaliação, qualquer evento novo é perdido. O sistema faz um número limitado de tentativas de reenviar a notificação com falha.
A tabela a seguir lista os tempos aproximados de espera e os tempos totais de experiência para novas tentativas feitas durante a avaliação. São feitas no máximo sete tentativas, e o tempo máximo de espera para uma nova tentativa de avaliação é de 15 horas.
| Número de Repetições | Tempo de retirada | Tempo total de liberdade condicional em horas |
|---|---|---|
| 1 | 20 minutos | 0.33 |
| 2 | 40 minutos | 1 |
| 3 | 1 hora e 20 minutos | 2.33 |
| 4 | 2 horas e 40 minutos | 5 |
| 5 | 5 horas e 20 minutos | 10.33 |
| 6 | 10 horas e 40 minutos | 21 |
| 7 | 15 horas | 36 |
Se a assinatura receber uma resposta bem-sucedida durante a avaliação, 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.
Usar IA para solucionar problemas de um gancho de serviço
O seguinte prompt de exemplo para o Copilot Chat auxilia o Copilot na resolução de problemas relacionados a códigos de erro e mensagens. Copie e cole esse prompt no Copilot Chat, substituindo o espaço reservado por 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 de um gancho de serviço?
R: O limite de conteúdo é de 2 MB. Cargas maiores causam degradação no desempenho e na confiabilidade. Como prática recomendada, os ganchos de serviço devem limitar o conteúdo a 2 MB.
P: O que significa o estado Habilitado (restrito)?
A: Uma assinatura fica restrita se ocorrerem muitas falhas. Estar no estado habilitado (restrito) é o mesmo que estar em liberdade condicional.
P: O que significa o estado desabilitado (devido a falhas) ?
A: Uma assinatura é desabilitada automaticamente nos seguintes casos:
- Ocorreu uma falha de terminal.
- Uma série de falhas consecutivas ocorre durante um período prolongado.
Notificações que resultam em falhas transitórias são repetidas várias vezes antes de serem declaradas falhas duradouras. Notificações de falha duradouras são tentadas novamente um número limitado de vezes durante o período de avaliação. Se todas as tentativas de ativação falharem, a assinatura fica desativada.
Os seguintes códigos de status fornecem exemplos de cada tipo de falha:
- Transitório: 408 (tempo limite da solicitação), 502 (gateway inválido), 503 (serviço indisponível), 504 (tempo limite do gateway)
- Terminal: 410 (desaparecido)
- Duradouro: todas as falhas que não são transitórias ou terminais
P: O que significa o estado Desabilitado (usuário deixou o projeto)?
A: 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?
A: Verifique os seguintes itens:
- Confirme se a assinatura está habilitada.
- Confirme se as configurações de assinatura estão corretas. Verifique filtros de eventos e ações.
- Examine o histórico, especialmente se houver falhas.
P: Posso conceder a um usuário de projeto regular a capacidade de exibir e gerenciar assinaturas de gancho de serviço para um projeto?
Um: Por padrão, somente 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 assinaturas programaticamente?
R: Sim, use APIs REST.