Cuándo utilizar los diferentes niveles de registro
Hay diferentes formas de registrar mensajes, en orden de fatalidad:
FATALERRORWARNINFODEBUGTRACE
¿Cómo decido cuándo usar cuál?
¿Cuál es una buena heurística para usar?
Generalmente me suscribo a la siguiente convención:
- Seguimiento : solo cuando estaría "rastreando" el código e intentando encontrar una parte de una función específicamente.
- Depuración : información que resulta útil desde el punto de vista del diagnóstico para personas no solo desarrolladores (TI, administradores de sistemas, etc.).
- Información : información generalmente útil para registrar (inicio/detención del servicio, supuestos de configuración, etc.). Información que quiero tener siempre disponible pero que normalmente no me importa en circunstancias normales. Este es mi nivel de configuración listo para usar.
- Advertencia : cualquier cosa que pueda causar anomalías en la aplicación, pero que me esté recuperando automáticamente. (Como cambiar de un servidor principal a uno de respaldo, reintentar una operación, faltar datos secundarios, etc.)
- Error : cualquier error que sea fatal para la operación , pero no para el servicio o la aplicación (no se puede abrir un archivo requerido, faltan datos, etc.). Estos errores obligarán a la intervención del usuario (administrador o usuario directo). Generalmente están reservados (en mis aplicaciones) para cadenas de conexión incorrectas, servicios faltantes, etc.
- Fatal : cualquier error que obligue a cerrar el servicio o la aplicación para evitar la pérdida de datos (o una mayor pérdida de datos). Los reservo sólo para los errores y situaciones más atroces en las que se garantiza que se han producido daños o pérdida de datos.
¿Le gustaría que el mensaje sacara a un administrador del sistema de la cama en medio de la noche?
- si -> error
- no -> advertir
Es un tema antiguo, pero sigue siendo relevante. Esta semana escribí un pequeño artículo al respecto para mis colegas. Para ello, también creé esta hoja de trucos, porque no pude encontrar ninguna en línea.
Me resulta más útil pensar en la gravedad desde la perspectiva de ver el archivo de registro.
Fatal/Crítico : falla general de la aplicación o del sistema que debe investigarse de inmediato. Sí, active SysAdmin. Dado que preferimos que nuestros SysAdmins estén alerta y bien descansados, esta gravedad debe usarse con muy poca frecuencia. Si sucede a diario y no es un BFD, ha perdido su significado. Normalmente, un error fatal solo ocurre una vez durante la vida del proceso, por lo que si el archivo de registro está vinculado al proceso, este suele ser el último mensaje del registro.
Error : Definitivamente es un problema que debe investigarse. SysAdmin debería ser notificado automáticamente, pero no es necesario sacarlo de la cama. Al filtrar un registro para ver los errores y superiores, se obtiene una descripción general de la frecuencia de los errores y se puede identificar rápidamente la falla inicial que podría haber resultado en una cascada de errores adicionales. El seguimiento de las tasas de error en comparación con el uso de la aplicación puede generar métricas de calidad útiles, como el MTBF, que se pueden utilizar para evaluar la calidad general. Por ejemplo, esta métrica podría ayudar a fundamentar las decisiones sobre si se necesita o no otro ciclo de prueba beta antes de un lanzamiento.
Advertencia : Esto PODRÍA ser un problema o no. Por ejemplo, las condiciones ambientales transitorias esperadas, como una breve pérdida de conectividad de la red o de la base de datos, deben registrarse como Advertencias, no como Errores. Ver un registro filtrado para mostrar solo advertencias y errores puede brindar información rápida sobre las primeras pistas sobre la causa raíz de un error posterior. Las advertencias deben utilizarse con moderación para que no pierdan sentido. Por ejemplo, la pérdida de acceso a la red debería ser una advertencia o incluso un error en una aplicación de servidor, pero podría ser simplemente una información en una aplicación de escritorio diseñada para usuarios de portátiles que se desconectan ocasionalmente.
Información : Esta es información importante que debe registrarse en condiciones normales, como inicialización exitosa, inicio y detención de servicios o finalización exitosa de transacciones importantes. Ver un registro que muestra información y más debería brindar una descripción general rápida de los principales cambios de estado en el proceso, proporcionando un contexto de alto nivel para comprender cualquier advertencia o error que también ocurra. No tenga demasiados mensajes de información. Normalmente tenemos < 5 % de mensajes de información relacionados con Trace.
Seguimiento : el seguimiento es, con diferencia, la gravedad más utilizada y debe proporcionar contexto para comprender los pasos que conducen a errores y advertencias. Tener la densidad adecuada de mensajes Trace hace que el software sea mucho más fácil de mantener, pero requiere cierta diligencia porque el valor de las declaraciones Trace individuales puede cambiar con el tiempo a medida que evolucionan los programas. La mejor manera de lograrlo es acostumbrar al equipo de desarrollo a revisar periódicamente los registros como parte estándar de la resolución de problemas informados por los clientes. Aliente al equipo a eliminar los mensajes de seguimiento que ya no brindan un contexto útil y a agregar mensajes cuando sea necesario para comprender el contexto de los mensajes posteriores. Por ejemplo, suele resultar útil registrar las entradas del usuario, como cambios de pantalla o pestañas.
Depurar : consideramos Depurar <Traza. La diferencia es que los mensajes de depuración se compilan a partir de versiones de lanzamiento. Dicho esto, desaconsejamos el uso de mensajes de depuración. Permitir mensajes de depuración tiende a generar que se agreguen más y más mensajes de depuración y que ninguno se elimine. Con el tiempo, esto hace que los archivos de registro sean casi inútiles porque es demasiado difícil filtrar la señal del ruido. Eso hace que los desarrolladores no utilicen los registros, lo que continúa la espiral de muerte. Por el contrario, la poda constante de mensajes Trace anima a los desarrolladores a utilizarlos, lo que da como resultado una espiral virtuosa. Además, esto elimina la posibilidad de que se introduzcan errores debido a efectos secundarios necesarios en el código de depuración que no está incluido en la versión de lanzamiento. Sí, sé que eso no debería suceder en un buen código, pero más vale prevenir que lamentar.
