Solucionar problemas de ganchos de serviço

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.

1. Para ver a atividade e o estado das suas subscrições, aceda à página Ganchos de Serviço.

   

2. 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.

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 período probatório, perde quaisquer novos eventos. O sistema faz um número limitado de tentativas para reenviar a notificação com falha.

A tabela seguinte apresenta os intervalos de espera aproximados e os tempos totais do período de observação para as novas tentativas que o sistema efetua durante esse período. O sistema tenta, no máximo, sete tentativas, e o tempo máximo de recuo para uma nova tentativa em liberdade condicional é de 15 horas.

Se a subscrição receber uma resposta bem-sucedida durante o período de experiência, o sistema restaura-a para um estado totalmente habilitado e publica novamente os eventos. Se todas as sete tentativas falharem, o sistema define o estado da subscrição para DisabledBySystem.

Subscrições desativadas devido à inatividade

O Azure DevOps desativa automaticamente uma subscrição quando a entrega de notificações bem-sucedida mais recente foi há mais de seis meses. A subscrição deixa de receber eventos até que o utilizador a volte a ativar.

Esta verificação de inatividade considera apenas a última entrega bem-sucedida. Não considera quando a subscrição foi criada ou editada pela última vez, nem quantos eventos corresponderam à subscrição. Uma subscrição que continua a entregar notificações com sucesso não é desativada por inatividade, independentemente da sua idade. Uma subscrição sem entregas registadas e bem-sucedidas não é afetada pela verificação de inatividade.

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: Porque é que uma subscrição pode ficar desativada?

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.
• A entrega de notificações bem-sucedida mais recente foi há mais de seis meses.
• O utilizador que criou a subscrição já não faz parte da equipa.

P: O que significa o estado Desativado (devido a falhas)?

R: 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 de Deficiente (devido à inatividade)?

R: A última entrega bem-sucedida de notificações da subscrição ocorreu há mais de seis meses, pelo que o Azure DevOps a desativou. Este estado difere de Desabilitado (devido a falhas), o que significa que o Azure DevOps tentou entregar e a entrega falhou repetidamente. Reative a subscrição se a integração ainda for necessária.

P: Porque é que as subscrições inativas estão desativadas?

R: O Azure DevOps avalia todas as subscrições quando um evento correspondente é publicado, mesmo quando a integração de receção já não está ativa. Com o tempo, as organizações podem acumular subscrições inativas à medida que os pipelines são desativados e as integrações são abandonadas. Algumas organizações têm dezenas de milhares de subscrições que não recebem notificações há anos. Desativar subscrições inativas ajuda a manter os ganchos de serviço rápidos e fiáveis para subscrições que ainda estão em uso.

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 os conceder diretamente a outros utilizadores, utilize a ferramenta de linha de comandos ou a API Security REST.

P: Posso criar subscrições programaticamente?

R: Sim, use APIs de REST.

Conteúdo relacionado

• Visão geral dos ganchos de serviço
• Crie uma subscrição de gancho de serviço
• Todos os guias de resolução de problemas e perguntas frequentes