Partilhar via

Solucionar problemas de ganchos de serviço

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

Este artigo oferece orientações gerais de solução de problemas para ganchos de serviço do 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.

    Captura de ecrã da página Ganchos de Serviço a mostrar o estado, estado e outros dados das subscrições. As configurações do projeto e os ganchos de serviço são realçados.

  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.

    Captura de tela que mostra o histórico de uma assinatura, com informações detalhadas de um evento com falha, como status, mensagem e mensagem de erro.

Falhas de subscrição e liberdade condicional (restrita)

Se a resposta HTTP a uma solicitação de notificação indicar um erro, a gravidade da falha determinará como o Azure DevOps responderá. 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 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 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 repetição 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 repetição 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 exemplo seguinte para o Copilot Chat ajuda o Copilot a solucionar o seu código de erro e mensagem. Copie e cole esse prompt no Copilot Chat, substituindo o espaço reservado 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.

  • Last updated on