Qué registrar/rastrear en un entorno de producción

Question

Me pregunto qué tipo de información se debe registrar en un archivo una vez que la aplicación se haya trasladado a un entorno de producción. Además del registro de excepciones y errores ...

¿Se debe registrar el inicio y el final de cada método? El inicio y el final de un servicio en funcionamiento? ¿Cada vez que la aplicación guarda datos en una base de datos o llama a un servicio externo? Estoy intentando encontrar el equilibrio entre registrar/rastrear todo y solo registrar errores.

Answer 1

Realmente depende de ti, no hay reglas fijas & duros.

par de meses atrás que estábamos trabajando en esta aplicación Java y utiliza log4j para el registro, en log4j hemos sido capaces de definir en el código de nuestros registros, ya sea como depuración, advertencia, error, etc. información

Nuestro registro de depuración fue casi en cada inicio de funciones & final, cada transacción exitosa no exitosa se registró como "información", "error" en las excepciones se registraron & del mismo modo.

Una vez que movimos la aplicación en el entorno de producción después de un mes o así, desconectamos todos los registros de depuración a través de archivos .properties sin reiniciar la aplicación & estábamos listos para continuar.

Answer 2

Me gusta usar diferentes niveles. El menos detallado muestra el inicio y el apagado del servicio , así como también errores y excepciones. El más detallado podría ir tan lejos como mostrando el valor de cada variable local, función de entrada/salida y así sucesivamente.

Cuantos más detalles pueda obtener con facilidad, menos excavaciones tendrá y menos posibilidades tendrá de saltar en un avión para ir donde está el problema. . . .

K

Answer 3

En un entorno de producción, tengo el inicio de sesión establecido en "INFO" de forma predeterminada (usando log4net), y en este nivel registro la información suficiente para tener una buena posibilidad de diagnosticar cualquier error. Entonces, ¿qué es información "suficiente"? Bueno, eso depende de tu sistema. En nuestro sistema, registro los puntos de entrada y salida de los métodos más importantes, incluidos sus parámetros de entrada y los valores de retorno (a menos que sea una gran cantidad de datos). Estoy dispuesto a aceptar un 5-10% de gastos generales para el registro (pero debe medir esto).

Mi formato Perferred es la siguiente: entrada

Método:

-> MiMetodo (1, "arg1")

Método de salida:

< -MyMethod (1 " arg1 ") = verdadero

Las flechas significan que puedo ver fácilmente si esto es entrada o salida. Al incluir los argumentos y el valor de retorno obtengo los datos más críticos para diagnosticar errores. Solo tengo un punto de retorno de mis métodos, por lo que no tengo que preocuparme por los puntos de salida múltiples para mi registro.

Al ingresar/salir del método de registro, no tengo que registrar mucho más: si su código se descompone correctamente en métodos, esto documentará el flujo de ejecución a través de su aplicación.

No cometa el error de no registrar suficiente información porque le preocupa el rendimiento: mida esto para que esté contento con la sobrecarga, pero confía en que está iniciando sesión lo suficiente para diagnosticar fallas basadas puramente en la información eso está en el registro. Lo que no desea hacer es cambiar el inicio de sesión a más detalles después de su cliente ha informado de un error, y luego esperar que la falla ocurra nuevamente.

También uso un nivel de registro DEBUG que registra prácticamente todo. Esto solo se usa en desarrollo/prueba, o quizás en producción, pero solo después de consultar con el cliente.