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

15

Mi servicio tiene un gran número continuo de eventos de usuario, y nos gustaría hacer cosas como "recuento de ocurrencia del tipo de evento T desde la fecha D ."

Estamos tratando de tomar dos decisiones básicas:

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

    • (Estilo de registro de eventos) registra cada evento y cuéntalos más tarde, vs.
    • (Estilo de series de tiempo) almacena un único "recuento del evento E para la fecha D " para cada día
  2. Dónde 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 de forma centralizada a través de la red a través de syslog-ng )

¿Qué es la práctica estándar / dónde puedo obtener más información 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 él
  • No necesariamente necesitamos acceso en tiempo real a los datos en bruto o los resultados de la agregación

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

    
pregunta elliot42 19.07.2012 - 20:21
fuente

4 respuestas

4

Siempre depende, le daré mi consejo para ofrecerle una nueva perspectiva

  

¿Qué almacenar? Almacenar cada evento vs. solo almacenar agregados

     

(Estilo de registro de eventos) registra cada evento y los cuenta 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 aparecen los resultados, encuentra otros eventos que para X o Y no fueron relevantes, o no trajeron ninguna información adicional, pero después de algún análisis, simplemente lo hace, y usted también necesita hacer un seguimiento de eso, y luego, dado que está registrado pero no se cuenta, le tomará algún tiempo antes de poder agregarlo. a la imagen.

  

(Estilo de series de tiempo) almacena un único "conteo agregado 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 cualquier motivo, entonces debe agregar este nuevo evento y luego espere un tiempo largo para tener buenos niveles de agregación

  

Dónde almacenar los datos

     

En una base de datos relacional (particularmente MySQL)

La primera opción puede ser pesada para una base de datos si va a registrar todos los eventos, por lo que me temo que MySQL puede ser demasiado pequeño, y si desea ir para las soluciones RDBMS puede pensar en algo más grande, como PostgreSQL o como propietario. 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. lea en wikipedia puede ayudar usted 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 desalentaría para que opte por esa opción. Si el archivo crece demasiado, sería más difícil analizarlo, pero aún no sé cuál es el objetivo principal, es hacer un seguimiento de un sistema o simplemente revisar un archivo de registro ...

Espero que ayude!

    
respondido por el user50236 17.09.2012 - 18:10
fuente
1

Creo que su idea de analizar registros, contar y almacenar resultados en una base de datos es válida. No estoy seguro de que quieras todos esos registros en bruto en la base de datos de todos modos (creo que eso es lo que dijiste que sugieren tus compatriotas). Ya tienes los registros en los archivos, ¿correcto? Usted podría simplemente archivar esos. Supongo que ese bit realmente depende de su (s) caso (s) de uso.

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

    
respondido por el hiwaylon 17.09.2012 - 02:14
fuente
1

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

Si tienes el tiempo y el espacio, lo que normalmente me gusta 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 un reprocesamiento masivo si los criterios de clasificación cambian.

    
respondido por el TMN 17.09.2012 - 15:31
fuente
1

Cualquier decisión de arquitectura debe ser impulsada 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 almacenar, 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, correladores de eventos y aplicaciones similares.

En lugar de darte mi opinión, te sugiero que mires algunas aplicaciones similares a las que intentas desarrollar. Algunos de ellos pueden ser mucho más poderosos que lo que pretendes desarrollar, pero no te dolerá si observas la arquitectura y las políticas de 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 o OSSIM (que también tiene una versión basada en dispositivos profesionales).

Otra cosa a considerar es que cuando empiece a usar los resultados obtenidos por la herramienta, 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) ....

    
respondido por el Picarus 17.09.2012 - 18:29
fuente

Lea otras preguntas en las etiquetas