Сервер Ubuntu 16.04, Журнал к Базе данных вместо журналов по умолчанию

Если бы Вы открыты для других решений, я советовал бы использовать специализированное регистрирующееся программное обеспечение вместо MySQL. Обоснование для этого состоит в том, что MySQL, как было известно, был проблематичен для хранения журналов, особенно без любого вида предварительной обработки. Другими словами, если Вы просто выводите необработанные записи в журнале в таблицу MySQL, Вы, вероятно, собираетесь закончить с очень немногими столбцами: id, timestamp, log_level, и log_entry (или любая подкомбинация их). Это, в результате делает поиск очень трудно, поскольку необходимо будет или ожидать, долгое время для работы через все записи в журнале плюс память наверху индексации могло бы быть недопустимым для сети. Несомненно, Вы могли разработать пользовательскую схему, которая немного более применима и эффективна в хранении данных и извлечении, но это может потребовать обслуживания, если какая-либо часть регистрирующейся цепочки изменяет операцию или если Вы хотите к данным логов, Вы не регистрировались прежде.

Точно так же при использовании MySQL для user/gamedata/whatever устройства хранения данных делание такой вещи добавило бы намного больше служебный к базе данных. Таким образом, это могло замедлить инфраструктуру Вашей всей системы (в зависимости от системной нагрузки, я рекомендую при выполнении некоторого тестирования).

Так или иначе...

Если бы Вы действительно хотите спуститься по кроличьей норе централизованного входа и управления журналом, я предложил бы что-то как Logstash, объединенный с Elasticsearch для получения информации о запросе. Вы можете также (если Вы хотите), бросают Kibana в соединение для создания чего-то известного как полный стек ELK. Проблема с этим решением, однако, состоит в том, что Elasticsearch является по существу глобальным индексом и требует достойных инвестиций разработки и/или операционное время для установки его эффективным способом. Необходимо будет также отложить большое пространство на жестком диске (и возможно память) если не выделенный сервер для входа. Конечно, существует много альтернатив стеку ELK, и можно, вероятно, найти решение, которое работает лучше всего на Вас с небольшим количеством исследования. Одна вещь отметить, однако, является этим logstash требует некоторой базы данных NoSQL (см. поддерживаемые выводы).

Так или иначе, в зависимости от любого решения для входа Вы выбираете, существуют способы интегрировать такую информацию о журнале в большинство регистрирующихся стеков. Как пример, я выполняю маленькую сеть Minecraft с помощью полностью пользовательской инфраструктуры и программного обеспечения. Наша система разработана для входа ЛОСЮ, который затем предоставляет нам доступную для поиска информацию относительно пользователей, команд в игре, событий "высокой задержки" и подобных действий. Конечно, это не могло бы быть необходимо, но способность расшириться в том направлении может быть полезна для будущего расширения и простоты разработки и администрирования.

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

Мое общепризнанное мнение (на основе Ваших комментариев) - то, что у Вас есть несколько проблем, которые должны быть решены без определенного порядка:

• Не позволяйте пользователям даже пойти, где они не были должны.
  Linux имеет чрезвычайно мощное управление управлением доступом. Можно просто блокировать пользовательский доступ к вещам, к которым у них не должно быть доступа. Например, использование /etc/sudoers для ограничения, что управляет, кто-то может (или не может), выполненный.

• Предоставление сытых пользователей root делает вход невозможным
  Так, я собираюсь позволить своему воображению разрастись здесь. Вы предоставляете свой пользовательский доступ к sudo без ограничения. Если я, администратор жулика, должен был работать sudo -s или подобная команда, я заскочил бы в корневую оболочку без проблемы. На данном этапе Вы теряете несколько вещей. Во-первых, Вы понятия не имеете, кто на самом деле выполняет ту команду. Все, что Вы будете знать, является этим root выполнил его. Во-вторых, администратор жулика может очень легко отключить вход к любому серверу бэкэнда, которому они нравятся и затем выполняют любую команду (команды), которую они хотят. Несомненно, Вы, вероятно, сможете сказать, когда пользователь стал корнем, и, возможно, экстраполируйте, кто выполнил, какая команда после этого, но это больше ни в коем случае не надежно.

Однако существует все еще изящная названная утилита auditd (установке и настройке оставляют осуществление читателю). В основном эта утилита зарегистрируется и команды контроля, выполняемые пользователями (даже те, кто нарастил полномочия в определенных ситуациях). По умолчанию это зарегистрируется к плоскому файлу, но можно затем взять это и переместить его куда угодно, Вы хотите. Например, logstash может записать контрольные журналы, которые можно затем передать тому, везде, где (что-то как MongoDB могло бы быть хорошим, если Вы не хотите выполнять стек ELK). Однако, эта установка уязвима для администраторов жулика, запрещающих вход.

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

Если бы Вы действительно хотите использовать MySQL, я пошел бы с тем, что указывает комментарий Muru. По существу можно настроить auditd и имейте rsyslog вытяните данные из auditd и выведите его в MySQL через ommysql проект, который обеспечит устройство хранения данных предсказуемым способом. Оценка по документации для auditd, Вы сможете очень, легко получают по крайней мере некоторые полезные поля, которые будут допускать достойную схему (по крайней мере), для зарегистрированных команд. Например, Вы сможете использовать auid определить, который пользователь сделал что, comm или exe для определения, что было выполнено, контрольный уникальный идентификатор, результаты состояния, и что было выполнено/как, это было выполнено. См. этот ответ для установки в качестве примера.

Поскольку пользователь входит в систему и подобный, Вам будут нужны дополнительные таблицы, настроенные через rsyslog. В действительности каждая таблица в MySQL только сможет содержать единственный тип действия (вход в систему, выполняемая команда, и т.д.). В зависимости от Вашего примера использования это могло бы очень хорошо быть хорошо, но он действительно ограничивает Вашу способность создать полный журнал аудита (такие функции обеспечиваются NoSQL).

Вам все еще будут нужны сервер системного журнала и (идеально) выделенный SQL-сервер для входа.

Лично, хотя, я пошел бы с auditd и стек ELK. Легче, и комната для расширения.

_{Отказ от ответственности: Я не аффилирован ни с одной из вышеупомянутых именованных технологий, но я работал почти со всеми ими и имею свое собственное избранное.}