# Estandar y formato para logs de automation

## Log level:
- info:
- Http query ejecutada correctamente
- Corroboración de etapa de proceso ejecutada correctamente
- warn:
- Errores en la validación de una query http
- error
- Errores en la llamada http de un usuario
- Errores en la ejecución de un proceso.

## Proceso de error
- ¿Cómo sería el proceso de un error?
- recibir una alarma
- Diagnóstico:
- Qué gatilló el proceso?
- Interacción con un usuario
- Ejecución de un proceso a través de la cli.
- Qué proceso falló?
- En qué etapa del proceso falló?
- Reproducción:
- Obtener los argumentos de la acción desde logs
- Explicar por qué se produjo el error
- Resolución:
- Demostrar que con los mismo argumentos, no ocurre el error.
- Resolver el proceso que anteriormente dio el error.

# Estándar
- basicLogger:
- Los logs deben estar formateados solamente cuando se leen por consola, cuando se escribe en los archivos no debe tener formateo especial.
- El archivo utilizado para loggear debe estar sin comprimir, los archivos que alcanzaron su máximo, deben comprimirse.
- Api:
- Se debe configurar una alarma en elastic por cualquier error que ocurra en el servidor de automation.
- Debe existir un log sobre el acceso de la api llamado: access.log que utiliza el middleware accesslogger donde se imprimirá cada llamada a la api, su timestamp, loglevel, url, body, codigo de respuesta y su tiempo de respuesta.
- Cuando no se cumple el schema, debe tener el log.level: 'warn' type: 'schema'
- Procesos:
- Cada Proceso debe generar su propio archivo de logs (ej: /logs/createNewEquip.log, /logs/createDeploymentServer.log) y cada log debe ser enviado a elastic
- Cada proceso debe definir sus "etapas" como un log con un valor de 'info' para notificar a su log de su correcta ejecución.
- Definir los potenciales errores con valor 'error'.

- dbConnectionErrors:
- Mantener los Errores de conexión a la BD