Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
En este artículo se ofrecen instrucciones generales de solución de problemas para los enlaces de servicio de Azure DevOps. También proporciona respuestas a las preguntas más frecuentes (PF).
Ver actividad y depurar problemas
La página Service Hooks del administrador de acceso web resume la actividad de los últimos siete días para cada suscripción. La página también muestra si cada suscripción está habilitada, deshabilitada o restringida.
Para cada suscripción, puede acceder a un historial detallado que incluya los datos completos de solicitud y respuesta para cada evento. Esta información puede ayudarle a depurar un servicio o una suscripción problemáticos.
Para ver la actividad y el estado de las suscripciones, vaya a la página Enlaces de servicio .
Para ver la actividad detallada de una suscripción, incluidos los datos completos de solicitud, respuesta y carga de eventos, seleccione una suscripción en la tabla y, a continuación, seleccione Historial.
Errores de suscripción y período de prueba (restringido)
Si la respuesta HTTP a una solicitud de notificación indica un error, la gravedad del error determina cómo responde Azure DevOps. Ciertos tipos de errores pueden deshabilitar las suscripciones o ponerlas en período de prueba.
Tipos de error
Los errores de las notificaciones de enlace de servicio se agrupan en las siguientes categorías:
- Errores de terminal
- Errores transitorios
- Errores duraderos
El código de error de la respuesta HTTP determina cómo Azure DevOps clasifica el error.
Errores de terminal
El único código de estado HTTP que se clasifica como un error de terminal es 410 (Desaparecido).
Cuando se produce un error de terminal en una suscripción, la suscripción se deshabilita automáticamente independientemente de su estado anterior.
Errores transitorios
Las respuestas HTTP con los siguientes códigos de estado se clasifican como errores transitorios:
- 408 (Tiempo de espera de solicitud agotado)
- 502 (Error de puerta de enlace)
- 503 (Servicio no disponible)
- 504 (Tiempo de espera de puerta de enlace)
Cuando se produce un error transitorio en una suscripción, Azure DevOps intenta volver a enviar la notificación hasta ocho veces, con un retraso creciente entre cada intento.
En la tabla siguiente se muestra información sobre los reintentos que se intentan después de que se produzca un error transitorio. Incluido es el tiempo de retroceso aproximado o el tiempo de espera antes de intentar volver a enviar una notificación. El tiempo de retroceso máximo es de 60 segundos. La tabla también muestra el retraso total de cada reintento.
| Número de reintentos | Tiempo de retroceso en segundos | Retraso total en 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 |
Si se agotan todos los reintentos de una notificación y cada intento produce un error transitorio, la notificación ya no se envía. En su lugar, se clasifica como una falla persistente.
Errores duraderos
Todos los demás códigos de error HTTP, por ejemplo, 404 (no encontrado) y 500 (error interno del servidor), producen errores duraderos.
Cuando se produce un error perdurable en una suscripción, la suscripción se coloca en período de prueba.
Suspensión de la condena
Cuando una suscripción está en período de prueba, se pierden todos los eventos nuevos. El sistema realiza un número limitado de intentos para volver a enviar la notificación con errores.
En la tabla siguiente se enumeran los tiempos de espera aproximados y los tiempos totales del periodo de prueba para los reintentos que realiza el sistema durante dicho periodo. El sistema intenta como máximo siete reintentos y el tiempo de retroceso máximo para un reintento de prueba es de 15 horas.
| Número de reintentos | Tiempo de retroceso | Tiempo total de libertad condicional en 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 | Veintiuno |
| 7 | 15 horas | 36 |
Si la suscripción recibe una respuesta correcta durante la prueba, el sistema lo restaura a un estado totalmente habilitado y vuelve a publicar eventos. Si se produce un error en los siete reintentos, el sistema establece el estado de la suscripción en DisabledBySystem.
Suscripciones deshabilitadas debido a inactividad
Azure DevOps deshabilita automáticamente una suscripción cuando la entrega de notificaciones más reciente se realizó hace más de seis meses. La suscripción deja de recibir eventos hasta que un usuario vuelve a habilitarlo.
Esta comprobación de inactividad solo tiene en cuenta la última entrega realizada correctamente. No tiene en cuenta cuándo se creó o editó por última vez la suscripción o cuántos eventos coinciden con la suscripción. Una suscripción que sigue entregando notificaciones correctamente no está deshabilitada debido a la inactividad, independientemente de su antigüedad. Una suscripción sin entregas correctas registradas no se ve afectada por la comprobación de inactividad.
Uso de IA para solucionar problemas de un hook de servicio
El siguiente mensaje de ejemplo de Copilot Chat ayuda a Copilot a solucionar tu código de error y mensaje. Copie y pegue este mensaje en Copilot Chat, reemplazando el marcador de posición por su mensaje de error específico.
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.
Preguntas más frecuentes
P: ¿Cuál es el límite de carga de un enlace de servicio?
A: El límite de carga útil es de 2 MB. Las cargas más grandes provocan una degradación del rendimiento y la confiabilidad. Como procedimiento recomendado, los enlaces de servicio deben limitar la carga a 2 MB.
P: ¿Qué significa el estado Habilitado (restringido)?
A: Una suscripción se restringe si se producen demasiados fallos. Estar en el estado Habilitado (restringido) es el mismo que estar en libertad condicional.
P: ¿Por qué se puede deshabilitar una suscripción?
Una: Una suscripción se desactiva automáticamente en los siguientes casos:
- Se produce una falla terminal.
- Se produce una serie de errores consecutivos durante un período prolongado.
- La última entrega de notificaciones realizada con éxito se produjo hace más de seis meses.
- El usuario que creó la suscripción ya no es miembro del equipo.
P: ¿Qué significa el estado Deshabilitado (debido a errores)?
R: Las notificaciones que producen errores transitorios se reintentan varias veces antes de declarar errores duraderos. Las notificaciones de error duraderas se reintentan un número limitado de veces durante el periodo de prueba. Si fallan todos los intentos durante el periodo de prueba, la suscripción se desactiva.
Los códigos de estado siguientes proporcionan ejemplos de cada tipo de error:
- Transitorio: 408 (tiempo de espera de solicitud), 502 (puerta de enlace incorrecta), 503 (servicio no disponible), 504 (tiempo de espera de puerta de enlace)
- Terminal: 410 (desaparecido)
- Perdurable: todos los errores que no son transitorios o terminales
P: ¿Qué significa el estado Deshabilitado (debido a la inactividad)?
R: La última entrega correcta de notificaciones de la suscripción se realizó hace más de seis meses, por lo que Azure DevOps la deshabilitó. Este estado difiere de Deshabilitado (debido a fallos), lo que significa que Azure DevOps intentó realizar la entrega y esta falló repetidamente. Vuelva a habilitar la suscripción si la integración sigue siendo necesaria.
P: ¿Por qué están deshabilitadas las suscripciones inactivas?
R: Azure DevOps evalúa cada suscripción cuando se publica un evento coincidente, incluso cuando la integración receptora ya no está activa. Con el tiempo, las organizaciones pueden acumular suscripciones inactivas a medida que se retiran las canalizaciones y se abandonan las integraciones. Algunas organizaciones tienen decenas de miles de suscripciones que no entregaron notificaciones en años. Deshabilitar las suscripciones inactivas ayuda a mantener los enlaces de servicio rápidos y confiables para las suscripciones que todavía están en uso.
P: ¿Qué significa el estado Deshabilitado (usuario abandonó el proyecto)?
Un: El usuario que creó la suscripción ya no es miembro del equipo.
P: ¿Qué debo probar si un enlace de servicio no funciona?
A: Compruebe los siguientes elementos:
- Confirme que la suscripción está habilitada.
- Confirme que la configuración de la suscripción es correcta. Compruebe los filtros de eventos y las acciones.
- Examine el historial, especialmente si hay errores.
P: ¿Puedo conceder a un usuario de proyecto normal la capacidad de ver y administrar suscripciones de enlace de servicio para un proyecto?
A: De forma predeterminada, solo los administradores del proyecto tienen estos permisos. Para concedérselos directamente a otros usuarios, utilice la herramienta de línea de comandos o la API de REST de Seguridad.
P: ¿Puedo crear suscripciones mediante programación?
A: Sí, use las API REST.