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

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

1. si el registro se daña, es difícil recuperarlo ya que necesita herramientas especializadas
2. no son legibles por humanos, por lo que no puedes usar herramientas estándar como vi , grep , tail etc. para analizarlos

La principal razón para usar un formato binario (que yo sepa) era que se consideraba más fácil para crear índices, por ejemplo, para 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 disminuye) en la práctica. Si desea almacenar grandes cantidades de registros, comprimir los registros enrollados es realmente muy eficiente.

En general, las ventajas de las herramientas y la familiaridad probablemente se 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 utilizan texto sin formato en lugar de un formato binario?

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

  

McIlroy, entonces jefe de la CSRC de Bell Labs (Centro de Investigación de Ciencias de Computación) e inventor de la tubería de 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 flujos de texto, ya que 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 la programación de monolitos demasiado complicados si ninguno de   Sus programas pueden comunicarse entre sí.

     

La tradición de Unix recomienda encarecidamente escribir programas que lean y   escribe formatos simples, textuales, orientados a la corriente e independientes del dispositivo.   Bajo el Unix clásico, tantos programas como sea posible están escritos como simples   filtros, que toman una corriente de texto simple en la entrada y la procesan en   otro flujo de texto simple en la salida.

     

A pesar de la mitología popular, esta práctica se favorece no porque Unix   Los programadores odian las interfaces gráficas de usuario. Es porque si no lo haces.   escribir programas que acepten y emitan flujos de texto simples, es mucho   Más difícil es enlazar los programas.

     

Las secuencias de texto son para las herramientas de Unix como los mensajes para los objetos en una   Entorno orientado a objetos. La simplicidad de la interfaz de flujo de texto.   Hace cumplir la encapsulación de las herramientas. Formas más elaboradas de   La comunicación entre procesos, como las llamadas a procedimientos remotos, muestran una   tendencia a involucrar programas con los internos de los demás demasiado.

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

Almacenar el archivo de registro en binario es solo el principio (y trivial). Entonces necesitarías escribir herramientas para:

• Mostrar todo el archivo de registro ( edit )
• Muestra el final del registro, sin leer el principio ( tail -f )
• Buscar material en el archivo ( grep )
• Filtrar para mostrar solo las 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 registro-archivo-decodificador
• Copie y pegue un fragmento del archivo de registro
• Lea el archivo de registro mientras el programa (que crea el archivo de registro) aún 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 y usa formatos de archivo binarios (por ejemplo, para bases de datos relacionales) pero no vale la pena (en YAGNI sense), generalmente no vale la pena hacerlo, para archivos de registro.

Hay muchas suposiciones discutibles aquí.

El registro ha sido una parte integral de (casi) todos los trabajos que he tenido. Es esencial si desea cualquier tipo de visibilidad en la salud de sus aplicaciones. Dudo que sea un uso "marginal"; La mayoría de las organizaciones en las que he participado consideran que los registros son muy importantes.

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

Los SSD son más confiables que los HDD en la actualidad, y los argumentos en contra de muchas escrituras son en gran medida discutibles. Si está realmente preocupado por eso, almacene sus registros en un disco duro 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 ocurrido y cuándo; qué errores han ocurrido; y el estado general de la aplicación que va más allá de lo que se haya diseñado en el monitoreo. Es común escuchar acerca de un problema, verificar los diagnósticos incorporados de la aplicación (abrir su consola web o usar una herramienta de diagnóstico como JMX) y luego recurrir a archivos de registro.

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

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

En resumen, las herramientas de lectura de texto son multiplataforma y ubicuas, y los registros suelen ser de larga duración y, a veces, deben leerse con prisa . Si inventas un formato binario, 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 se ponen en peligro: mantenga los registros actuales legibles y presentes, y comprima los más antiguos. Eso significa que obtiene 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 utilizar less y grep y así sucesivamente.

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 una SSD asignará nuevos bloques una y otra vez. Entonces, binario es una opción apropiada si:

• estás escribiendo grandes cantidades de datos estructurados
• los registros deben crearse particularmente rápido
• es poco probable que necesite analizarlos bajo "condiciones de soporte"

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

EDIT

Creo que hay una confusión general entre "registros de programa" (según los marcos de registro) vs "registros" (como en 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 tema está mucho menos bien definido. Es perfectamente aceptable que un registro de mensajes o de actividades esté en un formato compacto, especialmente porque es probable que esté bien definido y se utilice para el análisis en lugar de la solución de problemas. Las herramientas que hacen esto incluyen tcpdump y el monitor del sistema Unix sar . Por otro lado, los registros de programas tienden a ser mucho más ad hoc.

Un ejemplo de un registro un tanto binario es generalizado: el registro de eventos de Windows. En el lado profesional, esto permite que los mensajes de registro sean bastante prolijos (y, por lo tanto, esperemos que sean útiles) prácticamente sin costo, posiblemente algo como

  

Advertencia: La cola de tareas para hacer ha aumentado en 517 elementos en los últimos 90 segundos. Si esto sucede una vez al día, no hay nada de qué preocuparse. Si sucede 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 un recurso instalado con la aplicación. Sin embargo, si este recurso no se instala correctamente (por ejemplo, debido a que mientras se instaló una versión más reciente que ya no admite este mensaje obsoleto), todo lo que ve en el registro de eventos es un mensaje estándar que es simplemente 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 le gustaría hacer antes de elegir entre texto y binario son:

• ¿Quién es mi público?
• ¿Qué contenido debo transmitir?

Una opinión común es que la audiencia de un mensaje de registro es un ser humano. Obviamente, esto no es una suposición perfecta, porque existen muchos scripts de rastreo de registros, pero es uno 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 debe tener un formato bien definido. El formato debe estar lo suficientemente definido como para que otras personas escriban software que funcione en esos registros. Algunos registros están bastante bien estructurados (sus preguntas enumera varias). Otros registros necesitan la capacidad de transmitir contenido en un lenguaje natural menos definido. Estos casos de lenguaje natural no coinciden con los formatos binarios.

Para los registros que podrían estar bien descritos en binario, tiene que hacer una elección. Debido a que el texto funciona para todos, a menudo se lo ve como la opción predeterminada. Si registra sus resultados en texto, las personas pueden trabajar con sus registros. Se ha comprobado miles de veces. Los archivos binarios son más complicados. Como resultado, puede ser que los desarrolladores envíen un texto simplemente porque todos saben cómo se comportará.

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

En primer lugar, si bien la comparación de las ventajas respectivas del texto y los formatos binarios para el almacenamiento de registros a corto plazo es una cuestión 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: según mi experiencia, no es raro ver archivos de registro comprimidos cuyo tamaño sea del 5% o menos del tamaño del archivo original. En consecuencia, el uso de un texto o un formato binario no debería tener ningún impacto medible en el almacenamiento a largo plazo de los registros.

2. Sea cual sea el formato que elijamos, los registros llenarán rápidamente el disco del servidor si no implementamos un "sumidero de archivos" 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 mucho.

Formatos de texto frente a binarios

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

Para decirlo de otra manera, si es probable que tengamos que realizar tratamientos y análisis, no podemos resolverlo hoy, si no sabemos quién debe implementar este análisis, etc., entonces estamos en la etapa en que se deben usar los prototipos y Los 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 deberíamos diseñar un sistema de software perenne para realizar este análisis y es probable que los formatos binarios o estructurados para registros, como las bases de datos relacionales, sean óptimo.

(Hace algún tiempo, escribí un 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 a través del comando de la consola.

Sin embargo, algunos archivos de registro están en formato binary si hay una gran cantidad de 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 se pueda usar (por ejemplo, hojas de cálculo).

En resumen, no todos los archivos de registro están en formato de texto. El formato textual tiene la ventaja de que no se necesitan herramientas personalizadas para ver el contenido. Donde hay una gran cantidad de datos, el archivo puede estar en formato binary . El formato binario necesitará una aplicación (personalizada) para leer los datos y mostrarlos en un formato legible. Más datos se pueden empaquetar en un 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 donde es posible que no haya un canal de salida disponible durante el tiempo de ejecución, la aplicación no puede permitirse el impacto de la velocidad impuesta por el registro, o el registro alteraría o enmascararía el efecto que estoy tratando de grabar. A menudo he recurrido a rellenar datos binarios en una matriz o en un búfer de anillo, y puede imprimirlos (al final de la prueba) o descartarlos y escribir un intérprete para imprimirlos como legibles. 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. Normalmente, el espacio en el disco duro es mucho más barato que el tiempo de ingeniería. Los archivos de registro utilizan 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 archivos 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 de recuperar cualquier información útil en caso de que el sistema falle y corrompa parte del registro.

Un archivo de texto dañado aún se puede leer alrededor de la parte dañada. Un archivo binario dañado puede restaurarse, 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 un apuro para crear un "arreglo temporal" (también conocido como "el más permanente de todos los arreglos") la solución de registro se use en lugar de algo que se pueda crear más rápido.

Contamos con pruebas de unidad para lograr y mantener la solidez de nuestro software. (La mayoría 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 hacen algo de registro. 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 es ú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 de eventos oficiales, escritos a mano y secuenciales. Cuando la maquinaria se volvió capaz de registrar eventos, estos se escribieron en un dispositivo de salida de copia impresa, como una impresora de teletipo, que produjo un registro secuencial permanente pero que solo podía procesar texto y, en ocasiones, sonar una BELL ...

En mis días de mainframe, utilizamos un formato de registro binario personalizado. La razón principal no fue para ahorrar espacio, sino porque queríamos que el registro ocupara un espacio finito al sobrescribir las entradas antiguas por otras nuevas; Lo último que queríamos era no poder diagnosticar los problemas causados por el hecho de que los discos se llenaban (en 1980, el espacio en disco solía costar $ 1000 / Mb, por lo que la gente no compraba más de lo que necesitaba).

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 era una mala idea. Realmente no quieres tener que perder tiempo buscando los comandos correctos para descifrar un archivo de registro cuando tienes un problema crítico que resolver.