• Articles
• admin

Obtener visibilidad de su aplicación es crucial al ejecutar su código en producción. ¿Qué entendemos por visibilidad? Principalmente cosas como el rendimiento de la aplicación a través de métricas, el estado de la aplicación y la disponibilidad, sus registros en caso de que necesite solucionar problemas, o sus rastros si necesita averiguar qué lo hace lento y cómo hacerlo más rápido. Las métricas

le proporcionan información sobre el rendimiento de cada uno de los elementos de su infraestructura. Traces le mostrará una vista más amplia de la ejecución de código y el flujo junto con las métricas de ejecución de código. Por último, los registros bien elaborados proporcionarán una información invaluable sobre la ejecución de la lógica del código y lo que estaba sucediendo en su código. Cada una de las piezas mencionadas es crucial para su aplicación y, de hecho, para la observabilidad general del sistema. Hoy, nos centraremos solo en una sola pieza: los troncos. Para ser más precisos, en registros de aplicaciones Java. Si te interesan las métricas, consulta nuestro artículo sobre métricas clave de JVM que deberías monitorear.

Sin embargo, antes de entrar en esto, abordemos un problema que impactó a la comunidad usando este marco. El 9 de diciembre de 2021, se informó de una vulnerabilidad crítica apodada Log4Shell. Identificado como CVE-2021-44228, permite a un atacante tomar el control completo de una máquina que ejecuta Apache Log4j 2 versión 2.14.1 o inferior, lo que le permite ejecutar código arbitrario en el servidor vulnerable. En nuestra reciente publicación de blog sobre la vulnerabilidad de Log4jShell, detallamos cómo determinar si está afectado, cómo resolver el problema y lo que, en Sematext, hemos hecho para proteger nuestro sistema y a los usuarios.

Log4j 1.x Fin de Vida

Tenga en cuenta que el 5 de agosto de 2015 el Comité de Gestión de Proyectos de Servicios de Registro anunció que el Log4j 1.x había llegado al final de su vida. Se recomienda a todos los usuarios que migren a Log4j 2.x. En esta publicación de blog, le ayudaremos a comprender su configuración actual de Log4j, específicamente, el log4j 2.versión x-y después de eso, te ayudaré a migrar a la última y mejor versión de Log4j.

«Estoy usando Log4j 1.x, ¿qué debo hacer?». No te asustes, no tiene nada de malo. Haga un plan para la transición a Log4j 2.x. Te mostraré cómo seguir leyendo :). Su solicitud se lo agradecerá. Obtendrá las correcciones de seguridad, mejoras de rendimiento y muchas más funciones después de la migración.

«estoy empezando un nuevo proyecto, ¿qué debo hacer?». Solo usa el Log4j 2.x de inmediato, ni siquiera pienses en Log4j 1.x. Si necesitas ayuda con eso, echa un vistazo a este tutorial de registro de Java donde te explico todo lo que necesitas.

Iniciar sesión en Java

No hay magia detrás de iniciar sesión en Java. Todo se reduce a usar una clase Java apropiada y sus métodos para generar eventos de registro. Como comentamos en la guía de registro de Java, hay múltiples formas de iniciar

Por supuesto, la más ingenua y no la mejor ruta a seguir es solo usar el Sistema.fuera y Sistema.clases de err. Sí, puede hacerlo y sus mensajes irán a la salida estándar y al error estándar. Por lo general, eso significa que se imprimirá en la consola o se escribirá en un archivo de algún tipo o incluso se enviará a /dev/null y se olvidará para siempre. Un ejemplo de dicho código podría verse como este:

public class SystemExample { public static void main(String args) { System.out.println("Starting my awesome application"); // some work to be done System.out.println( String.format("My application %s started successfully", SystemExample.class) ); }}

El resultado de la ejecución del código anterior sería el siguiente:

Starting my awesome applicationMy application class com.sematext.logging.log4jsystem.SystemExample started successfully

Eso no es perfecto, ¿verdad? No tengo ninguna información sobre qué clase generó el mensaje y muchas, muchas más cosas «pequeñas» que son cruciales e importantes durante la depuración.

Faltan otras cosas que no están realmente conectadas a la depuración. Piense en el entorno de ejecución, en múltiples aplicaciones o microservicios, y en la necesidad de unificar el registro para simplificar la configuración de la canalización de centralización de registros. Usando el Sistema.fuera, quirófano y Sistema.errar en nuestro código con fines de registro nos obligaría a rehacer todos los lugares donde lo usamos siempre que necesitemos ajustar el formato de registro. Sé que es extremo, pero créeme, hemos visto el uso del Sistema.¡código de producción en modelos de implementación de aplicaciones» tradicionales»! Por supuesto, iniciar sesión en el sistema.out es una solución adecuada para aplicaciones en contenedores y debe usar la salida que se adapte a su entorno. ¡Recuerda eso!

Debido a todas las razones mencionadas y muchas más que ni siquiera pensamos, debe buscar en una de las posibles bibliotecas de registro, como Log4 j, Log4j 2, Logback o incluso java.útil.registro que forma parte del Kit de desarrollo de Java. Para esta publicación de blog, usaremos Log4j.

La capa de abstracción-SLF4J

El tema de elegir la solución de registro correcta para su aplicación Java es algo que ya discutimos en nuestro tutorial sobre el registro en Java. Recomendamos encarecidamente leer al menos la sección mencionada.

Usaremos SLF4J, una capa de abstracción entre nuestro código Java y Log4j, la biblioteca de registro de nuestra elección. La fachada de registro simple proporciona enlaces para marcos de registro comunes como Log4j, Logback y java.útil.tala. Imagine el proceso de escribir un mensaje de registro de la siguiente manera simplificada:

¿Puede preguntar por qué usar una capa de abstracción? Bueno, la respuesta es bastante simple: eventualmente, es posible que desee cambiar el marco de registro, actualizarlo, unificarlo con el resto de su pila de tecnología. Cuando se utiliza una capa de abstracción, esta operación es bastante simple: simplemente se intercambian las dependencias del marco de registro y se proporciona un nuevo paquete. Si no utilizáramos una capa de abstracción, tendríamos que cambiar el código, potencialmente mucho código. Cada clase que registra algo. No es una experiencia de desarrollo muy agradable.

El registrador

El código de su aplicación Java interactuará con un conjunto estándar de elementos clave que permiten la creación y manipulación de eventos de registro. Hemos cubierto los cruciales en nuestro tutorial de registro de Java, pero permítanme recordarles una de las clases que usaremos constantemente: el Registrador.

El registrador es la entidad principal que utiliza una aplicación para realizar llamadas de registro: crear eventos de registro. El objeto Logger se usa generalmente para una sola clase o un solo componente para proporcionar un contexto vinculado a un caso de uso específico. Proporciona métodos para crear eventos de registro con un nivel de registro apropiado y pasarlos para su procesamiento posterior. Por lo general, creará un objeto estático con el que interactuará, por ejemplo, de esta manera:

... Logger LOGGER = LoggerFactory.getLogger(MyAwesomeClass.class);

Y eso es todo. Ahora que sabemos lo que podemos esperar, echemos un vistazo a la biblioteca Log4j.

Log4j

La forma más sencilla de comenzar con Log4j es incluir la biblioteca en el classpath de su aplicación Java. Para ello, incluimos la biblioteca log4j más reciente disponible, lo que significa la versión 1.2.17 en nuestro archivo de compilación.

Usamos Gradle y en nuestra aplicación simple y la sección de dependencias para el archivo de compilación de Gradle se ve de la siguiente manera:

dependencies { implementation 'log4j:log4j:1.2.17'}

Podemos empezar a desarrollar el código e incluir el registro usando Log4j:

package com.sematext.blog;import org.apache.log4j.Logger;public class ExampleLog4j { private static final Logger LOGGER = Logger.getLogger(ExampleLog4j.class); public static void main(String args) { LOGGER.info("Initializing ExampleLog4j application"); }}

Como puede ver en el código anterior, inicializamos el objeto Logger utilizando el método getLogger estático y proporcionamos el nombre de la clase. Después de hacer eso, podemos acceder fácilmente al objeto del Registrador estático y usarlo para producir eventos de registro. Podemos hacerlo en el método principal.

Una nota al margen: el método getLogger también se puede llamar con una cadena como argumento, por ejemplo:

private static final Logger LOGGER = Logger.getLogger("com.sematext.blog");

Significaría que queremos crear un registrador y asociar el nombre de com.sematexto.blog con él. Si vamos a usar el mismo nombre en cualquier otro lugar del código, Log4j devolverá la misma instancia del registrador. Que es útil si queremos combinar el registro de varias clases diferentes en un solo lugar. Por ejemplo, registros relacionados con el pago en un único archivo de registro dedicado.

Log4j proporciona una lista de métodos que permiten la creación de nuevos eventos de registro utilizando un nivel de registro apropiado. Esos son:

• public void traza(Object mensaje)
• public void depuración(Object mensaje)
• public void info(Object mensaje)
• public void advertir(Object mensaje)
• public void error(Object mensaje)
• public void fatal(Object mensaje)

Y un método genérico:

• registro de vacío público (Nivel de nivel, Mensaje de objeto)

Hablamos sobre los niveles de registro de Java en nuestra entrada de blog tutorial de registro de Java. Si no los conoce, tómese unos minutos para acostumbrarse a ellos, ya que los niveles de registro son cruciales para el registro. Sin embargo, si recién está comenzando con los niveles de registro, le recomendamos que revise nuestra guía de niveles de registro también. Explicamos todo, desde lo que son hasta cómo elegir el correcto y cómo hacer uso de ellos para obtener información significativa.

Si ejecutáramos el código anterior, la salida que obtendríamos en la consola estándar sería la siguiente:

log4j:WARN No appenders could be found for logger (com.sematext.blog.ExampleLog4j).log4j:WARN Please initialize the log4j system properly.log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

No vimos el mensaje de registro que esperábamos. Log4j nos informó que no hay configuración presente. Oooops, hablemos de cómo configurar Log4j

Configuración de Log4j

Hay varias formas de configurar nuestro registro de Log4j. Podemos hacerlo programáticamente, por ejemplo, incluyendo un bloque de inicialización estático:

static { BasicConfigurator.configure();}

El código anterior configura Log4j para enviar los registros a la consola en el formato predeterminado. El resultado de ejecutar nuestra aplicación de ejemplo se vería de la siguiente manera:

0 INFO com.sematext.blog.ExampleLog4jProgrammaticConfig - Initializing ExampleLog4j application

Sin embargo, la configuración programática de Log4j no es muy común. La forma más común sería usar un archivo de propiedades o un archivo XML. Podemos cambiar nuestro código e incluir el archivo log4j.properties con el siguiente contenido:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

De esa manera le dijimos a Log4j que creáramos el registrador raíz, que se usará por defecto. Su nivel de registro predeterminado está establecido en DEPURACIÓN, lo que significa que se incluirán eventos de registro con depuración de gravedad o superior. Así que DEBUG, INFO, WARN, ERROR y FATAL. También le dimos a nuestro maderero un nombre: MAIN. A continuación, configuramos el registrador, configurando su salida en consola y utilizando el diseño de patrón. Hablaremos de ello más adelante en la entrada del blog. La salida de ejecutar el código anterior sería la siguiente:

0 INFO com.sematext.blog.ExampleLog4jProperties - Initializing ExampleLog4j application

Si lo deseamos, también podemos cambiar el archivo log4j.properties y usar uno llamado log4j.xml. La misma configuración usando formato XML se vería de la siguiente manera:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

Si ahora cambiáramos log4j. properties para log4j.xml una y mantenerla en la ruta de clase la ejecución de nuestra aplicación de ejemplo sería la siguiente:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

Entonces, ¿cómo sabe Log4j qué archivo usar? Echemos un vistazo a eso.

Proceso de inicialización

Es crucial saber que Log4j no hace suposiciones con respecto al entorno en el que se ejecuta. Log4j no asume ningún tipo de destinos de eventos de registro predeterminados. Cuando se inicia, busca la propiedad log4j.configuration e intenta cargar el archivo especificado como su configuración. Si la ubicación del archivo no se puede convertir en una URL o el archivo no está presente, intenta cargar el archivo desde la ruta de clase.

Eso significa que podemos sobrescribir la configuración de Log4j desde el classpath proporcionando el archivo-Dlog4j. configuration durante el inicio y dirigiéndolo a la ubicación correcta. Por ejemplo, si incluimos un archivo llamado otro.xml con el siguiente contenido:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"><log4j:configuration> <appender name="MAIN" class="org.apache.log4j.ConsoleAppender"> <param name="Target" value="System.out"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%r %-5p %c %x - %m%n" /> </layout> </appender> <root> <priority value ="debug"></priority> <appender-ref ref="MAIN" /> </root></log4j:configuration>

Y luego ejecute el código con-Dlog4j. configuration = /opt/sematext / other.xml la salida de nuestro código será la siguiente:

0 INFO com.sematext.blog.ExampleLog4jXML - Initializing ExampleLog4j application

Appenders Log4j

Ya usamos appenders en nuestros ejemplos well bueno, en realidad solo uno: el ConsoleAppender. Su único propósito es escribir los eventos de registro en la consola. Por supuesto, con una gran cantidad de eventos de registro y sistemas que se ejecutan en diferentes entornos, escribir datos de texto puros en la salida estándar puede no ser la mejor idea, a menos que se ejecute en contenedores. Es por eso que Log4j admite varios tipos de agregadores. Estos son algunos ejemplos comunes de anexadores Log4j:

• ConsoleAppender – el accesorio que añade los eventos de registro al sistema.fuera del sistema.errar con el Sistema por defecto.fuera. Al usar este appender, verá sus registros en la consola de su aplicación.
• FileAppender: el accesorio que añade los eventos de registro a un archivo definido que los almacena en el sistema de archivos.
• RollingFileAppender – el appender que extiende el FileAppender y gira el archivo cuando alcanza un tamaño definido. El uso de RollingFileAppender evita que los archivos de registro se vuelvan muy grandes y difíciles de mantener.
• SyslogAppender-el appender que envía los eventos de registro a un demonio de registro de sistema remoto.
• JDBCAppender: el appender que almacena los eventos de registro en la base de datos. Tenga en cuenta que este anexo no almacenará errores y, por lo general, no es la mejor idea almacenar los eventos de registro en una base de datos.
• SocketAppender: el appender que envía los eventos de registro serializados a un socket remoto. Tenga en cuenta que este appender no utiliza diseños porque envía los eventos de registro sin procesar serializados.
• NullAppender: el appender que simplemente descarta los eventos de registro.

Además, puede tener varios Appenders configurados para una sola aplicación. Por ejemplo, puede enviar registros a la consola y a un archivo. El siguiente log4j.el contenido del archivo de propiedades haría exactamente eso:

log4j.rootLogger=DEBUG, MAIN, ROLLINGlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.appender.ROLLING=org.apache.log4j.RollingFileAppenderlog4j.appender.ROLLING.File=/var/log/sematext/awesome.loglog4j.appender.ROLLING.MaxFileSize=1024KBlog4j.appender.ROLLING.MaxBackupIndex=10log4j.appender.ROLLING.layout=org.apache.log4j.PatternLayoutlog4j.appender.ROLLING.layout.ConversionPattern=%r %-5p %c %x - %m%n

Nuestro registrador raíz está configurado para registrar todo a partir de la gravedad de la DEPURACIÓN y para enviar los registros a dos Agregadores: el PRINCIPAL y el ROLLING. El registrador PRINCIPAL es el que ya vimos, el que envía los datos a la consola.

El segundo registrador, el llamado ROLLING, es el más interesante en este ejemplo. Utiliza el RollingFileAppender que escribe los datos en el archivo y vamos a definir qué tan grande puede ser el archivo y cuántos archivos conservar. En nuestro caso, los archivos de registro deberían llamarse awesome.registre y escriba los datos en el directorio/var/log/ sematext/. Cada archivo debe tener un máximo de 1024 KB y no debe haber más de 10 archivos almacenados. Si hay más archivos, se eliminarán del sistema de archivos tan pronto como log4j los vea.

Después de ejecutar el código con la configuración anterior, la consola imprimiría el siguiente contenido:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

En /var/log/sematext / awesome.archivo de registro que veríamos:

0 INFO com.sematext.blog.ExampleAppenders - Starting ExampleAppenders application1 WARN com.sematext.blog.ExampleAppenders - Ending ExampleAppenders application

Nivel de registro de Appender

Lo bueno de los Appenders es que pueden tener su nivel que debe tenerse en cuenta al iniciar sesión. Todos los ejemplos que hemos visto hasta ahora registraban todos los mensajes que tenían la gravedad de DEPURACIÓN o superior. Y si quisiéramos cambiar eso para todas las clases de la com.sematexto.blog paquete? Solo tendríamos que modificar nuestro archivo log4j.properties:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%nlog4j.logger.com.sematext.blog=WARN

Mire la última línea en el archivo de configuración anterior. Hemos usado el prefijo log4j.logger y hemos dicho que el logger llama com.sematexto.el blog solo se debe usar para los niveles de gravedad WARN y superiores, por lo que es un ERROR y FATAL.

Nuestro código de aplicación de ejemplo se ve así:

public static void main(String args) { LOGGER.info("Starting ExampleAppenderLevel application"); LOGGER.warn("Ending ExampleAppenderLevel application");}

Con la configuración Log4j anterior, la salida del registro se ve de la siguiente manera:

0 WARN com.sematext.blog.ExampleAppenderLevel - Ending ExampleAppenderLevel application

Como puede ver, solo se incluyó el registro de nivel WARN. Eso es exactamente lo que queríamos.

Diseños de Log4j

Finalmente, la parte del marco de registro de Log4j que controla la forma en que se estructuran nuestros datos en nuestro archivo de registro: el diseño. Log4j proporciona algunas implementaciones predeterminadas como PatternLayout, SimpleLayout, XMLLayout, HTMLLayout, EnchancedPatternLayout y DateLayout.

En la mayoría de los casos, encontrará el PatternLayout. La idea detrás de este diseño es que puede proporcionar una variedad de opciones de formato para definir la estructura de los registros. Algunos de los ejemplos son:

• d-fecha y hora del evento de registro,
• mensaje m asociado con el evento de registro,
• nombre de hilo en t,
• separador de líneas dependiente de la plataforma n,
• nivel de registro p.

Para obtener más información sobre las opciones disponibles, visite el archivo oficial Log4j Javadocs para ver el diseño de patrones.

Al usar PatternLayout podemos configurar qué opción nos gustaría usar. Supongamos que nos gustaría escribir la fecha, la gravedad del evento de registro, el hilo rodeado de corchetes y el mensaje del evento de registro. Podríamos usar un patrón como este:

%d %-5p - %m%n

El archivo log4j.properties completo en este caso podría verse de la siguiente manera:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%d %-5p - %m%n

Usamos %d para mostrar la fecha, % – 5p para mostrar la gravedad usando 5 caracteres, %t para hilo, %m para el mensaje y %n para separador de líneas. La salida que se escribe en la consola después de ejecutar nuestro código de ejemplo se ve de la siguiente manera:

2021-02-02 11:49:49,003 INFO - Initializing ExampleLog4jFormatter application

Contexto de diagnóstico anidado

En la mayoría de las aplicaciones del mundo real, el evento de registro no existe por sí solo. Está rodeado de un cierto contexto. Para proporcionar dicho contexto, por hilo, Log4j proporciona el llamado Contexto de diagnóstico anidado. De esta manera podemos enlazar un hilo determinado con información adicional, por ejemplo, un identificador de sesión, al igual que en nuestra aplicación de ejemplo:

NDC.push(String.format("Session ID: %s", "1234-5678-1234-0987"));LOGGER.info("Initializing ExampleLog4jNDC application");

Cuando se utiliza un patrón que incluye variable x, se incluirá información adicional en cada línea de registro para el hilo dado. En nuestro caso, la salida se verá así:

0 INFO com.sematext.blog.ExampleLog4jNDC Session ID: 1234-5678-1234-0987 - Initializing ExampleLog4jNDC application

Puede ver que la información sobre el identificador de sesión está en la línea de registro. Solo como referencia, el archivo log4j.properties que usamos en este ejemplo se ve de la siguiente manera:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %x - %m%n

Contexto de diagnóstico mapeado

El segundo tipo de información contextual que podemos incluir en nuestros eventos de registro es el contexto de diagnóstico mapeado. Usando la clase MDC podemos proporcionar información adicional relacionada con la clave y el valor. Al igual que el contexto de diagnóstico anidado, el contexto de diagnóstico mapeado está enlazado a hilos.

Veamos nuestro código de aplicación de ejemplo:

MDC.put("user", "[email protected]");MDC.put("step", "initial");LOGGER.info("Initializing ExampleLog4jNDC application");MDC.put("step", "launch");LOGGER.info("Starting ExampleLog4jNDC application");

Tenemos dos campos de contexto: el usuario y el paso. Para mostrar toda la información de contexto de diagnóstico asignada asociada con el evento de registro, solo usamos la variable X en nuestra definición de patrón. Por ejemplo:

log4j.rootLogger=DEBUG, MAINlog4j.appender.MAIN=org.apache.log4j.ConsoleAppenderlog4j.appender.MAIN.layout=org.apache.log4j.PatternLayoutlog4j.appender.MAIN.layout.ConversionPattern=%r %-5p %c %X - %m%n

Lanzar el código anterior junto con la configuración daría como resultado la siguiente salida:

0 INFO com.sematext.blog.ExampleLog4jMDC {{step,initial}{user,[email protected]}} - Initializing ExampleLog4jNDC application1 INFO com.sematext.blog.ExampleLog4jMDC {{step,launch}{user,[email protected]}} - Starting ExampleLog4jNDC application

También podemos elegir qué información usar cambiando el patrón. Por ejemplo, para incluir al usuario desde el contexto de diagnóstico mapeado, podríamos escribir un patrón como este:

%r %-5p %c %X{user} - %m%n

Esta vez la salida se vería de la siguiente manera:

0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Initializing ExampleLog4jNDC application0 INFO com.sematext.blog.ExampleLog4jMDC [email protected] - Starting ExampleLog4jNDC application

Puede ver que en lugar del %X general hemos usado %X{usuario}. Eso significa que estamos interesados en la variable de usuario del contexto de diagnóstico mapeado asociado a un evento de registro dado.

Migración a Log4j 2

Migración desde Log4j 1.x a Log4j 2.x no es difícil y, en algunos casos, puede ser muy fácil. Si no ha utilizado ningún Log4j 1 interno.clases x, ha utilizado archivos de configuración sobre la configuración programática de registradores y no utilizó las clases DOMConfigurator y PropertyConfigurator la migración debe ser tan simple como incluir la api log4j-1.2.archivo jar jar en lugar del Log4j 1.archivos x jar. Eso permitiría Log4j 2.x para trabajar con tu código. Tendría que agregar el Log4j 2.x archivos jar, ajuste la configuración y listo, listo.

Si desea obtener más información sobre Log4j 2.x echa un vistazo a nuestro tutorial de registro de Java y su Log4j 2.x sección dedicada.

Sin embargo, si utilizó Log4j 1 interno.clases x, la guía oficial de migración sobre cómo moverse desde Log4j 1.x a Log4j 2.x será muy útil. Analiza los cambios de código y configuración necesarios y será invaluable en caso de duda.

Registro centralizado con herramientas de administración de registros

Enviar eventos de registro a una consola o un archivo puede ser bueno para una sola aplicación, pero manejar varias instancias de su aplicación y correlacionar los registros de varias fuentes no es divertido cuando los eventos de registro se encuentran en archivos de texto en diferentes máquinas. En tales casos, la cantidad de datos se vuelve inmanejable rápidamente y requiere soluciones dedicadas, ya sea auto-alojadas o provenientes de uno de los proveedores. ¿Y qué pasa con los contenedores en los que normalmente ni siquiera escribes registros en archivos? ¿Cómo soluciona problemas y depura una aplicación cuyos registros se emitieron a la salida estándar o cuyo contenedor se ha eliminado?

Aquí es donde entran en juego los servicios de administración de registros, las herramientas de análisis de registros y los servicios de registro en la nube. Es una práctica recomendada de registro de Java no escrita entre los ingenieros usar este tipo de soluciones cuando se toma en serio la gestión de sus registros y sacarle el máximo provecho. Por ejemplo, Sematext Logs, nuestro software de monitoreo y administración de registros, resuelve todos los problemas mencionados anteriormente y más.

Con una solución totalmente administrada como Sematext Logs, no tiene que administrar otra parte del entorno: su solución de registro de bricolaje, que normalmente se construye utilizando piezas de la pila elástica. Tales configuraciones pueden comenzar pequeñas y baratas, sin embargo, a menudo crecen grandes y caras. No solo en términos de costes de infraestructura,sino también de gestión. Ya sabes, tiempo y nómina. Explicamos más sobre las ventajas de usar un servicio administrado en nuestra publicación de blog sobre las mejores prácticas de registro.

Alertas y agregación de registro también son cruciales cuando se trata de problemas. Eventualmente, para las aplicaciones Java, es posible que desee tener registros de recolección de basura una vez que active el registro de recolección de basura y comience a analizar los registros. Estos registros correlacionados con métricas son una fuente de información invaluable para solucionar problemas relacionados con la recolección de basura.

Resumen

Aunque Log4j 1.x llegó al final de su vida útil hace mucho tiempo, todavía está presente en un gran número de aplicaciones heredadas utilizadas en todo el mundo. La migración a su versión más joven es bastante simple, pero puede requerir recursos y tiempo sustanciales y, por lo general, no es una prioridad máxima. Especialmente en grandes empresas donde los procedimientos, los requisitos legales o ambos requieren auditorías seguidas de pruebas largas y costosas antes de que se pueda cambiar algo en un sistema que ya está en ejecución. Pero para aquellos de nosotros que recién estamos comenzando o pensando en la migración, recuerde, Log4j 2.x está ahí, ya es maduro, rápido, seguro y muy capaz.

Pero independientemente del marco que esté utilizando para registrar sus aplicaciones Java, definitivamente recomendamos combinar sus esfuerzos con una solución de administración de registros totalmente administrada, como los registros Sematext. ¡Inténtalo! Hay una prueba gratuita de 14 días disponible para que la pruebes.

¡Feliz registro!