syslogd: формат файла журнала (не формат конфигурации)
Я хотел бы разобрать лог-файлы. Является ли формат файла журнала syslogd одинаковым для всех систем? В моей системе (Debian Lenny) это:
Mar 7 04:22:40 my-host-name ...
(Меня не очень интересует... часть)
Могу ли я на это положиться? И есть ли какое-то более или менее официальное описание? Справочная страница syslogd описывает формат конфигурации, но не формат файла журнала.
В идеале описание должно содержать такие официальные имена полей, как (дата, время, хост, запись) или (дата / время, имя хоста, сообщение). Может быть, дополнительно некоторые регулярные выражения. Я хотел бы использовать имена и регулярные выражения в моем скрипте, чтобы избежать ненужного отклонения от стандарта и убедиться, что скрипт работает везде.
Спасибо
Крис
3 ответа
RFC должен ответить на этот вопрос. Насколько мне известно: да, это обычно так.
В 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, который @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, который обозначает
По сути, это говорит о том, что разработчик может вставить все, что хочет, в CONTENT, поэтому на самом деле не существует стандарта для реального содержимого сообщений, только для организации сообщений. Я мог бы сказать, что это недостаток, но я еще не уверен.