Для ведения аудита какой метод лучше?

Question

Для ведения аудита какой метод лучше?

0

Мне нужно выбрать технику хранения и получения журналов аудита (когда что-то было добавлено, удалено, изменено и т.д.). Сценарий: журналы могут быть увеличены на 10 миллионов в день и будут получены некоторыми ключевыми словами. Поэтому мой вопрос:

какую технику я должен использовать, например, ELK (Elasticsearch, Logstash, Kibana) или MySQL или Redis, или что-то лучше и почему.

GsM 14 янв. 2018, в 17:08

Источник

Теги:

mysql

logging

redis

audit

elastic-stack

1 ответ

Ещё вопросы

Ryan Merl · Answer 1 · 2018-01-16T07-53-00.000Z

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

MySQL был бы вторичным выбором OK, но в зависимости от временного горизонта, который вам нужно сохранить, вы в конечном итоге столкнетесь с проблемой масштабирования как с точки зрения пространства, так и с точки зрения поиска (в разумные сроки) без осколков. Sharding позаботится о многих из этих проблем, но, скорее всего, это будет более ручным и более болезненным, чем что-то вроде ELK, которое очень легко настроить для индексирования/осколки по дате.

Redis Не было бы очень хорошим выбором для этого. Все данные redis должны вписываться в память, что ограничивает количество данных журнала, которые вы можете сохранить резко. Ключ/значение также не подходит для данных с логарифмической структурой, особенно по его поисковому запросу, что в redis будет в основном отсутствовать.

Если бы вы перерастали ELK, следующий лучший вариант, вероятно, был бы похож на HDFS + Hadoop/Spark search (или S3 + EMR, если вы на AWS-земле), но в 10 миллионов в день ELK должен длиться хорошо ( в зависимости от временного горизонта). Как пример, в настоящее время я работаю с кластером ELK с 10 узлами, который обрабатывает около миллиарда лог файлов в день, и мы сохраняем историю за две недели.

РЕДАКТИРОВАТЬ:

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

Простой способ добавить журнал аудита - использовать для этого другой поток (например, spring @Async). Но с увеличением количества журналов затраты на управление потоками велики. Таким образом, сообщение квест (например, Кафка) является хорошим предложением. Мне также интересно, есть ли какой-либо способ хранения журналов аудита в приложении без вторжения кода? Поскольку в приложении будет большое количество дублированного кода для ведения журналов
Это во многом зависит от архитектуры вашего приложения. Если ваш доступ к БД четко разделен в вашем коде, а у сущностей есть свой собственный управляющий класс / служба, можно представить общий регистратор сущностей, какие классы управления данными могут присущи их операциям, и это произойдет автоматически. Я не очень знаком с Spring, который, я полагаю, является тем, с чем вы работаете, поэтому у меня не обязательно есть конкретное предложение там.