Почитал я тут срач в теме про journald, в принципе могу сказать, что скорее солидарен со сторонниками текстовых логов. Но я подумал вот что: существует же множество человекочитаемых форматов, которые также поддаются машинной обработке, например JSON. Пример:
{ «date»: «2011-11-23 23:25:36.0545 +0400», «pid»: 2104, «name»:«apache», «severity»:1, ...
«msg»: «127.0.0.1 - frank [11/Nov/2011:23:25:36 +0400] \„GET /apache_pb.gif HTTP/1.0\“ 200 2326» }
и т.д. Т.е. две строки для удобства грепания: строка самого syslog и строка приложения. На самом деле полей может быть дофига.
Преимущества перед простым текстом:
- формат легко и быстро парсится, быстрее регулярок
- формализованный заголовок
- можно написать набор утилиток, которые будут выдергивать текст перед грепанием, при этом добавлении произвольных полей в любую часть все продолжает работать как ни в чем не бывало
- можно легко создать SQL-подобный язык запросов. Например: SELECT msg FROM apache.log WHERE date >2011.11.22;
- приложения могут добавлять свои поля (они добавятся как поля «msg»), которые могут обрабатываться тем же способом теми же утилитами: SELECT pid, name from apache.log WHERE msg.code=200 AND date >2011.11.22
- можно одним запросом обрабатывать одновременно несколько логов
- можно в фоне строить индекс (кстати, для тескта тоже можно)
- если уж очень всралось, можно вставлять блобы в base64, они легко выкидываются парсером JSON
Преимущества перед бинарными логами
- текстовый формат. nuff said
- обрабатывается грепами, седами и прочими перлами на ура. Можно вообще не пользоваться сторонними утилитами
- скорость и простота
- добавляется в syslog элементарно
- расширяется просто путем добавления новых полей, при этом все старые скрипты и утилиты продолжают работать
- приложение само может регистрировать произвольные поля и объекты без гемора
В общем, на мой взгляд, так одни плюсы. Почему бы не начать с этого?