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

17

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

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

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

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

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

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


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

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

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

elliot42
источник
1
Удачи в этом проекте?
Hiwaylon
2
@hiwaylon В конечном итоге мы использовали гибридную систему: 1) MySQL, где это возможно (низкий объем) (упрощает агрегацию SELECT...GROUP BY, может легко сохранять результаты SELECTs), 2) использование Graphite для простой крупномасштабной агрегации и визуализации, и 3) регистрация полных событий для справки и для просмотра деталей потока данных в режиме реального времени. Каждый на самом деле был ценным по-разному.
elliot42
Это звучит как отличное решение, очень похожее на то, что мы делаем.
hiwaylon
1
ОБНОВЛЕНИЕ более года спустя мы создали систему, которая регистрирует все, периодически перебирает журналы, подсчитывающие вещи, а затем сохраняет эти подсчитанные числа в базе данных (могла / должна была быть база данных временных рядов, но MySQL хватало). Это было несколько недель работы, но в итоге оказалось удивительно мощным / быстрым подходом - когда ваш код перебирает только протоколированный JSON, легко добавить много метаданных и легко для вашего кода иметь гибкие правила для именно того, что он хочет считать.
elliot42
1
Обновление 2016: Kafka может делать такие вещи в наши дни, по крайней мере, для хранения в сыром виде. Затем вы можете вставить их в большое задание MapReduce или Spark, или в большой склад, такой как Vertica и т. Д., Если вы хотите запросить / агрегировать их.
elliot42

Ответы:

4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


источник
1
Файлы журнала должны быть повернуты по размеру или длине. Я не думаю, что последнее беспокойство будет проблемой тогда.
Hiwaylon
1

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

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

hiwaylon
источник
1

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

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

TMN
источник
msgstr "агрегировать данные, но хранить детали в (сжатом) файле". Отличная мысль, в частности, спасибо!
elliot42
Есть ли проблемы с объемом регистрации упомянутого OP и выполнением фильтрации + агрегирования по мере их поступления? Кажется, что это может быть опасным узким местом, если объем журнала велик и / или агрегация не тривиальна.
Hiwaylon
ОП упомянула объемы «сотен тысяч мероприятий в день». Один миллион событий в день - это менее семисот минут или около одиннадцати секунд. Если ввод не является длинным XML, ваш средний сервер должен справиться с этим, не потревожив. Это определенно то, что следует учитывать при разработке (и развертывании) решения.
TMN
1

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

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

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

Picarus
источник