Архитектура данных для метрик журнала событий?

В моем сервисе постоянно присутствует большое количество пользовательских событий, и мы хотели бы сделать что-то вроде «подсчитать вхождение события типа T с даты D ».

Мы пытаемся принять два основных решения:

1. Что хранить? Хранение каждого события против хранения только агрегатов

   • (Стиль журнала событий) регистрировать каждое событие и считать их позже, по сравнению с
   • (Стиль временного ряда) хранит единое агрегированное «количество событий E на дату D » за каждый день

2. Где хранить данные

   • В реляционной базе данных (в частности, MySQL)
   • В нереляционной (NoSQL) базе данных
   • В плоских лог-файлах (собираются централизованно по сети через syslog-ng)

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

Дополнительные детали:

• Общий поток событий большой, потенциально сотни тысяч записей в день
• Но наша текущая потребность состоит только в том, чтобы считать определенные типы событий в нем
• Нам не обязательно нужен доступ в реальном времени к необработанным данным или результатам агрегации

ИМХО, «записывать все события в файлы, сканировать их позднее для фильтрации и агрегирования потока» - это довольно стандартный способ UNIX, но мои соотечественники Rails-y, похоже, думают, что ничего не реально, если только оно не в MySQL.

Это всегда зависит, я дам вам мой совет, чтобы предложить вам новую перспективу

Что хранить? Хранение каждого события против хранения только агрегатов

(Стиль журнала событий) регистрировать каждое событие и считать их позже, по сравнению с

Если вы планируете не пропустить ни одной детали, даже если сейчас они не актуальны, на мой взгляд, это лучший подход, потому что иногда, когда приходят результаты, вы обнаруживаете некоторые другие события, которые для X или Y не были актуальны или они не принесли никакой дополнительной информации, но после некоторого анализа это просто происходит, и вам необходимо также отследить эту информацию, то есть потому, что она записана, но не учтена, потребуется некоторое время, прежде чем вы сможете добавить ее к изображению ,

(Стиль временного ряда) хранит единое агрегированное «количество событий E на дату D» за каждый день

Если вы хотите внедрить и использовать его завтра, это может сработать, но затем, если у вас появятся новые требования или вы обнаружите корреляцию с другим событием, которое вы по какой-либо причине пропустили, вам нужно добавить это новое событие и затем подождать некоторое долгое время иметь хорошие уровни агрегации

Где хранить данные

В реляционной базе данных (в частности, MySQL)

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

Но для агрегирования будет хорошим выбором, в зависимости от генерируемой нагрузки вы можете агрегировать в коде и вставлять эти агрегации в БД.

В нереляционной (NoSQL) базе данных

Если вы выберете это решение, вам нужно увидеть, какой подход вы хотите использовать, и вам может помочь хорошее чтение в Википедии. Я не могу вам сильно помочь по этой теме, потому что у меня просто нет достаточного опыта, я в основном использую rdbms.

В плоских лог-файлах (собранных централизованно по сети через syslog-ng)

Лично я бы не рекомендовал вам использовать эту опцию. Если файл слишком сильно растет, его будет сложнее разобрать, но все же я не знаю, какова основная цель - следить за системой или просто проверять журнал. файл ...

Надеюсь, это поможет!

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

Также согласитесь с @ Thorbjørn Ravn Andersen о переносе вашего «комментария ответа» на вопрос.

Зависит от вашего предполагаемого использования. Если у вас есть стандартный график или отчет, показывающий агрегированные значения, вам нужно просто отфильтровать события по мере их поступления и агрегировать их в соответствующий сегмент. Если вам необходимо детализировать конкретные события или вы думаете, что хотите вернуться назад и повторно проанализировать / переклассифицировать события позже, то вам следует сохранить отдельные события.

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

Любая архитектура должна зависеть от потребностей бизнеса. В вашем случае у вас должно быть более четкое представление о том, какую информацию вы хотите получить из своей системы журналов, и чтобы решить, как хранить, как часто вам потребуется эта информация и сколько времени вы можете ждать, чтобы получить результат. , Это то, что движет дизайном сборщиков журналов, корреляторов событий и подобных приложений.

Вместо того, чтобы высказать свое мнение, я предлагаю вам взглянуть на некоторые приложения, аналогичные тем, которые вы пытаетесь разработать. Некоторые из них могут быть гораздо более мощными, чем то, что вы притворяетесь разрабатывать, но это не повредит, если вы посмотрите на архитектуру и политики хранения, которые следуют. На профессиональной стороне у вас есть приложения SIEM, такие как RSA и Arcsight, а на стороне Open Source у вас есть инициативы, такие как Kiwi или OSSIM (у которых также есть версия для профессионального устройства).

Еще одна вещь, которую следует учитывать, - когда вы начнете использовать результаты, полученные с помощью инструмента, вы, скорее всего, начнете получать много запросов от своего руководства для получения дополнительной информации и более подробных. Так что ... используйте это осторожно и планируйте свое видение на горизонте. Это может дать вам больше работы, но определенно вы можете получить большую поддержку и видимость (давление приходит в пакет) ....