Я хотел бы проанализировать файлы журналов. Одинаков ли формат файла журнала syslogd для всех систем? В моей системе (Debian Lenny) это:
Mar 7 04:22:40 my-host-name ...
(Меня не очень интересует ... часть)
Могу я на это рассчитывать? А есть ли более-менее официальное описание? Справочная страница syslogd описывает формат конфигурации, но не формат файла журнала.
В идеале описание должно давать полям официальные имена, такие как (дата, время, хост, запись) или (дата и время, имя хоста, сообщение). Может быть, еще какие-нибудь регулярные выражения. Я хотел бы использовать имена и регулярные выражения в моем скрипте, чтобы избежать ненужного отклонения от стандарта и убедиться, что скрипт работает везде.
Спасибо
Крис
RFC 3164, на который указал вам Warner, описывает сетевой формат для сообщений системного журнала UDP, вы можете полагаться на то, что это то, что передается по сети, но syslogd может записывать на диск что-то немного другое, когда он регистрирует ваши сообщения.
Тем не менее, вы обычно можете полагаться на записи системного журнала, похожие на то, что описано в RFC, примерно в форме:
DATE HOSTNAME TAG: MESSAGE
Дата имеет форму Jan 1 00:00:01
Имя хоста обычно короткое имя хоста, но может быть полностью определенным (особенно если вы регистрируете сообщение с удаленного хоста)
Тег имеет произвольную форму, но по соглашению не содержит :. Часто имеет форму procname[PID], и я считаю, что всегда следует буквальное :
Сообщение произвольная форма
Если вам нужна лучшая гарантия согласованности в формате журнала, стоит обратить внимание на syslog-NG - он позволит вам определить поля и вставить маркеры, чтобы вы могли анализировать полученные файлы. syslog-NG также позволяет вам включать метаданные, такие как значения объекта + приоритета из сообщения. Однако использование syslog-NG сокращает определение «везде» до «машины, на которых запущен syslog-NG с конфигурацией, аналогичной вашей».
RFC должен ответить на этот вопрос. Насколько мне известно: да, это обычно так.
Дьявол находится в RFC, на который ссылается @warner:
4.1.3 MSG - часть пакета системного журнала
Часть MSG заполнит оставшуюся часть пакета системного журнала. Обычно он содержит некоторую дополнительную информацию о процессе, создавшем сообщение, а затем текст сообщения. У этой части нет конечного разделителя. Часть MSG пакета системного журнала ДОЛЖНА содержать видимые (печатные) символы. Традиционно и чаще всего используется кодовый набор, представляющий собой семибитный ASCII в восьмибитном поле, подобное тому, которое используется в частях PRI и HEADER. В этом кодовом наборе единственными допустимыми символами являются значения ABNF VCHAR (% d33-126) и пробелы (значение SP% d32). Однако никакого указания кодового набора, используемого в MSG, не требуется и не ожидается. Другие кодовые наборы МОГУТ использоваться, если символы, используемые в MSG, являются исключительно видимыми символами и пробелами, подобными описанным выше. Выбор кодового набора, используемого в части MSG, ДОЛЖЕН производиться с учетом предполагаемого получателя. Сообщение, содержащее символы в кодовом наборе, которые не могут быть просмотрены или поняты получателем, не предоставит никакой ценной информации для оператора или администратора, просматривающего его. Часть MSG имеет два поля, известных как поле TAG и поле CONTENT. Значение в поле TAG будет именем программы или процесса, создавшего сообщение. КОНТЕНТ содержит подробную информацию о сообщении. Это традиционно сообщение произвольной формы, в котором содержится подробная информация о мероприятии. TAG - это строка буквенно-цифровых символов ABNF, длина которой НЕ ДОЛЖНА превышать 32 символа. Любой не буквенно-цифровой символ завершает поле TAG и считается начальным символом поля CONTENT. Чаще всего первый символ поля CONTENT, обозначающий
По сути, это говорит о том, что разработчик может вставлять в СОДЕРЖАНИЕ все, что он хочет, поэтому на самом деле нет стандарта для фактического содержимого сообщений, только для организации сообщений. Могу сказать, что это недостаток, но я еще не уверен.