Почему там столько файлов журнала в типичной системе Linux? То, почему они не используют тот, консолидировало дб/файл журналов и API?

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

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

В системе Unix у Вас уже есть некоторый "системный журнал API". Это называют системным журналом. Системным журналом не является действительно API, но это - стандарт для входа сообщений. Имя обозначает сетевой протокол и библиотеку и демона позади нее.

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

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

Вам решать.

Я просто задаюсь вопросом, почему там столько файлов журнала в типичной системе Linux?

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

Не был бы это быть лучшей идеей иметь одну системную функцию API для входа

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

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

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

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

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

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

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