Архітектура даних для показників журналу подій?

У моїй службі є велика кількість постійних подій користувачів, і ми хотіли б зробити такі дії, як "рахувати виникнення події типу T з дати D ".

Ми намагаємось прийняти два основні рішення:

1. Що зберігати? Зберігання кожної події проти зберігання агрегатів

   • (Стиль журналу подій) реєструйте кожну подію та підраховуйте їх пізніше,
   • (Стиль часових рядів) зберігає одну зведену "кількість подій Е на дату D " на кожен день

2. Де зберігати дані

   • У реляційній базі даних (зокрема, MySQL)
   • У нереляційній (NoSQL) базі даних
   • У файлах плоских журналів (збираються централізовано по мережі через syslog-ng)

Що таке стандартна практика / де я можу прочитати більше про порівняння різних типів систем?

Додаткові дані:

• Загальний потік подій великий, потенційно - сотні тисяч записів на день
• Але наша сьогоднішня потреба полягає лише в підрахунку певних типів подій всередині нього
• Нам не обов’язково потрібен доступ у режимі реального часу до вихідних даних або результатів агрегації

IMHO, "записуйте всі події у файли, скануйте їх пізніше, щоб фільтрувати та агрегувати потік" - це досить стандартний шлях UNIX, але мої співвітчизники Rails-y, здається, вважають, що нічого не є реальним, якщо це не в MySQL.

Це завжди залежить, я дам вам поради, щоб запропонувати вам нову перспективу

Що зберігати? Зберігання кожної події проти зберігання агрегатів

(Стиль журналу подій) реєструйте кожну подію та підраховуйте їх пізніше,

Якщо ви плануєте не пропустити жодної деталі, хоча зараз вони не актуальні, на моїх очах це найкращий підхід, тому що іноді, коли результати приходять, то ви виявляєте деякі інші події, які для X чи Y вони не були актуальними або вони не принесли ніякої додаткової інформації, але після деякого аналізу це просто так, і вам потрібно також відстежити цю, тому що її записана, але не врахована, потребує певного часу, перш ніж ви зможете додати її до зображення .

(Стиль часових рядів) зберігає одну зведену "кількість подій Е на дату D" на кожен день

Якщо ви хочете реалізувати та використати його завтра, він може спрацювати, але тоді, якщо у вас є нові вимоги або ви виявите кореляцію з іншою подією, яку ви пропустили з будь-якої причини, тоді вам потрібно додати цю нову подію, а потім зачекати деякі довго мати приємні рівні агрегації

Де зберігати дані

У реляційній базі даних (зокрема, MySQL)

Перший варіант може бути важким для БД, якщо ви збираєтеся записувати всі події, тому MySQL, я боюся, може стати занадто маленьким, і якщо ви хочете перейти на рішення RDBMS, ви можете здатися більшими, як PostgreSQL або патентованими як Oracle або DB2 .

Але для агрегування буде хорошим вибором, залежно від сформованого навантаження ви можете об'єднати в код і вставити ці агрегації в БД.

У нереляційній (NoSQL) базі даних

Якщо ви вирішите скористатися цим рішенням, вам слід побачити, який підхід ви хочете дотримуватися приємного прочитання у Вікіпедії, можливо, вам допоможе, я не можу допомогти вам на цю тему, тому що у мене просто недостатньо досвіду, я в основному використовую rdbms.

У файлах плоских журналів (збираються централізовано по мережі через syslog-ng)

Я особисто заважав би вам скористатися цим варіантом. Якщо файл зростає занадто сильно, було б складніше розібратися, але все одно я не знаю основної мети - це слідкувати за системою або просто перевірити журнал файл ...

Сподіваюся, це допомагає!

Я думаю, що ваша ідея розбору журналів, підрахунку та зберігання результатів у БД є дійсною. Не впевнений, що ви хочете все-таки усі ці необроблені журнали в БД (я думаю, саме так ви сказали ваші співвітчизники). Ви вже отримали журнали у файлах, правда? Ви можете просто архівувати їх. Я думаю, що цей біт дійсно залежить від ваших випадків використання.

Також погоджуйтеся з @ Thorbjørn Ravn Andersen щодо переміщення вашої "коментарної відповіді" на питання.

Залежить від призначеного використання. Якщо у вас є стандартний графік або звіт із сукупними значеннями, вам потрібно просто відфільтрувати події під час їх надходження та об'єднати їх у відповідне відро. Якщо вам потрібно детальніше ознайомитись з конкретними подіями або якщо ви думаєте, що ви хочете повернутися назад і переаналізувати / перекласифікувати події пізніше, то вам слід зберегти окремі події.

Якщо у вас є час і простір, я зазвичай люблю це збирати дані, але зберігати дані у (стисненому) файлі. Деталі не повинні бути легкодоступними, оскільки я майже ніколи не потребую їх, але вони доступні для масової повторної обробки, якщо зміниться критерії класифікації.

Будь-яке рішення архітектури повинно визначатися потребами бізнесу. У вашому випадку ви повинні мати більш чітке уявлення про те, яку інформацію ви хочете отримати з вашої системи журналів, і щоб вирішити, як зберігати, як часто вам буде потрібно ця інформація та скільки часу ви можете чекати, щоб отримати результат . Саме це визначає дизайн колекторів журналів, кореляторів подій та подібних програм.

Замість того, щоб дати вам свою думку, я пропоную вам переглянути деякі програми, схожі на те, що ви намагаєтеся розробити. Деякі з них можуть бути набагато потужнішими, ніж те, що ви робите вигляд, що розвиваєтесь, але це не зашкодить, якщо ви подивитесь на політику архітектури та зберігання, яку слід. З боку професіоналів у вас є такі програми SIEM, як RSA та Arcsight, а на відкритій стороні у вас є такі ініціативи, як Kiwi або OSSIM (що також має професійну версію для приладів).

Ще слід врахувати, що коли ви почнете використовувати результати, отримані інструментом, ви почнете отримувати дуже багато запитів від вашого керівництва для отримання додаткової інформації та більш детального. Отже ... використовуйте це обережно і плануйте своїм поглядом на горизонті. Це може дати вам більше роботи, але, безумовно, ви можете отримати багато підтримки та наочності (тиск приходить в комплекті) ....