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

17

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.

elliot42
fuente
1
¿Alguna suerte en este proyecto?
hiwaylon
2
@hiwaylon Hemos terminado usando un sistema híbrido: 1) MySQL donde sea posible (bajo volumen) (hace que la agregación sea fácil de usar SELECT...GROUP BY, puede almacenar fácilmente los resultados de SELECTs), 2) usar Graphite para una agregación y visualización simple a gran escala, y 3) registrar eventos completos como referencia y para ver detalles del flujo de datos en tiempo real. Cada uno ha sido valioso de diferentes maneras.
elliot42
Eso suena como una gran solución, bastante similar a lo que estamos haciendo también.
Hiwaylon
1
ACTUALIZACIÓN más de un año después, creamos un sistema que registraba todo y periódicamente iteraba sobre los registros contando cosas, y luego almacenaba esos números contados en una base de datos (podría / debería haber sido una base de datos de series de tiempo, pero MySQL fue suficiente). Estas fueron unas pocas semanas de trabajo, pero terminaron siendo un enfoque sorprendentemente poderoso / rápido: cuando se trata solo de que su código itera sobre JSON registrado, es fácil agregar muchos metadatos y es fácil que su código tenga reglas flexibles para exactamente qué Quiere contar.
elliot42
1
Actualización 2016: Kafka puede hacer este tipo de cosas en estos días, al menos para el almacenamiento sin procesar. Luego puede pegarlos en un gran trabajo MapReduce o Spark, o en un gran almacén como Vertica, etc., si desea consultar / agregar sobre ellos.
elliot42

Respuestas:

4

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!


fuente
1
Los archivos de registro deben rotarse en tamaño o longitud. No creo que la última preocupación sea un problema entonces.
hiwaylon
1

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.

hiwaylon
fuente
1

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.

TMN
fuente
"agrega los datos, pero almacena los detalles en un archivo (comprimido)". Gran pensamiento en particular, gracias!
elliot42
¿Hay inquietudes con el volumen de inicio de sesión del OP mencionado y el filtrado + agregación a medida que entran? Parece que podría ser un cuello de botella peligroso si el volumen de registro es alto y / o la agregación no es trivial.
Hiwaylon
OP mencionó volúmenes de "cientos de miles de eventos al día". Un millón de eventos por día es menos de setecientos por minuto, o alrededor de once por segundo. A menos que la entrada sea un XML largo, su servidor promedio debería ser capaz de manejar eso sin sudar. Sin embargo, definitivamente es algo que debe considerarse al diseñar (y desplegar) la solución.
TMN
1

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) ...

Picarus
fuente