3. Identificando opciones de Logging en Mule


Ya sea en Cloudhub o en otro modelo de despliegue, contar con un buen sistema de logging es vital al desarrollar una aplicación. El poder identificar qué está sucediendo, ya sea un error o un proceso estándar, es clave para el éxito y la estabilidad de tus aplicaciones Mule.

 

Logging en Mulesoft

  • ¿Para qué sirve? Facilita el depurar y rastrear lo que sucede en tus aplicaciones de Mule, proporcionando detalles de los eventos que ocurren durante su procesamiento.
  • Niveles de Log:
    • DEBUG: Para información detallada, útil durante la depuración.
    • INFO: Confirmaciones de que las cosas están funcionando como se esperaba.
    • WARN: Para indicar que ha sucedido algo inesperado, o podría suceder un problema en el futuro.
    • ERROR: Para señalar errores graves que han ocurrido.
  • Appenders: Son los destinos a donde se envían tus logs. Pueden ser la consola del sistema, un archivo, una base de datos, el servicio de logging de CloudHub o incluso otro servidor o servicio. Esta parte se configura en el archivo log4j2.xml y es necesario crearla en la aplicación, puedes obtener el formato oficial aquí
  • Por defecto: Las rutinas de Mule muestran el nivel de log INFO, así que los mensajes de DEBUG o TRACE normalmente no se registran a menos que se configure de otra manera.

Origen de los logs

En MuleSoft, tanto en ambientes CloudHub como customer-hosted, los System Logs y los Application Logs desempeñan roles distintos pero complementarios en la observabilidad y el diagnóstico de las aplicaciones:

  • System Log: Registra eventos relacionados con el Mule runtime. Esto incluye información sobre el inicio y la parada del runtime, así como alertas sobre el estado general del entorno en el que corre la aplicación de Mule. Piensa en el System Log como el diario de salud y estado del entorno de ejecución de Mule.
  • Application Log: Captura todo lo que sucede dentro de una aplicación Mule específica. Este log incluirá los mensajes que los desarrolladores han decidido registrar, que pueden ir desde seguimiento de errores hasta confirmaciones de que ciertas acciones se completaron con éxito. El Application Log es más específico y detallado respecto a las operaciones y el flujo de datos dentro de tu aplicación.

Logs en MuleSoft: CloudHub vs Customer-Hosted

CloudHub

  • System Log
    • Propósito: Registra el ciclo de vida del runtime de Mule.
    • Configuración: log4j2.xml no modificable por el cliente.
    • Contenido: Mensajes de estado del runtime y de la aplicación.
  • Application Log
    • Propósito: Se enfoca en la aplicación Mule.
    • Configuración: log4j2.xml incluido en la aplicación, personalizable.
    • Contenido: Mensajes generados por la aplicación, incluyendo System.out.

Customer-Hosted

  • System Log
    • Propósito: Igual que en CloudHub, pero con capacidad de configuración limitada para el cliente.
    • Contenido: Incluye mensajes sobre despliegues de dominio de Mule.
  • Application Log
    • Propósito y Configuración: Igual que en CloudHub, con pleno acceso para personalización.
    • Contenido: Igual que en CloudHub.

Diferencias Clave entre Customer-Hosted  y CloudHub

CloudHub trunca los mensajes de log a:

      • 100 MB por aplicación Mule y por worker.
      • 30 días como máximo.

Configuración de log4j2.xml en CloudHub:

  • El archivo se encuentra en el proyecto de la aplicación en la ruta src/main/resources por defecto.
  • La configuración de este archivo es ignorada a menos que actives la opción «Disable CloudHub Logs».
  • Por defecto no se permite desactivar los logs de CloudHub, por lo que la configuración de log4j2.xml que hagas localmente no tendrá efecto en ese entorno. Es necesario solicitar a Mulesoft que habiliten la opción si quieres enviar los logs a otro destino que hayas configurado en el appender.

 

Acceso y Control: Mayor en customer-hosted; puedes modificar src/main/resources/log4j2.xmlque se encuentra en el proyecto de la aplicación.

Personalización: En customer-hosted, la personalización es más profunda debido al acceso al archivo de configuración.

Separación de Logs: En ambos ambientes hay una distinción entre los logs del sistema y los de la aplicación, pero en customer-hosted, el nivel de detalle y control es superior.

 

Logging síncrono vs asíncrono

Logging Síncrono

  • Cómo Funciona: Cada vez que se genera un log, el thread (hilo de ejecución) que está procesando tu mensaje se detiene hasta que el mensaje de log se ha registrado completamente.
  • Impacto en Rendimiento: Este método puede hacer que tu aplicación sea más lenta porque espera a que el log se complete antes de continuar.
  • Uso Recomendado: Es ideal para llevar una traza de auditoría o cuando es crucial registrar errores o mensajes críticos, ya que asegura que la información importante no se pierda.

logger synch

Logging Asíncrono (por Defecto)

  • Cómo Funciona: Los logs se escriben en un thread separado, lo que permite que el procesamiento de tu mensaje continúe sin esperar a que el log se complete.
  • Beneficios: Mejora significativa en el rendimiento y la latencia del procesamiento de mensajes, ya que no interrumpe el flujo principal de ejecución.
  • Consideraciones: Existe el riesgo de que los logs se pierdan si el sistema se cae antes de que hayan sido escritos definitivamente.

logger asynch alternativo

En MuleSoft, la práctica recomendada es usar logging asíncrono para maximizar la eficiencia y el rendimiento. Sin embargo, para casos críticos donde se necesita una traza exacta de eventos, como en auditorías o manejo de errores graves, el logging síncrono es la opción adecuada

 

Conclusión

La elección entre logging síncrono y asíncrono depende de tus necesidades de auditoría y rendimiento. En MuleSoft, la eficiencia y rapidez son claves, por lo que el logging asíncrono suele ser la opción preferida. Sin embargo, para seguimiento detallado de errores o auditorías, el logging síncrono es indispensable. Asegúrate de configurar tus logs de manera que apoyen el éxito de tus aplicaciones Mule de la mejor manera posible.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *