¿Alguna razón para no registrar siempre los rastros de pila?

Question

Encontrado un problema frustrante en nuestra aplicación hoy que se redujo a una excepción ArrayIndexOutOfBounds que se lanza. El tipo de la excepción era casi todo lo que se registraba, lo cual es bastante inútil (pero, oh querida aplicación heredada, todavía te amamos, en su mayoría). He redistribuido la aplicación con un cambio que registra el seguimiento de pila en el manejo de excepciones (y de inmediato encontré la causa raíz del problema) y me pregunté por qué nadie más lo hizo antes. ¿Generalmente registra el seguimiento de la pila y hay alguna razón por la que no haría esto?

Puntos de bonificación si puede explicar (por qué, no cómo) la razón detrás de tener que saltar aros en java para obtener una representación de cadena de un rastro de pila!

Answer 1

• Algunos registros contengan datos sensibles, las facilidades de registro no son necesariamente lo suficientemente seguros para realizar un seguimiento de los datos de la producción.

• Registrar demasiado puede dar como resultado demasiada información, es decir, no hay información para los administradores del sistema. Si sus registros están llenos de mensajes de depuración, no podrán reconocer patrones sospechosos. (Hace años vi a un sistema de registro de todas las llamadas al sistema por motivos de seguridad. Había tantos registros, que nadie lo vio cuando algunos usuarios no privilegiados empezaron a convertirse en root.)

mejor que se puede hacer para registrar todo con niveles de registro apropiados, y ser capaz de establecer niveles de registro en producción (al menos en Java no es un gran problema).

Answer 2

Las restricciones en el registro a menudo se eliminan cuando los desarrolladores registran demasiado liberalmente y los administradores de sistemas descubren que la aplicación, una vez sometida a una carga de producción, arrasa y llena la HD con enormes archivos de registro. Puede ser difícil convencerlos de que ha visto el error de su camino y ha reducido el registro (o los niveles de registro ajustados) lo suficiente, pero realmente necesitan esas entradas de registro restantes.

Answer 3

Por lo general, registro el seguimiento de la pila, porque tiene información para solucionar problemas/depurar el problema. Es lo mejor pensar al lado de un minivolcado y, a menudo, conduce a una solución simplemente mediante la inspección del código y la identificación del problema.

BTW, estoy de acuerdo con sibidiba sobre la posible divulgación de información sobre las aplicaciones internas de una aplicación: los nombres de las funciones, junto con la secuencia de llamadas de pila, pueden decir mucho a un lector educado. Esta es la razón por la cual algunos productos solo registran la dirección del símbolo en la pila, y confían en los desarrolladores para resolver la dirección al nombre desde los pdbs internos.

Pero considero que el registro de texto en archivos que contienen 1 línea de error y 14 líneas de pila hace que sea muy difícil navegar por los registros de errores. También causa problemas en aplicaciones de alta concurencia porque el bloqueo en el archivo de registro se mantiene por más tiempo (o peor, los archivos de registro se entrelazan). Habiendo encontrado estos problemas muchas veces, junto con otros problemas en el soporte y la solución de problemas de las implementaciones de mis propias aplicaciones, me llevó a crear un servicio para registrar errores al bugcollect.com. Al diseñar las políticas de recopilación de errores elegí recolectar los volcados de pila todo el tiempo, y usar las pilas como parte de las llaves de la cubeta (para agrupar los errores que ocurren en la misma pila en el mismo cubo).

Answer 4

Para nosotros es muy simple: si se produce una excepción inesperada, registramos el seguimiento de la pila junto con un mensaje que nos dice lo más posible.

Supongo que el desarrollador que escribió el código original en la pregunta, simplemente no tenía la experiencia suficiente como para saber que no es suficiente con solo el mensaje. Yo también lo pensé una vez.

La razón por la que es intrincado obtener un seguimiento de la pila como una cadena es porque no hay StringPrintWriter en el JRE - Creo que la línea de pensamiento ha sido que proporcionan una gran cantidad de bloques ortogonales que luego combinas como necesario. Debe ensamblar el PrintWriter necesario usted mismo.

Answer 5

favor ver estas preguntas también

Logging in Java and in general: Best Practices?

Best practices for Java logging from multiple threads?

cosas importantes aquí a considerar

1. Manejo de los datos sensibles
2. mensajes de excepción compactos y enviar por correo los de fijadores adecuados
3. Registrando lo que se requiere. Debido a que su registro costoso en términos de espacio y hora

Answer 6

Los puntos de bonificación si se puede explicar (¿por qué, no cómo) la razón de tener para saltar aros en Java para obtener una cadena representación de una pila ¡rastro!

¿No debería simplemente registrar el throwable en lugar de pasar por aros para imprimir stacktrace? De esta manera: log.error ("Falló al implementar!", Ej.). Dado un lanzamiento, Log4J imprimirá tanto el mensaje de error obtenido a través de getMessage() como el seguimiento de la pila.

Answer 7

Lo que he visto es mucho código de registro de una excepción de esta manera:

log.error (ex);

Como log4j acepta un objeto como primer argumento, registrará la representación de cadena de la excepción, que a menudo es solo el nombre de la clase. Esto es generalmente solo un descuido por parte del desarrollador. Es mejor iniciar sesión y generar un error como este:

LOG.error ("foo happened", ex);

..so que si se configura correctamente, el marco de registro registrará el seguimiento de la pila.