[vc_row][vc_column][vc_column_text]
El log del Garbage Collector no es un registro estándar, y a medida que pasa el tiempo, proliferan diferentes «estándares», lo que lleva a una mayor fragmentación. ¿Cómo se puede arreglar esto?. En este artículo, Ram Lakshmanan repasa un último intento de estandarización, el framework Unified JVM Logging.
El formato del log del GC varía según el proveedor de JVM, la versión de Java, el algoritmo de GC y las propiedades del sistema de GC que se registren. Los registros difieren de Oracle a IBM, Java 8 a Java 9, Serial a Shenandoah, e incluso se basan en consideraciones técnicas. En función de estas combinaciones y permutaciones, ya hay más de 40 formatos diferentes de logs de Garbage Collection.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Desafíos de los estándares dispares de Garbage Collection
Si ha realizado una secuencia de comandos que analiza el log de GC para extraer ciertas estadísticas o lanzar alertas cuando el tiempo de GC excede cierto umbral o supervisar eventos repetidos de GC, estos escripts deben personalizarse para adaptarse a diferentes formatos de registros de GC.
Dado que hay diferentes formatos de GC, es difícil entender cada uno de los formatos e interpretar los resultados de manera efectiva. La mayoría de los formatos no tienen ninguna documentación o literatura. Por supuesto, este punto puede contradecirse: puede utilizar sofisticadas herramientas de análisis de registro de GC, como GCeasy o HPJmeter.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Unificación o proliferación?
Cuando se dio la noticia de que los logs de GC se volverán a implementar utilizando «Unified JVM logging framework (JEP 158)» en Java 9, fue una gran noticia. Esto, de primera significaba que todos los logs diferentes de GC se consolidarían en un formato estándar. Todo sería más sencillo. Más, esto no sucedió. En cambio, se crearon más formatos de los logs.
El objetivo del framework Unified JVM Logging es introducir un sistema de registro común para todos los componentes de la JVM. Específicamente, está destinado a unificar componentes como el compilador, el GC, el classloader, los metaspace, svc, jfr y más. ¿Entonces, cómo funciona? En cada línea de registro, se imprime la siguiente información además de la información actual que está presente en la versión anterior de los logs de GC:
- Nombre del componente – compiler, GC, classloader, metaspace, svc, jfr
- Nivel del Log – trace, debug, info, warning, error
- Información adicional – time, uptime, timemillis, uptimemillis, timenanos, uptimenanos, pid, tid
Además de estos parámetros adicionales, el formato de extracto del log de GC también ha cambiado. Aquí hay una comparación entre Java 8 y Java9:[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=»1674″ img_size=»full» alignment=»center» title=»Fig 1: formato de GC en Java 9 Unified Logging»][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=»1675″ img_size=»full» alignment=»center» title=»Figura 2: Formato del log en Java 8″][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Si observa en detalle las figuras 1 y 2, puede ver las diferencias en como ha cambiado los logs de GC entre la versión de Java 8 y Java9.
Conclusión
Es fácil quejarse y criticar cualquier implementación. Sin embargo, se entiende el hecho de que el equipo de ingeniería de Oracle recibió la misión de migrar al framework Unified JVM Logging. Como es una iniciativa global de JVM, el log del GC se combinó en esta situación. Una propuesta sería aprovechar herramientas como GCEasy y HPJmeter para analizar la mayoría de los formatos de registros de GC. Pero al final, sólo la comunidad en general puede simplificar este problema al elegir un enfoque estandarizado.
Este artículo se encuentra basado en The proliferation of Java Garbage Collection logs standards[/vc_column_text][/vc_column][/vc_row]
