Recuerde que sus registros son parte de la interfaz de usuario. Son flujos de eventos interesantes y procesables que serán consumidos tanto por las máquinas como por los humanos.
La práctica más útil que he seguido hasta ahora es tener esto en cuenta y actuar en consecuencia: comprender los sistemas informáticos analizando, filtrando y analizando registros y hablando con todas las personas que serán notificadas cuando ocurra algo de interés. Observe lo que hacen y pregúntese “¿cómo podría ser más útil el resultado de mi aplicación en este escenario?”
Las partes interesadas en los registros de su aplicación generalmente están en conflicto: lo que es interesante y procesable para los desarrolladores y probadores no es tan importante para los ingenieros de soporte de producción, y sus declaraciones de temporización SQL probablemente se consideran basura para la herramienta de análisis en busca de problemas de seguridad.
- ¿Qué biblioteca PHP debo usar en el back-end de mi mini proyecto que será mejor que usar PHP simple sin ninguna biblioteca?
- ¿Qué es lo más divertido que has tenido programando / aprendiendo a programar? ¿Qué herramientas / programas estabas usando?
- ¿Necesito saber cómo codificar ampliamente para desarrollar un sitio web?
- ¿Cómo debo configurar un servidor web Linux CentOS hecho para aprender desarrollo web?
- ¿Qué es mejor jQuery, MooTools o Prototype?
Para minimizar eso, cualquier marco de registro que esté usando debería poder dirigir esas secuencias de eventos con filtros predefinidos (y con suerte, fácilmente configurables), y cada tipo de entorno o usuario debería poder tener su propia configuración .
Aquí hay algunos ejemplos para ilustrar el punto:
Durante el desarrollo, tiene sentido tener todas las declaraciones de depuración relevantes para el módulo que se está trabajando en ir a la misma secuencia, al tiempo que le dice al marco que lo tome con calma con todos los demás módulos. Los eventos de otros módulos pueden ser interesantes, pero deben filtrarse si no son procesables, ya que no va a hacer nada con ellos. Cambiar el filtro para que pueda ver los diferentes módulos no debería llevar más de unos segundos de trabajo (pero puede requerir el rebote de un servidor o dos).
Mientras ejecuta pruebas unitarias en una configuración de integración continua, puede tener sentido deshabilitar por completo el registro detallado: si su entorno de prueba automatizado es lo suficientemente maduro, al menos una de las pruebas se romperá y podrá reproducir la falla en una estación de trabajo de desarrollo para obtener detalles. En ese tipo de entorno, no solo desea tener en cuenta el uso del disco, los eventos en sí mismos generalmente no son muy procesables de todos modos.
En producción, deje esa configuración a las personas con experiencia en soporte: hable con los ingenieros que recibirán una llamada a las 3 a.m. y se apresurarán a una cabina si ocurre un tipo particular de error, y obtenga su opinión. Le dirán exactamente en qué tipo de errores están interesados en su aplicación en particular. Recuerde que esto probablemente sea específico para el dominio en el que está trabajando y que los ingenieros de soporte generalmente se encargan de más de una aplicación y de más de un servidor.
Un error muy común que veo (¡mirándote, JBoss!) Es tratar los errores que los desarrolladores deberían ver como importantes (una NullPointerException, por ejemplo) y que la gente de soporte de producción no puede hacer nada. No los despierte a menos que haya algo que puedan hacer para solucionar el problema, o corra el riesgo de llorar lobo demasiadas veces y recibir notificaciones importantes y procesables (errores de OutOfMemory, poco espacio en disco, etc.) ignorados.
