Исходное сообщение
"Представлен проект Lumberjack, нацеленный на модернизацию си..." Отправлено VoDA, 03-Мрт-12 15:23
>>>Разница между текстовым и бинарным форматом - логическое следствие разницы между структурированными и неструктурированными данными. >> Вы не врубаетесь в самую суть: формат хранения логов это второстепенные вещи >> и нет никакой проблемы перегнать с одного формата в другой. >>>Нет, конечно, можно и текстовые данные структурировать (JSON там, XML), но не на таких объемах, как в случае с логами. >> Проблема сжать существующие логи? Или проблема навесить структуризацию на текущий способ? > Она УЖЕ структурирована, в эрэфсях это чётко прописано (это свежий): Сам MSG не структурирован. Как по вашему задаются обязательные и дополнительные поля для MSG? никак. в этом и проблема, которую хотят вылечить. Дальше дыры в безопасности: наличие в теле сообщения APP-NAME, PROCID, TIMESTAMP (возможно и других подобных полей). Приложение не должно иметь API для того чтобы выдать себя за другое или использовать другое время. API должен быть подобный (псевдо код): спикокПолейИЗначений = { "поле1":"значение поля 1", "IP":127.0.0.1, }; LOG.debug("сообщение для человека без данных", списокПолейИЗначений); И нигде не должно запрашиваться у приложения его ИМЯ, procid и дата записи. ДАТА - по факту логирования, ИМЯ и procid - по факту того кто вызвал запись. И т.п. иначе запись что приложение Маша с хоста Вася является скомпрометированной поскольку приложение может подменить и хост и собственное имя. PS спасибо, что подтвердили мои догадки, что RFC не описывает структуру самого сообщения. Ваша цитата наглядно это показывает )))))