Чтение Unix-p управляет ошибкой удара причин, как я фиксирую его?

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

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

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

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

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

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

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