Pruebas y resolución de problemas - Mattermost
El mensaje de prueba
Junto a cada tipo de evento hay un botón Enviar prueba. Publica un mensaje de ejemplo con el nombre del proyecto, el tipo de evento y la hora de detección, por el mismo camino que una alerta real. La prueba necesita una dirección de webhook guardada o recién introducida y un canal elegido. Si falta alguno de los dos, termina con un mensaje de configuración incompleta antes de que DockRay intente siquiera enviar la petición.
Problemas habituales
DockRay rechaza la dirección al guardar
La dirección debe ser HTTPS pública, sin usuario ni contraseña incrustados en ella, y el nombre de host debe resolver a una dirección IP pública. Una dirección HTTP, una interna (por ejemplo, un servidor Mattermost tras una IP privada sin proxy público) o una errata en el dominio terminan todas en el mismo mensaje: es una única regla compartida para cualquier campo de este tipo en el panel, no una validación específica de Mattermost.
La prueba pasa, pero las alertas reales no llegan
Revisa el enrutamiento de ese tipo de evento en concreto: puede estar en 'no enviar', o el proyecto puede haber sobrescrito explícitamente la herencia de la cuenta solo con un canal, sin activar el envío. También conviene comprobar si el evento llegó a producirse: issue solo se dispara en la primera aparición de un error nuevo.
El webhook funcionaba y desde hace un tiempo está en silencio
Alguien puede haber eliminado el webhook en el lado de Mattermost, por ejemplo al hacer limpieza de las integraciones del servidor o tras un cambio de administrador del canal. DockRay no tiene forma de saberlo por sí solo: un webhook eliminado simplemente deja de responder. Crea uno nuevo y colócalo en lugar del antiguo.
El mensaje llega a un canal distinto del esperado
Mattermost permite que un webhook publique en un canal distinto de aquel para el que se creó, si DockRay indica el canal explícitamente en la petición. Si el campo del canal está vacío en el enrutamiento, el mensaje va al canal por defecto del webhook, el que se usó al crearlo, no el que parecía 'obvio' por el nombre de la integración.
Un aumento repentino de errores no envía notificación
El criterio de error-spike exige a la vez un número mínimo de eventos en la ventana de tiempo y un múltiplo suficiente del tráfico normal de ese proyecto, y este tipo de alerta se envía para el mismo proyecto como mucho una vez cada varias horas: una segunda oleada en un margen corto se silencia a propósito.
Sigue sin funcionar
Repasa la lista de comprobación de falta de datos y, si no ayuda, escríbenos. Indica el nombre del proyecto, la versión de la integración y la hora aproximada de la prueba: acorta el camino a la respuesta.