Cuatro formas de escribir un evento

El texto libre no tiene estructura declarada: una persona lo entiende, un programa necesita un patrón. Syslog pone una cabecera común. En el formato del RFC 5424 un mensaje empieza con la prioridad entre ángulos, <165>, seguida de versión, hora, equipo, aplicación y mensaje.

La prioridad junta dos números: prioridad = facility × 8 + severidad. La facility dice de qué parte del sistema viene el mensaje (por ejemplo, 20 es local4); la severidad va de 0 (emergencia) a 7 (depuración), y 5 es «aviso». Así, <165> es facility 20 y severidad 5 porque 20 × 8 + 5 = 165. Para deshacerlo se divide entre 8: el cociente es la facility y el resto, la severidad.

Abre el laboratorio, entra en la carpeta de muestras y lee syslog.txt.

En un evento JSON cada dato trae su nombre y los objetos se anidan: la dirección de origen no está en la raíz, está dentro de red, dentro de origen. Para referirse a un campo anidado se escribe su ruta, con puntos entre los niveles, por ejemplo evento.accion.

Esto ahorra el patrón: no hay que adivinar dónde empieza un valor. A cambio hay que conocer el esquema y tolerar que un campo falte o cambie de nivel.

Lee json.txt.

CEF (Common Event Format) escribe el evento en una sola línea con una cabecera de campos separados por barra vertical: versión, fabricante del dispositivo, producto, versión del producto, identificador de la clase de evento, nombre y severidad. Después va la extensión, una lista de pares clave=valor con claves de un diccionario común.

Por eso un evento CEF se parte en dos pasos: primero la cabecera por las barras, luego la extensión por sus claves. Si un valor de la cabecera lleva una barra vertical, se escapa con una barra invertida.

Lee cef.txt y el diccionario de la exportación.

Algunas fuentes ofrecen dos formatos de salida. La elección no es de gusto: define cuánto trabajo recae en el parser y cuánto se rompe cuando el proveedor actualiza el producto.