Entender el resultado de una corrida¶
Código de salida¶
Todos los jobs migrados usan el mismo esquema:
| Código | Significado | Qué hacer |
|---|---|---|
| 0 | Terminó bien | Nada |
| 1 | Falló la ejecución (base de datos, SFTP, API, auditoría, etc.) | Leer el log y el runbook del job; corregir y relanzar |
| 2 | Configuración o argumentos inválidos (por ejemplo, falta una variable) | Revisar los secretos del job o los argumentos usados |
| 127 | El panel no encontró el comando del job | Revisar que el comando empiece por /opt/dabra/bin/dabra-job |
El panel también cierra una corrida que supera su timeout (JOB_TIMEOUT) o que quedó cortada por un reinicio (RUN_INTERRUPTED).
Auditoría¶
La mayoría de los jobs deja una fila en ods.tbl_control_procesos con su identificador, el estado (Success o Error) y la cantidad de registros. El panel la contrasta con el resultado de la corrida:
- corrida OK pero sin fila 10 minutos después →
AUDIT_MISSING; - fila con
Errorpero código de salida 0 →AUDIT_ERROR(el script ocultó una excepción).
Logs¶
- En el panel: job → historial de corridas → log de esa corrida (se puede descargar).
- En el servidor: la carpeta de logs montada en el contenedor, con una subcarpeta por job y un archivo por corrida (
<job>/<fecha_hora>.log). - Los jobs están hechos para no registrar contraseñas ni tokens; si ves alguno en un log, repórtalo y rota esa credencial.
Datos y archivos de un job¶
Cada job guarda lo que genera en /var/lib/dabra/<job>/: carpetas de entrada, temporales, salida (output/) y copias de lo enviado (archive/). Si un envío falla, los archivos suelen quedar en output/ para poder reenviarlos.