¿Qué logging es un buen registro para su aplicación?

Question

Así que hemos discutido la posibilidad de iniciar sesión en mi lugar de trabajo y me preguntaba si algunos de ustedes aquí podrían darme algunas ideas de sus enfoques.

Por lo general, nuestro escenario es que no hay ningún registro, y en su mayoría aplicaciones .NET, winforms/WPF clientes hablando a través de servicios web o directamente a un DB.

Entonces, la verdadera pregunta es, ¿dónde o qué registrarías? Por el momento, tenemos usuarios que informan mensajes de error, por lo que supongo que inicie y apague el registro, excepciones ...

¿Lo lleva a llamar a servicios web o db? Carga de página

¿Cómo se hace una buena idea de lo que el usuario estaba tratando de hacer en ese momento?

Es mejor ir hasta el final y registrar todo en varios intentos/días, o registrar solo lo que necesita (dado que el disco duro es barato).

Supongo que son algunas preguntas, pero quería tener más una idea de lo que es la práctica real en las tiendas más grandes.

Answer 1

La clave para el registro es una buena planificación. Sugeriría que busque en la excepción de biblioteca de empresa y en el bloque de aplicación de registro (http://msdn.microsoft.com/en-us/library/cc467894.aspx). Hay una pequeña curva de aprendizaje, pero funciona bastante bien. El enfoque que prefiero en este momento es definir 4 niveles de prioridad. 4 = excepción no controlada (error en el registro de eventos), 3 = excepción manejada (advertencia en el registro de eventos), 2 = acceso a un recurso externo como un servicio web, db o sistema mainframe (información en el registro de eventos), 1 = detallado/cualquier otra cosa de interés (información en el registro de eventos).

Usando el bloque de aplicación, entonces es bastante fácil modificar el nivel de prioridad que desea registrar. Entonces, en desarrollo registraría todo, pero a medida que obtenga un sistema estable en producción, probablemente solo le interesarían las excepciones no controladas y posiblemente las excepciones manejadas.

Actualización: Para mayor claridad, le sugiero que inicie sesión tanto en su aplicación winform/wpf como en sus servicios web. En un escenario web, he tenido problemas en el pasado donde puede ser difícil relacionar un error en el cliente con los servidores de aplicaciones. Principalmente porque cualquier error a través de los servicios web queda envuelto como una excepción SOAP. No puedo recordarlo, pero creo que si usa un manejador de excepciones personalizado (que es parte de la biblioteca de la empresa) puede agregar datos a excepciones como la ID de instancia de manejo de la excepción del servidor de la aplicación. Esto hace que sea más fácil vincular excepciones en un cliente a su cuadro de aplicación utilizando LogParser (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).

Segunda actualización: También me gusta dar a cada evento diferente una identificación de evento separada y hacer un seguimiento de eso en un archivo de texto u hoja de cálculo bajo control de fuente. Sí, es un problema, pero si tienes la suerte de contar con un equipo de TI que cuide tus sistemas en producción, creo que tienden a esperar que los diferentes eventos tengan identificadores de eventos diferentes.

Answer 2

Como respuesta rápida, yo diría que se debe crear una serie de categorías y niveles de registro intercambiables, p. información, advertencia, error, crítico, etc.

Luego, facilite establecer el nivel de registro para ajustar el nivel de detalle que necesita. Por lo general, configure el nivel de registro en un archivo de configuración y detenga y reinicie la aplicación.

También publicaría a los desarrolladores cuál es el significado para cada uno de los niveles.

editar: También establecería un sistema para rotar, comprimir y archivar archivos de registro de forma regular, tal vez todas las noches.

Answer 3

Para una aplicación de escritorio típica, almacenaba todo en la sesión actual, y tal vez almacenaba mensajes de información para las últimas n sesiones o hasta x en tamaño.

Supongo que sus mensajes están organizados. Usamos 4 categorías; errores, advertencias, información y rastreo. Todavía estamos averiguando qué va en qué nivel. Como me estoy acostumbrando a analizar archivos de registro, generalmente digo "registrar más". No te preocupes por la legibilidad, probablemente tengas que procesar el archivo de registro un poco antes de que puedas usarlo.

Al final, encuentre un buen marco de registro que le permita controlar el uso de su spool en el tiempo de vida y espacio de almacenamiento, y una API adecuada que minimice el efecto en su código. Lo ideal es que escriba info("waaah") o warning("waah") y la API hace todo el etiquetado elegante para usted.

Answer 4

¿Es mejor ir hasta el final y todo lo que ingrese a través de múltiples intentos/día, o ingrese sólo lo que necesita (HDD dado es barato).

El hecho de que los discos duros son baratos en realidad no es una buena razón para registrar todo lo posible, por algunas razones ... Por un lado, con una aplicación muy ocupada, realmente no desea reducir la velocidad y atar discos escribe registros de escritura (los discos duros son bastante lentos). El segundo punto, y el más importante, hay muy poco que ganar con los terabytes que valen la pena. Para el desarrollo, pueden ser útiles, pero no es necesario que guardes más de unos minutos de ellos.

Algunos registros son útiles, tener diferentes niveles es la única forma de hacerlo; por ejemplo, debug() info() solo se registra si se solicita (en una configuración o indicador de línea de comando), y luego se puede advertir () y error() son enviadas a un archivo de registro

para la mayoría de las cosas que he escrito (guiones más bien pequeñas) por lo general sólo tienen una función de depuración(), que comprueba si se establece --verbose, e imprime el mensaje .. De esa manera puedo empujar la depuración ("algún valor:% s"% (avar)) cuando sea necesario, y no tener que preocuparme por volver y eliminar la depuración print() statem en cualquier parte del mundo.

Para aplicaciones web, generalmente solo uso los registros del servidor web para estadísticas y el registro de errores. Utilizo cosas como el registro de mod_rewrite cuando es necesario, pero sería idiota dejar esto habilitado más allá del desarrollo (ya que crea muchas líneas en cada solicitud de página)

Supongo que depende de la aplicación en sí, pero en general, para grande las aplicaciones usan múltiples niveles de registros que se pueden activar cuando sea necesario. Para cosas más pequeñas, un indicador --verbose o equivalente, para aplicaciones web, registra errores y (hasta cierto punto) registra éxitos.

Básicamente, en "producción" registre solo la información que puede usar, en el registro de desarrollo, todo lo que pueda necesitar para solucionar problemas.

Answer 5

This post on highscalability.com proporciona una buena perspectiva para iniciar sesión en un sistema distribuido a gran escala. (Y casualmente, comienza mencionando una publicación en JoelOnSoftware).

Answer 6

Al ser un administrador, realmente aprecio las aplicaciones que se registran en el Registro de eventos (preferiblemente el propio, de lo contrario el registro de la aplicación) para todos los registros, pero los registros de seguimiento.Al iniciar sesión en el registro de eventos, es mucho más probable que el personal administrativo encuentre y atienda las advertencias o los errores antes de que se conviertan en un problema importante (si es un problema que pueden resolver) o les permite ponerse en contacto. con los desarrolladores, que pueden usar los registros de seguimiento para seguir solucionando el problema.

Mi mayor problema para soportar una aplicación .NET personalizada en este momento es que hay 8 aplicaciones diferentes (algunas aplicaciones de consola, algunas formas de pago y algunas web) del mismo proveedor. Ninguno de ellos se registra en el registro de eventos, todos tienen sus propios archivos de registro personalizados. Pero para todas las formas de pago y las aplicaciones de consola, mantienen el archivo abierto mientras se ejecutan, por lo que no puedo supervisarlo en busca de problemas. Además, los registros están escritos de forma ligeramente diferente, por lo que tendría que analizarlos de forma diferente para obtener información útil.

Esto me obliga a controlar la apariencia de una aplicación (¿está respondiendo por los puertos en los que está activo, el proceso de trabajo es demasiado alto, etc.), en lugar de cuál es el estado de la aplicación? .

Por favor, tenga en cuenta las personas que mantienen su aplicación después de su implementación y proporcionan el registro que pueden usar. ¡Gracias!

Answer 7

Gracias chicos, mucha información buena, pero Martin me ha dado un poco más de detalles sobre cómo proceder. Le daré la respuesta, ya que parece que ahora que estamos fuera de las primeras páginas las respuestas caerán.