Arquitectura de datos para métricas de registro de eventos?

Mi servicio tiene una gran cantidad de eventos de usuarios en curso, y nos gustaría hacer cosas como "contar la ocurrencia de eventos tipo T desde la fecha D ".

Estamos tratando de tomar dos decisiones básicas:

1. ¿Qué almacenar? Almacenar cada evento versus solo almacenar agregados

   • (Estilo de registro de eventos) registre cada evento y cuéntelos más tarde, vs.
   • (Estilo de serie temporal) almacena un único "recuento del evento E para la fecha D " para cada día

2. Donde almacenar los datos

   • En una base de datos relacional (particularmente MySQL)
   • En una base de datos no relacional (NoSQL)
   • En archivos de registro planos (recopilados centralmente a través de la red a través de syslog-ng)

¿Qué es la práctica estándar / dónde puedo leer más sobre la comparación de los diferentes tipos de sistemas?

Detalles adicionales:

• El flujo total de eventos es grande, potencialmente cientos de miles de entradas por día.
• Pero nuestra necesidad actual es solo contar ciertos tipos de eventos dentro de ella
• No necesariamente necesitamos acceso en tiempo real a los datos sin procesar o resultados de agregación

En mi humilde opinión, "registrar todos los eventos en archivos, rastrearlos más tarde para filtrar y agregar la secuencia" es una forma bastante estándar de UNIX, pero mis compatriotas Rails-y parecen pensar que nada es real a menos que esté en MySQL.

Siempre depende, te daré mi consejo para ofrecerte una nueva perspectiva

¿Qué almacenar? Almacenar cada evento versus solo almacenar agregados

(Estilo de registro de eventos) registre cada evento y cuéntelos más tarde, vs.

Si planea no perderse ningún detalle, aunque ahora no son relevantes, en mi opinión, ese es el mejor enfoque, porque a veces, a medida que llegan los resultados, encontrará otros eventos que para X o Y no fueron relevantes , o no trajeron ninguna información adicional, pero después de un análisis, simplemente lo hace, y usted también necesita rastrear esa información, entonces porque está grabada pero no contabilizada, le tomará algún tiempo antes de poder agregarla a la imagen .

(Estilo de serie temporal) almacena un único "recuento del evento E para la fecha D" para cada día

Si desea implementarlo y usarlo mañana, puede funcionar, pero si tiene nuevos requisitos o si encuentra una correlación con otro evento que omitió por algún motivo, debe agregar este nuevo evento y luego esperar un poco mucho tiempo para tener buenos niveles de agregación

Donde almacenar los datos

En una base de datos relacional (particularmente MySQL)

La primera opción puede ser pesada para un DB si va a grabar todos los eventos, por lo que MySQL me temo que puede volverse demasiado pequeño, y si desea buscar soluciones RDBMS, puede pensar en más grande, como PostgreSQL o propietario como Oracle o DB2 .

Pero para la agregación sería una buena opción, dependiendo de la carga generada, puede agregar en el código e insertar esas agregaciones en la base de datos.

En una base de datos no relacional (NoSQL)

Si opta por esta solución, necesita ver qué enfoque desea seguir, una buena lectura en wikipedia puede ayudarlo, no puedo ayudarlo mucho en ese tema porque simplemente no tengo suficiente experiencia, principalmente uso rdbms.

En archivos de registro planos (recopilados centralmente a través de la red a través de syslog-ng)

Personalmente, lo desaconsejaría para que optara por esa opción. Si el archivo crece demasiado, sería más difícil de analizar, pero aún no sé el propósito principal, es hacer un seguimiento en un sistema o simplemente verificar un registro archivo ...

¡Espero eso ayude!

Creo que su idea de analizar registros, contar y almacenar resultados en una base de datos es válida. De todos modos, no estoy seguro de querer todos esos registros sin procesar en la base de datos (creo que eso es lo que dijiste que sugieren tus compatriotas). Ya tienes los registros en los archivos, ¿correcto? Podrías archivarlos. Supongo que ese bit realmente depende de su (s) caso (s) de uso.

También esté de acuerdo con @ Thorbjørn Ravn Andersen acerca de mover su "respuesta de comentario" a la pregunta.

Depende de su uso previsto. Si tiene un gráfico o informe estándar que muestre valores agregados, entonces simplemente querrá filtrar los eventos a medida que ingresan y agregarlos en el depósito apropiado. Si necesita profundizar en eventos específicos, o si cree que puede volver atrás y volver a analizar / categorizar eventos más tarde, debe almacenar los eventos individuales.

Si tiene el tiempo y el espacio, lo que generalmente me gusta hacer es agregar los datos, pero almacenar los detalles en un archivo (comprimido). Los detalles no tienen que ser fácilmente accesibles, ya que casi nunca los necesito, pero están disponibles para el reprocesamiento en masa si cambian los criterios de clasificación.

Cualquier decisión de arquitectura debe ser dirigida por las necesidades del negocio En su caso, debe tener una idea más clara de qué información desea obtener de su sistema de registro y para decidir cómo almacenarla, con qué frecuencia necesitará esta información y cuánto tiempo puede esperar para obtener el resultado . Esto es lo que impulsa el diseño de recopiladores de registros, correlacionadores de eventos y aplicaciones similares.

En lugar de darle mi opinión, le sugiero que mire algunas aplicaciones similares a las que intenta desarrollar. Algunos de ellos pueden ser mucho más poderosos de lo que pretendes desarrollar, pero no te hará daño si miras las políticas de arquitectura y almacenamiento seguidas. En el lado profesional, tiene aplicaciones SIEM como RSA y Arcsight y en el lado de código abierto tiene iniciativas como Kiwi u OSSIM (que también tiene una versión profesional basada en dispositivos).

Otra cosa a tener en cuenta es que cuando comience a usar los resultados obtenidos por la herramienta, probablemente comenzará a recibir muchas solicitudes de su gerencia para obtener más información y una más detallada. Entonces ... úsalo con cuidado y planifica con tu vista en el horizonte. Puede darle más trabajo, pero definitivamente puede obtener mucho apoyo y visibilidad (la presión viene en el paquete) ...