Convenciones de registro

Question

¿Qué convenciones usa para las categorías de registro en log4j o bibliotecas similares? Normalmente ve los nombres de las clases como categorías, pero ¿ha utilizado otros sistemas?

¿Qué sucede con los niveles de registro? ¿Qué niveles usas y en qué caso?

Actualización: como algunos de ustedes respondieron, no hay una respuesta "correcta". Solo busco las diferentes convenciones que las personas usan como una posible fuente de inspiración.

Answer 1

Tengo 3 niveles: errores, advertencias y un registro detallado que dice lo que el programa está haciendo a la vez.

Utilizo class + function como contexto.

Answer 2

Hemos tenido extensos debates sobre esto a lo largo de los años y lo único en lo que todos estamos de acuerdo es en que no hay una respuesta perfecta.

Lo que hemos decidido es utilizar un nombre de categoría de primer nivel para diferenciar entre categorías amplias: p. 'Operación' se refiere a cualquier cosa que le interese al usuario, 'Interna' se refiere a cosas que solo le preocupan al desarrollador, 'Auditoría' se usa para rastrear eventos interesantes.

Más allá de eso intentamos límite el número de categorías, ya que encontramos que nadie las enciende/apaga en el nivel más detallado. Entonces, en lugar de nombres de clase tratamos de agruparlos en el área funcional, ej. Consulta, actualizaciones, etc.

Answer 3

El registro depende de su requisito. Si está creando un registro que simplemente controla si ha habido algún problema (como excepciones de registro), entonces solo puede requerir el nombre de la clase y la función.

Sin embargo, si tiene un requisito funcional para crear y realizar un seguimiento de tipo de pista, el registro debe llevarse a un nivel completamente diferente de detalle.

Answer 4

Tenemos registros de depuración que son clase + método.

También tenemos registros específicos para ciertas acciones, por ejemplo, conexión recibida en un socket. Estos son los que llamo 'Fact Logs' o 'Audit Trail Logs', registran un solo tipo de cosas. Por supuesto recientemente, simplemente los incluyo en una base de datos porque los hechos que usted está capturando pueden ser bastante más complejos que una cadena de texto, pueden incluir estado en un momento determinado. Es decir, transfiere su propio mecanismo de registro de auditoría para cada auditoría que necesita.

Al depurar, configuraremos el paquete/clase que estamos depurando para DEPURAR en log4j, mientras dejamos el registro de raíz en ERROR, y tendremos un archivo de registro de depuración para lo que con suerte deja fuera todo el registro de otras áreas de la aplicación.

Pero realmente no hay una "manera correcta" de hacer estas cosas. Una combinación de mecanismos parece buena, pero depende de lo que quiera registrar.

Answer 5

Estoy de acuerdo con Vaibhav's answer: debe saber por qué está iniciando sesión.

• para la depuración informaciones técnicas de depuración interna, log4j o cualquier otra biblioteca está muy bien (siempre que su uso no aumenta artificialmente el cyclomatic complexity de las funciones)
• para transversal puntual registro (a través de todo el código), algunos Aspect-Oriented approach se adapta mejor
• para monitoreo, se introduce a todo otro nivel de registro, a saber, la KPI, con la necesidad de registrar los datos a través de un bus de publicación (como TIBCO por ejemplo) a algún tipo de base de datos.

Así que por sólo el registro interno, que siguen un enfoque bastante estándar:

• severa por cualquier error que pueda comprometer el programa
• información para el seguimiento de la progresión interna
• bien para algunos sub -pasos de detalles

La granularidad (para el registro interno clásico) es la clase principal, la que está a cargo de la principal ste ps del proceso.