Nunca he escrito programas que hagan un uso significativo del registro. Lo más que he hecho es capturar los rastros de la pila cuando ocurren excepciones.
Me preguntaba, ¿cuánto registran otras personas? ¿Depende de qué tipo de aplicación está escribiendo? ¿Encuentras los registros realmente útiles?
Respuestas:
Por el trabajo que he realizado en gran parte de aplicaciones integradas, inicié sesión en una herramienta invaluable. Como mínimo, los errores deben registrarse con suficiente información para apuntar a la línea de código. A continuación, serían los principales puntos de función en toda la aplicación. Cosas como el administrador accedió a la máquina. Utilizamos un sistema que nos permite habilitar un registro más detallado. Esto suele ser específico del desarrollador. Puede usarse para ayudar al desarrollador durante la prueba de la característica o puede ayudar a diagnosticar un problema del cliente.
Personalmente he utilizado el registro en todas las aplicaciones que he desarrollado. Siempre ha llevado a una mejor comprensión del flujo de una aplicación. Especialmente cuando está en manos de un cliente. Nunca (rara vez) limitan sus casos de uso a aquellos con los que se prueba.
No creo que dependa del tipo de aplicación: el registro es útil en todas las aplicaciones (no triviales). Ciertamente, supongo, puede ser más útil en algunas aplicaciones que en otras, pero no creo que sea inútil .
En particular, en el caso de un error, un seguimiento de la pila le indicará el estado del programa en el punto exacto de falla, pero tiene muy poca pista sobre el estado justo antes del error. Esa información podría ser muy útil para rastrear el problema, y el registro puede proporcionar una información útil al respecto. Creo que es algo de lo que pueden beneficiarse todos los programas, excepto los más triviales.
Otro uso del registro, que podría no ser útil para todos los programas, es en el análisis estadístico. Por ejemplo, su servidor web generalmente registra cada solicitud que ingresa, y luego hay muchas herramientas que pueden analizar esos registros y producir gráficos de los momentos más ocupados, las páginas más populares, etc. Puede usar esos datos para planificar la capacidad ("¿Necesito un servidor más grande?") Y así sucesivamente.
Hay dos razones por las que se realiza el registro:
El registro de diagnóstico ya ha sido discutido por otros y no voy a hablar mucho más del tema. Solo diré que debe pensar mucho en lo que sucede si hay un error de registro. ¿Te importa lo suficiente como para lanzar una excepción a través de la aplicación o administrarla de otra manera? Este es un "depende", pero los mensajes de nivel de información de registro probablemente deberían omitirse.
El registro de auditoría es un requisito comercial. El registro de auditoría captura eventos importantes en el sistema y es en lo que están interesados la administración y las águilas legales. Esto es cosas como quién firmó algo, quién hizo qué ediciones, etc. Como administrador de sistemas o desarrollador que soluciona problemas del sistema, probablemente solo ligeramente interesado en estos. Sin embargo, en muchos casos este tipo de registro es absolutamente parte de la transacción y debería fallar toda la transacción si no se puede completar.
Pensar en los dos por separado es útil para mí no solo porque uno es "opcional" y el otro obligatorio, sino porque, según los requisitos, es posible que deba implementarlos por separado. Puede ser un caso (a veces) que ambas son frutas, pero una son manzanas y las otras naranjas. Por lo general, un solo marco de registro puede manejar ambos.
En la mayoría de las tareas del servidor, el registro es crucial, ya que el administrador generalmente no está allí cuando suceden cosas, por lo que debe verificarlo después de los hechos.
Pero, un tipo en Google me dijo una vez que los procesos de su servidor no registran; en cambio, están 'instrumentados'; eso significa que cada proceso tiene ganchos o puertos (no especificó la mecánica) donde otros procesos pueden enclavarse para solicitar parámetros y estadísticas. Son esos procesos de monitoreo los que almacenan muchas cosas en los registros, la ventaja es que la información que obtienen no es "abrir un archivo", "escribir esto", "buscar eso"; obtienen cosas como "45,453 archivos abiertos", "653 clientes del servicio X", "respuesta promedio de 344 ms para la consulta Y"
Ciertamente es un enfoque diferente, y uno que tiendo a tener en cuenta cuando cuido mis sistemas, incluso si son algunos órdenes de magnitud más pequeños.
Vengo de una aplicación winforms N-Tiered que registró todo.
No fue muy útil.
Claro, registrar excepciones es excelente; pero ¿por qué registrarlos en la máquina del cliente cuando puede enviar la excepción por correo electrónico al equipo de desarrollo?
La información de registro se convierte fácilmente en una adicción cuyo valor rara vez se justifica. Para cada situación en la que pueda iniciar sesión de forma gratuita, es mejor recopilar información específica y enviarla a donde la necesite.
Capturar información de excepción es imprescindible porque puede ser muy útil hasta cierto punto. Pero a veces la información de excepción no es suficiente, especialmente si el usuario / cliente de la aplicación no puede informar un error con la información adecuada.
¿El registro se limita solo a capturar información de error?
En mi caso (aplicación web), siempre registro qué página se visita, cuándo, en qué hacen clic, dónde está la IP y el navegador, etc. Incluso registro el tiempo de carga total para cada visita a la página, de modo que pueda saber qué páginas son lentas y necesita optimización. así que puedo decir que me conecto tanto como sea posible.
Al principio, no tenía idea de lo significativo que sería. pero aparentemente es muy útil en muchas cosas (aparte de la depuración):
Creo que el registro puede ser más significativo si nos encanta desenterrar información estadística en él.
Soy desarrollador en una empresa cuyos productos se implementan en el extranjero. Cuando un equipo de soporte pregunta por una definición de problema, mis únicas herramientas para el diagnóstico son mis archivos de registro y una copia de la base de datos del cliente. Utilizando la base de datos y mi entorno de desarrollo, tengo la oportunidad de reproducir el caso erróneo, porque registro los datos entrantes en mi módulo y las acciones relacionadas. Si puedo reproducir el error con la ayuda de los datos que recopilo, entonces puedo solucionarlo con la depuración. Si no tuviera archivos de registro, entonces tendría que depender de la descripción del cliente o del equipo de soporte de lo que sucede en qué caso (que tiene una gran posibilidad de engaño).
En segundo lugar, el registro me da la oportunidad de detectar los cuellos de botella de mi módulo en el sitio implementado, ya que registro la fecha y la hora de ciertas acciones y luego puedo ver qué acción consume cuánto tiempo.
Además de eso, supongamos que nuestra solución consta de 6 módulos y estoy viendo registros de errores en mis archivos de registro sobre los tiempos de espera de la base de datos. Si estos errores también se registran en 5 de los otros módulos, la probabilidad de que se trate de un problema relacionado con el servidor SQL aumenta. Si esto se registra solo en mi módulo, entonces la probabilidad de que mis consultas tengan errores aumenta. Creo que este tipo de cosas son indicadores útiles.
El tipo de datos que veo en mis archivos de registro depende de la configuración del nivel de registro. Si se trata de un producto nuevo, establecemos el nivel de registro en "Todos" para recopilar la mayor cantidad de datos posible. Pero cuando mejoramos el producto, podemos preferir mantener el nivel de registro en "Error" para registrar solo el error, pero no los registros de nivel de información, etc.
El registro es útil para la información que no puede obtener de otros programas:
Nota: desea al menos DOS archivos de registro.
El INFO uno siempre está encendido. La DEPURACIÓN está activada cuando es necesario.
Escriba el código de registro anticipando que algún día tendrá que depurar una situación en la que TODO lo que tiene es el archivo de registro, y hacerlo correctamente puede ser la diferencia entre ser despedido y ser promovido.
Para la milla extra, haga que todas las llamadas a funciones agreguen sus parámetros a cualquier seguimiento de pila, en Java con
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
Este enfoque esencialmente mejora su pila de llamadas con valores de parámetros y puede permitirle analizar la situación solo con el seguimiento de la pila y no tener que ver los archivos de registro.
También recomendaría que todas las aplicaciones no triviales empleen el registro multinivel.
Por las razones que otros han declarado, es una herramienta invaluable para resolver problemas con la aplicación.
En algunos casos, el registro es esencial, por ejemplo, en aplicaciones financieras y otros dominios que requieren registros de actividad, por seguridad, métricas de uso y auditoría.
Sin duda, depende del tipo de sistema que esté construyendo.
Si está escribiendo una aplicación de escritorio independiente, como un procesador de textos, entonces probablemente no necesite ningún registro.
Si está escribiendo un sistema incrustado, no puede vivir sin iniciar sesión. De lo contrario, cuando su dispositivo integrado se congela, no tiene idea de por qué. También necesita iniciar sesión cada vez que su sistema involucra múltiples procesos o múltiples máquinas físicas que se comunican entre sí. Nuevamente, cuando el sistema se cuelga, necesita saber qué parte de él murió, cuándo y por qué. Debe poder comparar registros para determinar si los datos llegaron o no a través de un proceso al otro. Del mismo modo, necesita iniciar sesión siempre que su sistema esté destinado a ejecutarse durante períodos prolongados sin mucha interacción directa del usuario.
El registro siempre es útil. Pero cuando implemente, tenga en cuenta que no es necesariamente usted, quien va a leer los registros. Quizás sea una especie de administrador, usuario final, cliente, equipo de soporte, ...
Por lo tanto, no solo registre los seguimientos de pila, sino también alguna información adicional que pueda ser interpretada por personas que no sean desarrolladores. Cuando otros grupos mantienen su aplicación, también es útil escribir algunos códigos de error únicos en sus registros. Esto podría facilitar el soporte, la automatización, ...
Otro punto desde la perspectiva del administrador: piense en la rotación de registros.