standards - ultimate - ¿Cómo debo formatear mis registros?

pasos para formatear windows 7 (6)

En mi opinión, lo más importante es:

Iniciar registros (líneas) con fecha / hora formateada después del perfil de W3C de ISO 8601
Utilice la pestaña como el separador de campo en los registros

Estoy escribiendo un software de honeypot que tendrá un registro extenso de interacciones con él, planeo iniciar sesión en archivos de texto plano .log.

Tengo dos preguntas, de alguien que no está muy familiarizado con la forma en que se registran los servidores, en primer lugar, ¿cómo dividiré mis archivos de registro? Supongo que después de ejecutar esto durante un mes no quiero un gran archivo .log. Hago esto por día, mes, año? ¿Hay algún estándar para ello?

El formato de cada línea, ¿tengo un deliminitador estándar que es whater, *, -, +, cualquier cosa? ¿Hay un estándar en cualquier lugar (mi google no ha criado mucho).

¡Gracias!

Me gusta este formato para archivos de registro:

$ python simple_logging_module.py 2005-03-19 15:10:26,618 - simple_example - DEBUG - debug message 2005-03-19 15:10:26,620 - simple_example - INFO - info message 2005-03-19 15:10:26,695 - simple_example - WARNING - warn message 2005-03-19 15:10:26,697 - simple_example - ERROR - error message 2005-03-19 15:10:26,773 - simple_example - CRITICAL - critical message

Esto es del módulo de registro de python. Generalmente tengo un archivo por día, una carpeta por cada mes, una carpeta por cada año. Obtendrás enormes archivos de registro que, de lo contrario, no podrás editar correctamente.

logs/ 2009/ January/ 01012009.log 02012009.log ... February/ ... 2008/ ...

No hay un estándar para tal registro. Y rodando, diseño de archivos, todo depende de lo que necesites. En general me he enfrentado a 3 escenarios principales:

Todo en un archivo . No parece una opción para ti.
Laminado de tamaño fijo . Usted define el tamaño cuando se crea un nuevo archivo de registro una vez que el archivo actual es más grande que el valor definido. Por lo general, en la mayoría de los paquetes de log4anything hay soporte de una caja para esto.
Totalmente personalizada rodando . He visto diseños como este
- Cada día recibe su propio directorio llamado en formato YYYYMMDD . Si no organiza sus registros, considere la disposición del directorio como YYYY / MM / YYYYMMDD como se muestra en otras respuestas.
- Dentro de este directorio se debe utilizar la laminación de tamaño fijo .
- Cada archivo tiene el nombre logfile_yyyymmdd_ccc.log donde ccc está aumentando el número. También es una buena idea agregar tiempo al nombre del archivo (por ejemplo, para juzgar fácilmente cuántos registros por minuto está generando)
- Para ahorrar espacio, cada registro se comprime con zip automáticamente.
- Los últimos 3 días siempre se mantienen sin comprimir para que pueda tener un acceso rápido con UNIX herramientas de texto de UNIX .

Esta costumbre se veía así

logs/ 20090101/ logfile_20090101_001.zip logfile_20090101_002.zip ... 20090102/ logfile_20090102_001.zip logfile_20090102_002.zip logfile_20090101_001.log logfile_20090101_002.log logfile_20090102_001.log logfile_20090102_002.log

También hay algunas buenas prácticas para un buen registro:

Siempre mantenga la fecha en su nombre de archivo de registro
Siempre agregue algún nombre a su nombre de archivo de registro. Le ayudará en el futuro a distinguir los archivos de registro de diferentes instancias de su sistema.
Siempre registre la hora y la fecha (preferiblemente una resolución de hasta milisegundos) para cada evento de registro.
Siempre almacene su fecha como YYYYMMDD. En todos lados. En nombre de archivo, dentro de archivo de registro. Ayuda mucho con la clasificación. Se permiten algunos separadores (por ejemplo, 2009-11-29).
En general, evite almacenar registros en la base de datos. En es otro punto de falla en su esquema de registro.
Si tiene un sistema multiproceso, siempre registre el ID del hilo.
Si tiene un sistema multiproceso, siempre registre el id del proceso.
Si tiene muchas computadoras siempre registre la identificación de la computadora.
Asegúrese de que puede procesar los registros más tarde. Solo intente importar un archivo de registro a la base de datos o Excel . Si tarda más de 30 segundos, significa que su registro es incorrecto. Esto incluye:
- Elegir un buen formato interno de registro. Prefiero el espacio delimitado ya que funciona bien con las herramientas de texto Unix y con Excel .
- Elegir un buen formato para la fecha / hora para que pueda importar fácilmente en alguna base de datos SQL o Excel para su posterior procesamiento.

Para dividir los archivos de registro, puede usar una aplicación externa como logrotate y dejar que se encargue del trabajo sucio.

En cuanto al formato de cada línea, no hay un estándar, por lo que debe usar lo que mejor le funcione. Si vas a analizar automáticamente el archivo de registro más tarde, entonces deberías tenerlo en cuenta al formatear la salida del registro.

Te recomiendo usar una biblioteca de registro conocida. La mayoría de las bibliotecas de registro admiten rollover para usted. Log4Net (.net) / Log4J (java) es una biblioteca de registro particularmente buena para usar, y tiene muchas opciones que pueden resultarle útiles. Use el intervalo de vuelco que mejor le funcione. Para una aplicación de honeypot, creo que encontrará la rotación horaria o diaria para funcionar mejor. También puede usar un límite fijo, como 256 mb, para asegurarse de que sus esfuerzos de registro no excedan el espacio libre disponible en el disco. Log4Net / Log4J soporta esto también.

Log4J @ Apache.Org
Log4Net @ Apache.Org

El formato de sus archivos de registro se debe configurar de acuerdo con sus necesidades. Es altamente deseable usar un delimitador que es poco probable que aparezca en la entrada del registro. Para su aplicación, esto puede no ser posible. En circunstancias típicas, algunas partes usan espacios (registros NCSA), otras usan comas (para crear archivos CSV), otras usan pestañas (para hacer archivos delimitados por tabulaciones). Cada uno de estos tiene sus propios beneficios y desventajas.

Una sugerencia:

Al ser para un sistema honeypot (y, a menos que los malos realmente estén dañando la aplicación / sitio), puede considerar tomarse el tiempo adicional para iniciar sesión en una base de datos .

Esto hará que el análisis y el uso de los registros sea más fácil y en tiempo real (es decir, no necesita pasar por el proceso ETL antes de analizar / examinar los registros).

Dicho esto, al estar en una tabla o tablas de base de datos o en un archivo (s), esto no excluye la necesidad de definir un formato . Tentativamente, puede tener un formato " polimórfico ", con algunos atributos comunes (ID, dirección IP, marca de tiempo, cookie / ID, "nivel" [de importancia / urgencia]) seguido de un breve código mnemotécnico que define un tipo de evento particular ( diga "LIA" = intento de inicio de sesión, "GURL" = url adivinado, "SQLI" intento de inyección de SQL, etc ...) seguido de algunos campos numéricos y algunos campos de cadenas cuya semántica variará según la mnemotécnica. Para resumir:

- Id - TimeStamp (maybe split in date and time) - IP_Address - UserID_of_sorts - // other generic/common fields that you may think of - EventCode (LIA, GURL, SQLI...) - Message Text message (varies with particular event instance) - Int1 // Numbers... - Int2 - Str1 // ...and text which meaning varies with the EventCode - Str2 - //... ?

Ahora ... independientemente de que vaya a un archivo plano o a una base de datos SQL (y, en particular, si va a la base de datos), podría / debería usar una biblioteca de registro estándar . Tal vez log4j como se sugiere en otras respuestas (aunque no estoy seguro de si tiene enlaces en Python, y de todos modos, el módulo de registro estándar de Python es +/- el mismo ...) o incluso el módulo de registro de la biblioteca estándar de Python probablemente puede ser adaptado a sus necesidades