1. Antecedentes
En el desarrollo diario, se suelen imprimir muchos registros de nivel INFO para facilitar la depuración y la comprobación de problemas.
Con el aumento del número de visitas, si no tiene cuidado, el tamaño de un archivo de registro en un día será mayor que un cierto umbral (como 5G). Por lo tanto, recibirá una alarma para optimizar el tamaño del registro y informe a su supervisor si el tamaño del registro no está optimizado dentro de un cierto período de tiempo. ,Oops...
Si el registro es demasiado grande, es fácil que algunas operaciones de operación y mantenimiento consuman el rendimiento de la máquina, como la recuperación de archivos de registro, la recopilación de datos y la limpieza del disco.
Entonces, ¿cuáles son las ideas comunes para adelgazar troncos? Este artículo se basa en un caso específico para hablar sobre mis puntos de vista.
2. Metodología de adelgazamiento diario
2.1 Imprima solo los registros necesarios
A veces, para facilitar las pruebas, se imprimen temporalmente muchos registros de nivel INFO. Para dichos registros, los registros innecesarios se pueden eliminar o ajustar al nivel DEBUG antes de que el proyecto entre en funcionamiento.
Sin embargo, en algunos escenarios, algunos registros se pueden imprimir como DEBUG o INFO. La impresión en el nivel INFO ocupa espacio, y la impresión en el nivel DEBUG debe usarse cuando se verifican problemas en línea. ¿Qué debo hacer?
Podemos transformar la clase de herramienta de registro para admitir un determinado cambio en la transferencia de contexto (las llamadas normales no tienen este cambio, pero se pasan a través del contexto Tracer o RPC de la empresa), y el registro DEBUG se puede actualizar temporalmente al nivel INFO. El pseudocódigo es el siguiente:
if(log.isDebugEnable()){
log.debug(xxx);
}else if(TracerUtils.openDebug2Info()){
log.info("【debug2info】"+xxx);
}
De esta forma, algunos registros que están confundidos acerca de si se deben imprimir como registro INFO se pueden imprimir como nivel DEBUG y se actualizan automáticamente al registro INFO cuando se verifica el problema. Para evitar malentendidos, distinga entre los registros DEBUG boost INFO y los registros INFO normales, y agregue un prefijo de registro similar a [debug2info].
Por supuesto, también puede participar en otras operaciones salaces, aquí hay solo un ejemplo, haga inferencias por sí mismo.
2.2 Impresión combinada
Algunos registros que se pueden fusionar se pueden considerar para la fusión.
Si el registro INFO se imprime antes y después del mismo método:
INFO [id de rastreo de 64 bits] XXXService tamaño = 10 antes de la ejecución INFO [id de rastreo de 64 bits] XXXService tamaño = 4 después de la ejecución
Se puede combinar en uno:
INFO [traceId de 64 bits] XXXService tamaño =10 antes de la ejecución y tamaño =4 después de la ejecución
2.3 Simplificación, abreviatura y compresión
某个日志非常有必要，但是打印的对象有些大，如果可以满足问题排查需求的情况下，我们可以：
（1）选择只打印其 ID
（2）创建一个只保留关键字段的日志专用对象，转化为日志专用对象，再打印。
（3）可以用缩写，如 write 简化为 w, read 简化为 r, execute 简化为e 等；比如 pipeline 中有 20个核心 bean ，打印日志时可以使用不同的编号替代 bean 全称，如 S1,S2 ，虽然没那么直观，但既可以查问题，又降低了日志量。
三、优化案例
3.1 场景描述
一个业务场景涉及很多 bean， 为了复用一些通用逻辑，这些 bean 都继承自某个抽象类。 在抽象类中，定义了执行 bean 前后的一些通用逻辑，如执行前后打印当前 pipeline 中 item 的数量。 最后一个 bean 执行完结果转换后需要打印出结果。
3.2 优化分析
3.2.1 只打印必要日志
（1）由于当前 bean 执行前 相当于前一个 bean 执行后，因此只打印执行后的日志就可以，执行前的INFO 日志可以删除或者改为 DEBUG （只打印必要日志）
（2）通常问题只出现在执行前后 size 不一致的情况下，因此执行后打印日志前可以加个判断，如果执行前后 size 相同则不打印。（只打印必要日志） 伪代码如下：
if(sizeBefore != sizeAfter){
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
}
这招效果很明显，因为大多数 bean 的执行前后 size 是相同的，就不会打印这条日志。 而假设之前有 20 个，这条日志就需要打印 20次，改进后可能只需要打印 2-3 次。
3.2.2 日志合并
（2）为了方便查问题还需要打印执行前的 size ，那么将执行前的 size 记录在内存中，打印执行后日志时多打印出执行前的 size。（合并打印） 伪代码如下：
log.info("service:{}, 执行前size:{}", getName(),sizeBefore)
log.info("service:{}, 执行后size:{}", getName(),sizeBefore, sizeAfter)
合并后
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
3.2.3 日志精简
对于最终结果，将结果对象（如 XXDTO）转化为只包括关键信息，如 id, title 的日志对象（XXSimpleLogDTO），转化为日志对象后再打印。
log.info("resultId:{}",result.getId());
或者
log.info("result:{}",toSimpleLog(result));
3.3 效果评估
El registro genera alrededor de 5 GB por día, y alrededor del 80 % es el tamaño antes y después de la impresión, alrededor del 10 % es el resultado final de la impresión y hay algunos otros registros. Después de optimizar el método anterior, el volumen de registro diario es inferior a 1G.
Existe un equilibrio entre satisfacer las necesidades de resolución de problemas y realizar la reducción de registros.
4. Resumen
La reducción de registros requiere una compensación, manteniendo los registros necesarios para solucionar problemas lo más reducidos posible.
Se puede optimizar eliminando registros innecesarios, fusionando registros y simplificando registros.
También podemos realizar algunas operaciones complicadas y admitir DEBUG en línea para aumentar temporalmente INFO (por supuesto, también se pueden usar arthas) para ayudarnos a verificar problemas.
¿Qué otros buenos consejos para llevar un diario tienes? Siéntase libre de comentar y comunicarse conmigo al final del artículo.
No es fácil de crear. Si este artículo te es útil, dale me gusta, marca como favorito y sígueme. Tu apoyo y aliento son la mayor motivación para mi creación.