¿Por qué la mayoría de los archivos de registro usan texto sin formato en lugar de un formato binario?

El registro es algo que es necesario pero que se usa (relativamente) raramente. Como tal, puede hacerse mucho más compacto en términos de almacenamiento.

Por ejemplo, los datos más comúnmente registrados como ip, fecha, hora y otros datos que se pueden representar como un número entero se almacenan como texto.

Si el registro se almacenara como datos binarios, se podría preservar una gran cantidad de espacio, lo que requeriría menos rotación y una mayor vida útil del disco, especialmente con SSD donde las escrituras son limitadas.

Algunos pueden decir que es un problema tan pequeño que realmente no importa, pero teniendo en cuenta el esfuerzo necesario para construir dicho mecanismo, no tiene sentido no hacerlo. Cualquiera puede hacer esto durante dos días en su tiempo libre, ¿por qué la gente no hace esto?

systemdfamoso almacena sus archivos de registro en formato binario. Los principales problemas que he escuchado son:

1. si el registro se corrompe, es difícil de recuperar ya que necesita herramientas especializadas
2. que no son legibles, por lo que no puede utilizar las herramientas estándar, como vi, grep, tailetc., para analizarlas

La razón principal para usar un formato binario (que yo sepa) fue que se consideró más fácil crear índices, etc., es decir, tratarlo más como un archivo de base de datos.

Yo diría que la ventaja de espacio en disco es relativamente pequeña (y está disminuyendo) en la práctica. Si desea almacenar grandes cantidades de registros, comprimir los registros enrollados es realmente bastante eficiente.

En general, las ventajas de las herramientas y la familiaridad probablemente errarían en el lado del registro de texto en la mayoría de los casos.

¿Por qué la mayoría de los archivos de registro usan texto sin formato en lugar de un formato binario?

Busque la palabra "texto" en el artículo de Wikipedia sobre filosofía Unix , por ejemplo, encontrará declaraciones como:

McIlroy, entonces jefe del CSRC de Bell Labs (Centro de Investigación de Ciencias de la Computación) e inventor de la tubería Unix, [9] resumió la filosofía de Unix de la siguiente manera: [10]

Esta es la filosofía de Unix: escribir programas que hagan una cosa y que lo hagan bien. Escribir programas para trabajar juntos. Escriba programas para manejar secuencias de texto, porque esa es una interfaz universal.

O, por ejemplo, de Conceptos básicos de la filosofía de Unix ,

Regla de composición: Diseñe programas para conectarse con otros programas.

Es difícil evitar programar monolitos demasiado complicados si ninguno de sus programas puede comunicarse entre sí.

La tradición de Unix alienta firmemente a escribir programas que lean y escriban formatos simples, textuales, orientados a la transmisión e independientes del dispositivo. Bajo Unix clásico, la mayor cantidad de programas posibles se escriben como filtros simples, que toman una secuencia de texto simple en la entrada y la procesan en otra secuencia de texto simple en la salida.

A pesar de la mitología popular, esta práctica se ve favorecida no porque los programadores de Unix odien las interfaces gráficas de usuario. Es porque si no escribe programas que acepten y emitan secuencias de texto simples, es mucho más difícil unir los programas.

Las secuencias de texto son para herramientas Unix como los mensajes son para objetos en una configuración orientada a objetos. La simplicidad de la interfaz de flujo de texto impone la encapsulación de las herramientas. Las formas más elaboradas de comunicación entre procesos, como las llamadas a procedimientos remotos, muestran una tendencia a involucrar demasiado a los programas entre sí.

Cualquiera puede hacer esto durante dos días en su tiempo libre, ¿por qué la gente no hace esto?

Almacenar el archivo de registro en binario es solo el comienzo (y trivial). Luego necesitaría escribir herramientas para:

• Mostrar todo el archivo de registro ( edit)
• Mostrar el final del registro, sin leer el comienzo del mismo ( tail -f)
• Buscar cosas en el archivo ( grep)
• Filtra para mostrar solo cosas seleccionadas / interesantes (usando una expresión de filtro arbitrariamente complicada)
• Envíe el registro por correo electrónico a otra persona que no tenga su software de decodificador de archivos de registro
• Copie y pegue un fragmento del archivo de registro
• Lea el archivo de registro mientras el programa (que crea el archivo de registro) todavía se está desarrollando y depurando
• Lea los archivos de registro de versiones anteriores del software (que se implementan en los sitios de los clientes y se ejecutan).

Obviamente, el software también puede usar formatos de archivos binarios (por ejemplo, para bases de datos relacionales), pero no vale la pena (en un sentido YAGNI ), generalmente no vale la pena hacerlo, para los archivos de registro.

Hay muchas presunciones discutibles aquí.

El registro ha sido una parte integral de (casi) todos los trabajos que he tenido. Es esencial si desea algún tipo de visibilidad sobre el estado de sus aplicaciones. Dudo que sea un uso "marginal"; La mayoría de las organizaciones con las que he estado involucrado consideran los registros muy importantes.

Almacenar registros como binarios significa que debe decodificarlos antes de poder leerlos. Los registros de texto tienen la virtud de la simplicidad y facilidad de uso. Si está contemplando la ruta binaria, también podría almacenar registros en una base de datos, donde puede interrogarlos y analizarlos estadísticamente.

Los SSD son más confiables que los HDD hoy en día, y los argumentos en contra de muchas escrituras son en gran medida discutibles. Si realmente le preocupa, guarde sus registros en un HDD normal.

Los archivos de registro son una parte crítica de cualquier aplicación seria: si el registro en la aplicación es bueno, entonces le permiten ver qué eventos clave han sucedido y cuándo; qué errores han ocurrido; y el estado general de la aplicación que va más allá de cualquier monitoreo en el que se haya diseñado. Es común escuchar sobre un problema, verificar los diagnósticos integrados de la aplicación (abrir su consola web o usar una herramienta de diagnóstico como JMX), y luego recurrir a verificar el archivos de registro.

Si utiliza un formato que no es de texto, se enfrenta inmediatamente a un obstáculo: ¿cómo lee los registros binarios? ¡Con la herramienta de lectura de registros, que no está en sus servidores de producción! O lo es, pero querido, hemos agregado un nuevo campo y este es el viejo lector. ¿No probamos esto? Sí, pero nadie lo desplegó aquí. Mientras tanto, su pantalla comienza a encenderse con usuarios que le hacen ping.

¿O tal vez esta no es tu aplicación, pero estás brindando soporte y crees que sabes que es este otro sistema y WTF? los registros están en formato binario? Ok, comienza a leer páginas wiki y ¿por dónde empiezas? Ahora los he copiado en mi máquina local, pero ¿están dañados? ¿He realizado algún tipo de transferencia no binaria? ¿O la herramienta de lectura de registros está mal?

En resumen, las herramientas de lectura de texto son multiplataforma y omnipresentes, y los registros suelen ser de larga duración y, a veces, deben leerse rápidamente . Si inventas un formato binario, entonces estás aislado de todo un mundo de herramientas bien entendidas y fáciles de usar. Grave pérdida de funcionalidad justo cuando la necesita.

La mayoría de los entornos de registro tienen un compromiso: mantener los registros actuales legibles y presentes, y comprimir los más antiguos. Eso significa que obtendrá el beneficio de la compresión, más aún, de hecho, porque un formato binario no reduciría los mensajes de registro. Al mismo tiempo, puede usar menos y grep, etc.

Entonces, ¿qué posibles beneficios podrían surgir del uso de binarios? Una pequeña cantidad de eficiencia de espacio, cada vez menos importante. ¿Menos (o más pequeño) escribe? Bueno, tal vez, en realidad, el número de escrituras se relacionará con el número de confirmaciones de disco, por lo que si las líneas de registro son significativamente más pequeñas que el tamaño de bloque del disco, entonces un SSD asignaría nuevos bloques una y otra vez. Entonces, binario es una opción apropiada si:

• estás escribiendo grandes cantidades de datos estructurados
• los registros tienen que ser creados particularmente rápido
• es poco probable que necesite analizarlos en "condiciones de soporte"

pero esto suena menos como el registro de aplicaciones; Estos son archivos de salida o registros de actividad. Ponerlos en un archivo probablemente esté a solo un paso de escribirlos en una base de datos.

EDITAR

Creo que hay una confusión general entre los "registros de programa" (según los marcos de registro) y los "registros" (como en los registros de acceso, registros de inicio de sesión, etc.). Sospecho que la pregunta se relaciona más estrechamente con la última, y ​​en ese caso el problema está mucho menos definido. Es perfectamente aceptable que un registro de mensajes o registro de actividad esté en un formato compacto, especialmente porque es probable que esté bien definido y utilizado para el análisis en lugar de la resolución de problemas. Las herramientas que hacen esto incluyen tcpdumpel monitor del sistema Unix sar. Los registros de programas, por otro lado, tienden a ser mucho más ad hoc.

Un ejemplo de un registro algo binario está muy extendido: el registro de eventos de Windows. En el lado profesional, esto permite que los mensajes de registro sean bastante verbales (y, por lo tanto, con suerte útiles) prácticamente sin costo, posiblemente algo así como

Advertencia: la cola de foobars para hacer ha crecido en 517 artículos en los últimos 90 segundos. Si esto sucede aproximadamente una vez al día, no hay nada de qué preocuparse. Si ocurre con más frecuencia o en una sucesión rápida, es posible que desee verificar la cantidad de RAM disponible para la aplicación foobar. Sin embargo, si ocurre junto con el evento 12345, parece que está utilizando una base de datos obsoleta y es mejor que llame al soporte al + 1-555-12345 para evitar la pérdida de datos.

La parte principal de este mensaje existe solo una vez como recurso instalado con la aplicación. Sin embargo, si este recurso no está instalado correctamente (por ejemplo, porque mientras se ha instalado una versión más nueva que ya no es compatible con este mensaje obsoleto), todo lo que ve en el registro de eventos es un mensaje estándar que es solo una redacción elegante para

No sé, algo con "517" y "90".

y ya no es útil de ninguna manera.

Las dos preguntas principales que desea hacer antes de elegir entre texto y binario son:

• ¿Quien es mi audiencia?
• ¿Qué contenido necesito transmitir?

Una opinión común es que la audiencia de un mensaje de registro es un ser humano. Obviamente, esta no es una suposición perfecta, porque hay muchos scripts de rastreo de registros, pero es común. En este caso, tiene sentido transmitir la información en un medio con el que los humanos se sientan cómodos. El texto tiene una larga tradición de ser este medio.

En cuanto al contenido, considere que un registro binario debe tener un formato bien definido. El formato debe estar lo suficientemente bien definido como para que otras personas puedan escribir software que opere en esos registros. Algunos registros están bastante bien estructurados (su pregunta enumera varios). Otros registros necesitan la capacidad de transmitir contenido en una forma de lenguaje natural menos bien definida. Tales casos de lenguaje natural no coinciden con los formatos binarios.

Para los registros que podrían describirse bien en binario, debe elegir. Como el texto funciona para todos, a menudo se considera la opción predeterminada. Si registra sus resultados en texto, las personas pueden trabajar con sus registros. Se ha demostrado miles de veces. Los archivos binarios son más complicados. Como resultado, puede ser que los desarrolladores generen texto simplemente porque todos saben cómo se comportará.

TL; DR: el tamaño realmente no importa, pero la comodidad de uso sí

En primer lugar, si bien comparar las ventajas respectivas de los formatos de texto y binarios para el almacenamiento de registros a corto plazo es una pregunta importante, el tamaño realmente no importa. Las dos razones para esto son:

1. Los registros son información altamente redundante que se comprimirá muy bien: en mi experiencia, no es raro ver archivos de registro comprimidos cuyo tamaño es 5% o menos del tamaño del archivo original. En consecuencia, el uso de un formato de texto o binario no debería tener ningún impacto medible en el almacenamiento de registros a largo plazo.

2. Independientemente del formato que elijamos, los registros llenarán rápidamente un disco del servidor si no implementamos un "sumidero de archivos de registro" que comprime y envía los archivos de registro a una plataforma de almacenamiento a largo plazo. El uso de un formato binario podría ralentizar esto un poco, pero incluso un cambio por un factor 10 no importaría demasiado.

Texto versus formatos de registro binario

La promesa de los sistemas Unix es que, si aprendemos a usar el conjunto de herramientas estándar trabajando en archivos de texto estructurados en líneas, como grep , sort , join , sed y awk , podremos usarlos para ensamblar rápidamente prototipos que realicen cualquier trabajo queremos, aunque de forma lenta y cruda. Una vez que el prototipo ha demostrado su utilidad, podemos optar por convertirlo en un software realmente diseñado para obtener rendimiento o agregar otras características útiles. Esta es, al menos en mi opinión, la esencia de la filosofía de Unix.

Para decirlo de otra manera, si es probable que necesitemos realizar tratamientos y análisis que no podemos resolver hoy, si no sabemos quién debe implementar este análisis, etc., entonces estamos en la etapa en la que se deben usar prototipos y formatos de texto para Los registros son probablemente óptimos. Si necesitamos realizar repetidamente un pequeño conjunto de tratamientos bien identificados, entonces estamos en la situación en la que debemos diseñar un sistema de software perenne para realizar este análisis y es probable que haya formatos binarios o estructurados para registros, como bases de datos relacionales. óptimo

(Hace algún tiempo, escribí una publicación de blog sobre esto).

Los archivos de registro están en formato de texto porque se pueden leer fácilmente utilizando cualquier tipo de editor de texto o mostrando el contenido mediante el comando de la consola.

Sin embargo, algunos archivos de registro están en formato binario si hay muchos datos. Por ejemplo, el producto en el que estoy trabajando almacena un máximo de 15000 registros. Para almacenar los registros en la menor cantidad de espacio, se almacenan en binario. Sin embargo, se debe escribir una aplicación especial para ver los registros o convertirlos a un formato que pueda usarse (por ejemplo, hojas de cálculo).

En resumen, no todos los archivos de registro están en formato de texto. El formato de texto tiene la ventaja de que no se necesitan herramientas personalizadas para ver el contenido. Cuando hay muchos datos, el archivo puede estar en formato binario . El formato binario necesitará una aplicación (personalizada) para leer los datos y mostrarlos en un formato legible por humanos. Se pueden empaquetar más datos en formato binario. El uso de formato textual o binario es una decisión basada en la cantidad de datos y la facilidad de visualización de los contenidos.

En los sistemas integrados en los que podría no tener un canal de salida disponible durante el tiempo de ejecución, la aplicación no puede permitirse el golpe de velocidad impuesto por el registro, o el registro alteraría o enmascararía el efecto que estoy tratando de grabar, a menudo recurrió a rellenar datos binarios en una matriz o un búfer en anillo, y luego imprimirlos () al final de la ejecución de la prueba o volcarlos sin procesar y escribir un intérprete para imprimirlo como legible. De cualquier manera, quiero terminar con datos legibles.

En sistemas con más recursos, ¿por qué inventar esquemas para optimizar lo que no necesita optimización?

Los archivos de registro están destinados a ayudar a la depuración de problemas. Por lo general, el espacio en el disco duro es mucho más barato que el tiempo de ingeniería. Los archivos de registro usan texto porque hay muchas herramientas para trabajar con texto (como tail -f). Incluso HTTP usa texto sin formato (vea también por qué no enviamos binarios en lugar de texto en http ).

Además, es más barato desarrollar un sistema de registro de texto sin formato y verificar que funciona, más fácil de depurar si sale mal y más fácil recuperar cualquier información útil en caso de que el sistema falle y corrompa parte del registro.

Un archivo de texto dañado todavía es legible alrededor de la parte dañada. Un archivo binario dañado puede ser restaurable, pero también podría no serlo. Incluso si es restaurable, requeriría un poco más de trabajo. La otra razón es que un formato de registro binario hace que sea menos probable que durante una prisa por crear un "arreglo temporal" (también conocido como "el más permanente de todos los arreglos") la solución de registro se utilizará en lugar de algo que se pueda crear más rápido.

Contamos con pruebas unitarias para lograr y mantener la solidez de nuestro software. (La mayor parte de nuestro código se ejecuta en un servidor, sin cabeza; el análisis posterior a la operación de los archivos de registro es una estrategia clave). Casi todas las clases en nuestra implementación realizan algunos registros. Una parte importante de nuestras pruebas unitarias es el uso de registradores 'simulados' que se utilizan cuando se realizan pruebas unitarias. Una prueba unitaria crea un registrador simulado y lo proporciona al elemento que se está probando. Luego (cuando sea útil / apropiado) analiza lo que se registró (especialmente errores y advertencias). El uso de un formato de registro basado en texto hace que esto sea mucho más fácil por las mismas razones que los análisis realizados en registros 'reales': hay más herramientas a su disposición que son rápidas de usar y adaptar.

Históricamente, los registros eran registros oficiales, escritos a mano y secuenciales de eventos. Cuando la maquinaria se volvió capaz de grabar eventos, estos se escribieron en un dispositivo de salida de copia impresa, como una impresora de teletipo, que producía un registro secuencial permanente pero que solo podía procesar texto y ocasionalmente sonar un BELL ...

En mis días de mainframe, utilizamos un formato de registro binario personalizado. La razón principal no fue para ahorrar espacio, fue porque queríamos que el registro ocupara espacio finito al sobrescribir las entradas antiguas con otras nuevas; Lo último que queríamos era no poder diagnosticar los problemas causados ​​por el llenado de los discos (en 1980 el espacio en disco costaba $ 1000 / Mb, por lo que las personas no compraron más de lo que necesitaban).

Ahora todavía me gusta la idea de un archivo de registro circular, y si los sistemas operativos ofrecieran tal bestia, lo usaría sin dudarlo. Pero binario fue una mala idea. Realmente no desea perder tiempo buscando los comandos correctos para descifrar un archivo de registro cuando tenga un problema crítico que resolver.