Usando un Servidor SQL para el registro de aplicaciones. ¿Pros contras?

logging text-files (11)

Tengo una aplicación multiusuario que mantiene un archivo de registro centralizado para la actividad. En este momento, ese registro va a archivos de texto por una suma de alrededor de 10MB-50MB / día. Los archivos de texto son rotados diariamente por el registrador, y mantenemos el valor de los últimos 4 o 5 días. Más viejo que eso no nos interesa.

Se leen raramente: cuando se desarrolla la aplicación para mensajes de error, mensajes de diagnóstico o cuando la aplicación está en producción para hacer un triage en un problema reportado por el usuario o un error.

(Esto es estrictamente un registro de aplicación. El registro de seguridad se mantiene en otro lugar).

Pero cuando se leen, son un dolor en el culo. La ampliación de archivos de texto de 10 MB no es divertida, incluso con Perl: los campos (ID de transacción, ID de usuario, etc.) en el archivo son útiles, pero solo texto. Los mensajes se escriben de forma secuencial, uno a la vez, por lo que la actividad intercalada se mezcla al intentar seguir una transacción o usuario en particular.

Estoy buscando ideas sobre el tema. ¿Alguien hizo un registro a nivel de aplicación con una base de datos SQL y le gustó? ¿Lo odié?

He estado leyendo todas las respuestas y son geniales. Pero en una empresa que trabajé debido a varias restricciones y auditorías, era obligatorio iniciar sesión en una base de datos. De todos modos, teníamos varias formas de iniciar sesión y la solución era instalar una tubería donde nuestros programadores pudieran conectarse a la tubería e iniciar sesión en la base de datos, archivo, consola o incluso reenviar el registro a un puerto para ser consumido por otras aplicaciones. Esta interconexión no interrumpe el proceso normal y mantener un archivo de registro al mismo tiempo que inicia sesión en la base de datos garantiza que rara vez pierda una línea. Le sugiero que investigue más en log4net que es genial para esto.

http://logging.apache.org/log4net/

Creo que el problema que tiene con el registro podría resolverse con el registro en SQL, siempre que pueda dividir los campos que le interesan en columnas diferentes. No puede tratar la base de datos SQL como un campo de texto y esperar que sea mejor, no lo hará.

Una vez que obtiene todo lo que le interesa para iniciar sesión en las columnas que desea, es mucho más fácil hacer un seguimiento de las acciones secuenciales de algo al poder aislarlo por columna. Como si tuvieras un proceso de "entrada", registras todo normalmente y el texto "proceso de entrada" se coloca en la columna "logtype" o en la columna "process". Luego, cuando tiene problemas con el "proceso de entrada", una declaración WHERE en esa columna aísla todos los procesos de entrada.

Hemos utilizado el registro centralizado de SQL Server antes, y como se mencionó en la publicación anterior, el mayor problema fue que la conectividad interrumpida a la base de datos significaba la interrupción del registro. De hecho, terminé agregando una rutina de cola al registro que probaría primero la base de datos y escribiría en un archivo físico si fallara. Simplemente tendría que agregar código a esa rutina que, en un registro exitoso en la base de datos, verificará si hay otras entradas en cola localmente y las escribirá también.

Me gusta tener todo en una base de datos, a diferencia de los archivos de registro físicos, pero solo porque me gusta analizarlos con informes que he escrito.

Pude ver que funcionaba bien, siempre que tuvieras la capacidad de filtrar lo que se debe registrar y cuándo se debe registrar. Un archivo de registro (o una tabla, tal como está) es inútil si no puede encontrar lo que está buscando o si contiene información innecesaria.

Creo que iniciar sesión directamente en una base de datos suele ser una mala idea, y lo evitaría.

La razón principal es esta: un buen registro será más útil cuando puede usarlo para depurar su aplicación post-mortem, una vez que el error ya ha ocurrido y no puede reproducirlo. Para poder hacer eso, debe asegurarse de que el registro sea confiable. Y para que cualquier sistema sea confiable, un buen comienzo es mantenerlo simple.

Así que tener un registro simple basado en archivos con solo unas pocas líneas de código (abrir archivo, agregar línea, cerrar archivo o mantenerlo abierto, repetir ...) generalmente será más confiable y útil en el futuro, cuando realmente lo necesite trabajar.

Por otro lado, iniciar sesión correctamente en un servidor SQL requerirá que muchos más componentes funcionen correctamente, y habrá muchas más situaciones de error posibles en las que no podrá registrar la información que necesita, simplemente porque la infraestructura de registro en sí mismo no estará funcionando. Y algo peor: una falla en el procedimiento de registro (como una corrupción de base de datos o un punto muerto) probablemente afectará el rendimiento de la aplicación, y entonces tendrá una situación donde un componente secundario impide que la aplicación realice su función principal.

Si necesita hacer un gran análisis de los registros y no se siente cómodo usando herramientas basadas en texto como grep, guarde los registros en archivos de texto e impórtelos periódicamente a una base de datos SQL. Si el SQL falla, no perderá ninguna información de registro, y ni siquiera afectará la capacidad de la aplicación para funcionar. Luego puede hacer todo el análisis de datos en la base de datos.

Creo que esas son las razones principales por las que no hago el registro en una base de datos, aunque lo hice en el pasado. Espero eso ayude.

Sí, lo hacemos aquí, y no puedo soportarlo. Un problema que tenemos aquí es si hay un problema con el DB (conexión, etc. corrupto), se detiene todo el registro. Mi otro gran problema es que es difícil de seguir para rastrear problemas. También tenemos problemas aquí con los registros de tabla ocupando demasiado espacio y teniendo que preocuparse por truncarlos cuando movemos bases de datos porque nuestros registros son muy grandes.

Creo que es torpe en comparación con los archivos de registro. Me resulta difícil ver el "panorama general" con el que se almacena en la base de datos. Admitiré que soy una persona de archivo de registro, me gusta poder abrir un archivo de texto y revisar (regex) en lugar de usar sql para intentar buscar algo.

El último lugar donde trabajé teníamos archivos de registro de 100 meg más. Son un poco difíciles de abrir, pero si tienes la herramienta adecuada no es tan malo. Tuvimos un sistema para registrar mensajes también. Puede mirar rápidamente el archivo y determinar qué conjunto de entradas de registro pertenecía a qué proceso.

lo hacemos en nuestra organización en grandes volúmenes con SQL Server. En mi apertura, escribir en la base de datos es mejor debido a la capacidad de búsqueda y filtro. Rendimiento de 10 a 50 MB de datos y mantenerlo solo durante 5 días, no afecta su aplicación. La transacción de seguimiento y los usuarios serán muy fáciles de comparar con el seguimiento desde un archivo de texto, ya que puede filtrar por transacción o por usuario.

Usted menciona que los archivos se leen raramente. Entonces, decida si vale la pena invertir tiempo en el desarrollo para desarrollar el marco de registro. Calcule su tiempo dedicado a buscar los registros de los archivos de registro en un año frente al tiempo que le llevará codificar y probar. Si el gasto de tiempo es de 1 hora o más por día para los registros de búsqueda, es mejor descargar los registros en la base de datos. Lo cual puede reducir drásticamente el tiempo invertido en resolver problemas.

Si pasas menos de una hora puedes usar algunas herramientas de búsqueda de texto como "SRSearch", que es una gran herramienta que utilicé, busca desde múltiples archivos en una carpeta y te da los resultados en pequeños snippts ("como el resultado de la búsqueda de Google" "), donde hace clic para abrir el archivo con el resultado interesado. También hay otras herramientas de búsqueda de texto disponibles. Si el entorno es Windows, también tiene Microsoft LogParser, una buena herramienta disponible gratis donde puede consultar su archivo como una base de datos si el archivo está escrito en un formato específico.

Puede iniciar sesión en un formato de texto delimitado por comas o tabulaciones, o permitir que sus registros se exporten a un formato CSV. Cuando necesite leer de un registro, exporte su archivo CSV a una tabla en su servidor SQL, entonces puede consultar con sentencias SQL estándar. Para automatizar el proceso, puede usar SQL Integration Services.

Como sus registros se leen raramente, los escribiría en un archivo (mejor rendimiento y confiabilidad).

Luego, si y solo si necesita leerlos, importaría el archivo de registro en una base de datos (mejor análisis).

Al hacerlo, obtienes las ventajas de ambos métodos.

Aquí hay algunos pros y contras adicionales y la razón por la que prefiero los archivos de registro en lugar de las bases de datos:

El espacio no es tan barato cuando se usan VPS. Recuperar espacio en sistemas de bases de datos en vivo es a menudo una gran molestia y es posible que tenga que cerrar servicios mientras recupera espacio. Si sus registros son tan importantes que debe guardarlos durante años (como nosotros), entonces este es un problema real. Recuerde que la mayoría de las bases de datos no recuperan espacio cuando elimina datos, ya que simplemente reutilizan el espacio, lo cual no es de mucha ayuda si se está quedando sin espacio.
Si accede a los registros con mayor frecuencia y tiene que extraer informes diarios de una base de datos con una enorme tabla de registro y millones y millones de registros, tendrá impacto en el rendimiento de los servicios de su base de datos mientras consulta los datos de la base de datos.
Los archivos de registro se pueden crear y los registros más antiguos se archivan diariamente. Según el tipo de registros, se pueden recuperar grandes cantidades de espacio archivando registros. Ahorramos alrededor de 6 veces el espacio cuando comprimimos nuestros registros y, en la mayoría de los casos, probablemente ahorremos mucho más.
Los archivos de registro individuales más pequeños se pueden comprimir y transferir fácilmente sin afectar el servidor. Anteriormente teníamos registros que abarcaban los 100 de GB de datos en una base de datos. Mover estas grandes bases de datos entre servidores se convierte en una gran molestia, especialmente debido al hecho de que debe cerrar el servidor de la base de datos mientras lo hace. Lo que estoy diciendo es que el mantenimiento se convierte en un verdadero dolor el día que tienes que comenzar a mover grandes bases de datos.
Escribir para registrar archivos en general es mucho más rápido que escribir en DB. No subestime la velocidad de su archivo de sistema operativo IO.
Los archivos de registro solo son malos si no estructura sus registros correctamente. Puede que tenga que usar herramientas adicionales e incluso puede tener que desarrollar las suyas propias para ayudar a procesarlas, pero al final valdrá la pena.

Usamos una base de datos de registro en mi último trabajo, y fue genial.

Habíamos almacenado procedimientos que arrojaban resúmenes de la salud general del sistema para diferentes métricas que podía cargar desde una página web. También podríamos escupir rápidamente un rastro para una aplicación determinada durante un período determinado, y si lo quería era fácil obtenerlo como un archivo de texto, si realmente le gusta grep-ing archivos.

Para garantizar que el sistema de registro no se convierta en un problema, existe un marco de código común que usamos entre las diferentes aplicaciones que manejan la escritura en la tabla de registro. Parte de ese marco también incluía el inicio de sesión en un archivo, en caso de que el problema sea con la base de datos en sí, y parte de ello implica el ciclo de los registros. En cuanto a los problemas de espacio, la base de datos de registro está en un calendario de copia de seguridad diferente, y realmente no es un problema. El espacio (sin copia de seguridad) es barato.

Creo que eso resuelve la mayoría de las preocupaciones expresadas en otros lugares. Todo es una cuestión de implementación. Pero si me detuviera aquí, todavía sería un caso de "no mucho peor", y esa es una mala razón para tomarse la molestia de configurar el registro de DB. Lo que me gustó de esto es que nos permitió hacer algunas cosas nuevas que serían mucho más difíciles de hacer con los archivos planos.

Hubo cuatro mejoras principales sobre los archivos. La primera son las descripciones generales del sistema que ya he mencionado. El segundo, y lo más importante, era un control para ver si a alguna aplicación le faltaban mensajes en los que normalmente esperaríamos encontrarlos. Ese tipo de cosas es casi imposible de detectar en el registro tradicional de archivos, a menos que pases mucho tiempo revisando diarios que te den a entender en las aplicaciones que te dicen que todo está bien el 99% del tiempo. Es sorprendente cómo es la liberación de la vista para mostrar las entradas de registro faltantes. La mayoría de los días no necesitábamos ver la mayoría de los archivos de registro en absoluto ... algo que sería peligroso e irresponsable sin la base de datos.

Eso trae a colación la tercera mejora. Generamos un solo correo electrónico de estado diario, y era lo único que necesitábamos revisar los días en que todo funcionaba normalmente. El correo electrónico incluido mostró errores y advertencias. Los registros perdidos se volvieron a registrar como advertencia por el mismo trabajo de DB que envía el correo electrónico, y la falta de correo electrónico fue un gran problema. Podríamos enviar un mensaje de registro en particular a nuestro rastreador de errores con un solo clic, directamente desde el correo electrónico diario (tenía formato html, datos extraídos de una aplicación web).

La mejora final fue que si queríamos seguir más de cerca una aplicación específica, por ejemplo, después de hacer un cambio, podríamos suscribirnos a una fuente RSS para esa aplicación específica hasta que estuviéramos satisfechos. Es más difícil hacer eso desde un archivo de texto.

Donde estoy ahora, confiamos mucho más en herramientas de terceros y sus capacidades de registro, y eso significa volver a revisar mucho más el manual. Extraño mucho el DB, y estoy contemplando escribir una herramienta para leer esos registros y volver a registrarlos en un DB para recuperar estas habilidades.

Nuevamente, hicimos esto con los archivos de texto como una alternativa, y son las nuevas habilidades las que realmente hacen que la base de datos valga la pena. Si todo lo que vas a hacer es escribir en un DB e intentar usarlo de la misma forma que lo hiciste con los archivos de texto antiguos, agrega complejidad innecesaria y también puedes usar los archivos de texto antiguos. Es la capacidad de construir el sistema para las nuevas características que hace que valga la pena.