Почему в типичной системе Linux так много файлов журнала? Почему они не используют один объединенный журнал db / file и api?

Мне просто интересно, почему в типичной системе Linux так много файлов журналов? Не лучше ли было бы иметь одну системную API-функцию для ведения журнала и одну консолидированную таблицу для сохранения всех записей журнала из всех приложений?

Это часть философии Unix . Идея состоит в том, что текстовые файлы свободны от блокировки программы, и каждый может использовать любую технику, которую он предпочитает. Чтобы продвинуться дальше, часто используются плоские файлы, в отличие от языков разметки, таких как XML (хотя я видел программы, хранящие вещи также в формате XML).

В гугле я нашел эту хорошую заметку о простом тексте с комментариями о философии Unix.

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

Вы можете анализировать их с помощью grep, если хотите, можете открывать их с помощью своего любимого пейджера и обрабатывать их на своем любимом языке сценариев, таком как Perl, Python и т. Д., Без необходимости в дополнительных библиотеках.

В системе Unix у вас уже есть своего рода «API системного журнала». Это называется системный журнал. Системный журнал на самом деле не API, но это стандарт для регистрации сообщений. Название обозначает сетевой протокол, а также библиотеку и демон, стоящие за ним.

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

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

Это тебе решать.

Мне просто интересно, почему в типичной системе Linux так много файлов журналов?

Различные файлы журналов содержат разную информацию (хотя обычно есть некоторое дублирование). Они часто имеют разные характеристики: разные политики ротации и хранения, разные разрешения и т. Д. Демон системного журнала заботится о их написании; вы можете увидеть его настройки в /etc/syslog.confили /etc/syslog-ng.conf.

Разве не было бы лучше иметь одну системную API-функцию для регистрации

Это хорошая идея. Давайте назовем это системным журналом . Его задача - отправлять записи журнала демону syslog.

и одна сводная таблица для сохранения всех записей журнала из всех приложений?

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

• Что вы делаете, если база данных не работает? (Файловая система является фундаментальным компонентом (и я уже упоминал, что это намного проще, чем реляционная база данных?); Демон syslog - это простой компонент, который выполняет одну работу (общая особенность в дизайне Unix) и поэтому должен делать это хорошо и надежно.)
• Как вы ведете журнал операций с базой данных? (Хорошо, через саму базу данных - после того, как все журналы содержат записи из ядра и из демона syslog - но опять же более сложная база данных делает это более трудным и менее надежным).
• Как вы получаете доступ к записям журнала? Сравните простоту cat, grep, lessпротив запросов SQL. И права доступа к файлам, ну, я не знаю, как бы вы справились с этим в типичной реляционной базе данных.
• Многосерверные установки не хранят свои журналы локально, они используют функцию удаленного ведения журнала, которая была встроена в демон syslog с момента появления Unix. Это легко реализовать с помощью архитектуры ведения журналов Unix; Вы не можете запустить реплицированную базу данных с таким сложным бюджетом.

Если вы действительно хотите хранить системные журналы в реляционной базе данных (что может иметь много преимуществ), проверьте rsyslog ( готовящаяся замена для syslog ), который может записывать системные журналы в базу данных MySQL , Postgres или Oracle .

Это сделает невозможным такие вещи, как tail -f /var/log/apache/access.log.

Как вы думаете, почему было бы лучше поместить все в один файл?