Reglas y consejos para iniciar sesión?

En mi organización, hemos reunido algunas reglas / líneas de control sobre el registro que me gustaría saber si puede agregar o comentar.

Usamos Java, pero puede comentar en general sobre el inicio de sesión: reglas y consejos

1. Use el nivel de registro correcto

   • ERROR: Algo ha salido muy mal y es necesario solucionarlo de inmediato.
   • ADVERTENCIA: El proceso puede continuar sin reparaciones. La aplicación debe tolerar este nivel, pero la advertencia siempre debe investigarse.
   • INFORMACIÓN: información de que un proceso importante ha finalizado
   • DEPURAR. Solo se usa durante el desarrollo

2. Asegúrese de saber lo que está registrando.

3. Evite que el registro influya en el comportamiento de la aplicación.

La función del registro debe ser escribir mensajes en el registro.

1. Los mensajes de registro deben ser descriptivos, claros, cortos y concisos.

No se utiliza mucho un mensaje sin sentido al solucionar problemas.

1. Ponga las propiedades correctas en log4j

Ponga que el método y la clase correctos se escriben automáticamente.

Ejemplo:

Datedfile -web

log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG

log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n

log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/

1. Valor de registro.

Por favor, registre los valores de la aplicación.

1. Prefijo de registro

Indique desde qué parte de la aplicación se escribe el registro, preferiblemente con algo para el prefijo acordado del proyecto, por ejemplo PANDORA_DB

1. La cantidad de texto.

Tenga cuidado para que no haya demasiado texto de registro. Puede influir en el rendimiento de la aplicación.

1. Formato de inicio de sesión:

-Hay varias variantes y métodos para usar con log4j, pero nos gustaría un uso uniforme del siguiente formato, cuando iniciamos sesión con excepciones:

logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);

En el ejemplo anterior, se supone que hemos establecido las propiedades de log4j para que escriba automáticamente la clase y el método.

Utilice siempre el registrador y no lo siguiente:

System.out.println(), System.err.println(), e.printStackTrace()

Si la aplicación web utiliza nuestro marco, puede obtener información de error muy detallada de EJB, si usa try-catch en el controlador y registra de acuerdo con el modelo anterior:

En nuestro proyecto, usamos este patrón de conversión con el cual los nombres de método y clase se escriben automáticamente. Aquí usamos dos patrones diferentes para la consola y para el archivo de archivos con fecha:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

En los ejemplos anteriores, el método y la clase se escribirán. En el número de fila de la consola también se escribirá nuestro.

1. toString()

Por favor tenga un toString()para cada objeto. EX:

@Override
public String toString() {
  StringBuilder sb = new StringBuilder();
  sb.append(" DwfInformation [ ");
  sb.append("cc: ").append(cc);
  sb.append("pn: ").append(pn);
  sb.append("kc: ").append(kc);
  sb.append("numberOfPages: ").append(numberOfPages);
  sb.append("publicationDate: ").append(publicationDate);
  sb.append("version: ").append(version);
  sb.append(" ]");
  return sb.toString();
}

en lugar del método especial que hace estas salidas

public void printAll()
{
    logger.info("inbet: " + getInbetInput());
    logger.info("betdat: " + betdat);
    logger.info("betid: " + betid);
    logger.info("send: " + send);
    logger.info("appr: " + appr);
    logger.info("rereg: " + rereg);   
    logger.info("NY: " + ny);   
    logger.info("CNT: " + cnt);   
}

Entonces, ¿hay algo que pueda agregar, comentar o encontrar cuestionable con estas formas de usar el registro? Siéntase libre de responder o comentar incluso si no está relacionado con Java, Java y log4j es solo una implementación de cómo se razona esto.

Como una extensión de su regla de inicio de sesión de dónde proviene la declaración de registro, es posible que desee agregar indicadores de registro por nivel de módulo. En lugar de registrar todo, todo el tiempo, esto le permite seleccionar selectivamente secciones de su aplicación. Hay una sobrecarga en esto, y necesita crear una instalación que le permita habilitar / deshabilitar ese registro. Idealmente, podría habilitar / deshabilitar sobre la marcha mientras se ejecuta la aplicación.

Estoy acostumbrado a ver una capa debajo de la depuración que llamo "Trace", pero ese no es necesariamente un término universal. El registro de nivel "Trace" rastrea todo lo que pueda soportar, incluyendo entrada / salida del módulo, marcas de tiempo con entrada / salida y puntos de bonificación para capturar valores pasados. Obviamente, eso genera MUCHOS datos y no es algo que enciendas de todas formas. Pero tiene ventajas con respecto a la depuración cuando no puede adjuntar al proceso o no tiene un volcado de núcleo de la aplicación errónea.

Me gusta ver referencias de archivo / módulo y marcas de tiempo con mi información de registro. Puede ser útil al tratar de buscar condiciones de carrera entre subprocesos, así como coordinar las actividades de múltiples áreas de la aplicación. Para ser justos, sé de algunas personas que piensan que estos detalles abarrotan el archivo de registro. Agregar la marca de tiempo es algo para discutir con el equipo. (Disculpas si log4j ya lo hace).

Si el registro no está siendo atendido por su propio hilo / proceso, eso también es algo a considerar. En lugar de hacer que el subproceso de la aplicación espere a que se procese el registro, el mensaje de registro se pasa al controlador de registro y el subproceso de la aplicación sigue su camino feliz. Alternativamente, crear algún tipo de mecanismo de almacenamiento intermedio para manejar los mensajes de registro es otra forma de acelerar la capacidad de respuesta de la aplicación.

Tener controles sobre el tamaño y el historial de los archivos de registro es otra característica a tener en cuenta. No desea que la aplicación elimine todo el espacio en disco en el sistema host, ni desea conservar todos los archivos de registro para toda la eternidad.

Una cosa a tener en cuenta es verificar el nivel de registro antes de realizar cualquier tipo de operaciones de cadena para el registro. Es decir, no haga todo el trabajo de configurar un formateador de fecha o concatenar un montón de cadenas para crear el mensaje de registro si realmente no va a registrarlo. Eso es un desperdicio de trabajo que ralentiza su aplicación.

Para su información, el proyecto Apache Commons tiene una ToStringBuilder clase que simplifica la creación de sus toString()métodos.

No encuentro nada cuestionable en lo que has agregado aquí, Nick. Así es como lo he estado haciendo por algún tiempo. La publicación que ha proporcionado es muy detallada y probablemente pueda usarse como una especie de tutorial para iniciar sesión. Sin embargo, quiero agregar una cosa aquí, que es: En muchos lugares, he estado viendo chaps usando el registro condicional, por ejemplo:

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Creo que este tipo de rastreo o depuración condicional no es la mejor manera de hacerlo.

Además de registrar la Clase / Método que provocó el error, sería útil registrar también los parámetros pasados ​​a ese método. Saber dónde se produjo un error no es muy útil si solo ocurre 1 vez de 1000; También necesita saber qué datos causaron el error.

También me pareció útil tener una variable que defina el nivel predeterminado de registro para una aplicación. De esa manera, puede tener el código DEPURACIÓN e INFORMACIÓN junto con el código de ADVERTENCIA y ERROR. Cuando se ejecuta en modo de producción, la configuración predeterminada es que no muestre información de DEPURACIÓN, pero cuando aparece un error, puede actualizar un indicador y comenzar a escribir mensajes de DEPURACIÓN también en el registro.

La tala es la mayor parte del tiempo una preocupación transversal. Java por sí solo no es lo suficientemente expresivo como para que pueda separar el registro de las lógicas comerciales reales. Esto significa que no puede, por ejemplo, simplemente tomar un método y ponerlo en otro proyecto, sino que debe eliminar y ajustar todo su registro antes de hacerlo. Y eso es solo la punta del iceberg.

Para evitar ese y otros problemas al mezclar el registro y las lógicas comerciales "reales", debe considerar el uso de la programación orientada a aspectos. Para Java, el marco más utilizado sería AspectJ. Existe este video de YouTube de las charlas de tecnología de Google que explica AspectJ y sus usos más allá del registro bastante bien. Encontrará muchos ejemplos para iniciar sesión, por supuesto, aquí en stackexchange también .

Una cosa que sugeriría es que tenga un medio para tener múltiples contextos de registro asociados con cualquier archivo de registro en particular, y haga los arreglos para que cualquier cosa escrita en cualquier contexto de registro se registre a menos que el código solicite explícitamente al contexto de registro que descarte su contenido. Tal diseño permitirá capturar registros bastante detallados durante una operación y descartarlos si la operación tiene éxito, pero los tendrá disponibles si la operación falla. En ausencia de dicha función de registro, tener buenos registros disponibles cuando algo falla puede requerir que una aplicación pierda mucho tiempo registrando datos inútiles en el 99.99% de las veces cuando todo funciona.