Architecture de données pour les métriques du journal des événements?

Mon service a un grand nombre d'événements utilisateur en cours, et nous aimerions faire des choses comme «compter l'occurrence du type d'événement T depuis la date D ».

Nous essayons de prendre deux décisions fondamentales:

1. Que stocker? Stockage de chaque événement vs stockage uniquement des agrégats

   • (Style de journal des événements) enregistrez chaque événement et comptez-les plus tard, par rapport à
   • (Style série chronologique) stocke un "nombre d'événements E agrégé pour la date D " pour chaque jour

2. Où stocker les données

   • Dans une base de données relationnelle (notamment MySQL)
   • Dans une base de données non relationnelle (NoSQL)
   • Dans des fichiers journaux plats (collectés de manière centralisée sur le réseau via syslog-ng)

Quelle est la pratique standard / où puis-je en savoir plus sur la comparaison des différents types de systèmes?

Détails supplémentaires:

• Le flux d'événements total est important, potentiellement des centaines de milliers d'entrées par jour
• Mais notre besoin actuel est seulement de compter certains types d'événements en son sein
• Nous n'avons pas nécessairement besoin d'un accès en temps réel aux données brutes ou aux résultats d'agrégation

À mon humble avis, "consigner tous les événements dans des fichiers, les analyser ultérieurement pour filtrer et agréger le flux" est une méthode UNIX assez standard, mais mes compatriotes Rails-y semblent penser que rien n'est réel à moins qu'il ne soit dans MySQL.

Ça dépend toujours, je vais vous donner mes conseils pour vous offrir une nouvelle perspective

Que stocker? Stockage de chaque événement vs stockage uniquement des agrégats

(Style de journal des événements) enregistrez chaque événement et comptez-les plus tard, par rapport à

Si vous prévoyez de ne manquer aucun détail, même si maintenant ils ne sont plus pertinents, à mes yeux, c'est la meilleure approche, car parfois, au fur et à mesure des résultats, vous trouvez d'autres événements qui, pour X ou Y, n'étaient pas pertinents , ou ils n'ont apporté aucune information supplémentaire, mais après une analyse, c'est tout simplement le cas, et vous devez également suivre celle-ci, puis parce qu'elle est enregistrée mais non prise en compte, cela vous prendra un certain temps avant de pouvoir l'ajouter à l'image .

(Style série chronologique) stocke un "nombre d'événements E agrégé pour la date D" pour chaque jour

Si vous souhaitez l'implémenter et l'utiliser demain, cela peut fonctionner, mais si vous avez de nouvelles exigences, ou si vous trouvez une corrélation avec un autre événement que vous avez omis pour une raison quelconque, vous devez ajouter ce nouvel événement, puis attendre quelques longtemps pour avoir de bons niveaux d'agrégation

Où stocker les données

Dans une base de données relationnelle (notamment MySQL)

La première option peut être lourde pour une base de données si vous optez pour l'enregistrement de tous les événements, donc MySQL, je le crains, peut devenir trop petit, et si vous souhaitez opter pour des solutions SGBDR, vous pouvez penser plus grand, comme PostgreSQL ou propriétaire comme Oracle ou DB2. .

Mais pour l'agrégation serait un bon choix, en fonction de la charge générée, vous pouvez agréger dans le code et insérer ces agrégations dans la base de données.

Dans une base de données non relationnelle (NoSQL)

Si vous optez pour cette solution, vous devez voir quelle approche vous souhaitez suivre. Une bonne lecture sur wikipedia peut vous aider, je ne peux pas vous aider beaucoup sur ce sujet car je n'ai tout simplement pas assez d'expérience, j'utilise principalement rdbms.

Dans des fichiers journaux plats (collectés de manière centralisée sur le réseau via syslog-ng)

Personnellement, je vous découragerais d'opter pour cette option.Si le fichier augmente trop, il serait plus difficile à analyser, mais je ne connais toujours pas le but principal, c'est de suivre un système ou simplement de consulter un journal fichier ...

J'espère que cela aide!

Je pense que votre idée d'analyser les journaux, de compter et de stocker les résultats dans une base de données est valide. Pas sûr que vous souhaitiez tous ces journaux bruts dans la base de données de toute façon (je pense que c'est ce que vous avez dit que vos compatriotes suggèrent). Vous avez déjà les fichiers journaux dans les fichiers, correct? Vous pouvez simplement les archiver. Je suppose que ce bit dépend vraiment de vos cas d'utilisation.

Egalement d'accord avec @ Thorbjørn Ravn Andersen sur le déplacement de votre "réponse de commentaire" à la question.

Dépend de votre utilisation prévue. Si vous disposez d'un graphique ou d'un rapport standard affichant des valeurs agrégées, vous souhaiterez simplement filtrer les événements au fur et à mesure qu'ils arrivent et les agréger dans le compartiment approprié. Si vous devez explorer des événements spécifiques, ou si vous pensez que vous voudrez peut-être revenir en arrière et ré-analyser / reclassifier les événements plus tard, vous devez stocker les événements individuels.

Si vous avez le temps et l'espace, ce que j'aime généralement faire, c'est agréger les données, mais stocker les détails dans un fichier (compressé). Les détails ne doivent pas être facilement accessibles, car je n'en ai presque jamais besoin, mais ils sont disponibles pour un retraitement en bloc si les critères de classification changent.

Toute décision d'architecture doit être motivée par les besoins de l'entreprise. Dans votre cas, vous devriez avoir une idée plus claire des informations que vous souhaitez obtenir de votre système de journalisation et afin de décider comment les stocker, à quelle fréquence vous aurez besoin de ces informations et combien de temps vous pouvez attendre pour obtenir le résultat . C'est ce qui motive la conception des collecteurs de journaux, des corrélateurs d'événements et des applications similaires.

Plutôt que de vous donner mon avis, je vous suggère de regarder quelques applications similaires à ce que vous essayez de développer. Certains d'entre eux peuvent être bien plus puissants que ce que vous prétendez développer, mais cela ne fera pas de mal si vous regardez l'architecture et les politiques de stockage suivies. Du côté professionnel, vous avez des applications SIEM comme RSA et Arcsight et du côté Open Source, vous avez des initiatives comme Kiwi ou OSSIM (qui a aussi une version basée sur un appareil professionnel).

Une autre chose à considérer est que lorsque vous commencez à utiliser les résultats obtenus par l'outil, vous commencerez très probablement à recevoir de nombreuses demandes de votre direction pour plus d'informations et une plus détaillée. Alors ... utilisez-le soigneusement et planifiez avec votre vue à l'horizon. Cela peut vous donner plus de travail, mais vous pouvez certainement obtenir beaucoup de soutien et de visibilité (la pression vient dans le paquet) ....