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

Ведение журнала - это то, что необходимо, но (относительно) редко используется. Как таковой он может быть сделан намного более компактным с точки зрения хранения.

Например, данные, которые чаще всего регистрируются, такие как IP, дата, время и другие данные, которые могут быть представлены в виде целого числа, хранятся в виде текста.

Если запись была сохранена в виде двоичных данных, можно было бы сохранить много места, что потребовало бы меньшего вращения и увеличения срока службы диска, особенно с твердотельными накопителями, где запись ограничена.

Некоторые могут сказать, что это настолько незначительная проблема, что это не имеет большого значения, но принимая во внимание усилия, необходимые для создания такого механизма, нет смысла не делать этого. Любой может сделать это в течение двух дней в свободное время, почему люди не делают этого?

systemdклассно хранит свои файлы журнала в двоичном формате. Основные проблемы, которые я слышал, это:

1. если журнал поврежден, его трудно восстановить, так как он требует специальных инструментов
2. они не читаются человеком, поэтому вы не можете использовать стандартные инструменты, такие как vi, grepи tailт. д. для их анализа

Основная причина использования бинарного формата (насколько мне известно) заключалась в том, что его считали более легким для создания индексов и т. Д., Т. Е. Для его обработки больше как файла базы данных.

Я бы сказал, что преимущество дискового пространства на практике относительно невелико (и уменьшается). Если вы хотите хранить большое количество журналов, то архивирование свернутых журналов действительно весьма эффективно.

В целом, преимущества инструментария и фамильярности, вероятно, будут ошибаться в стороне от регистрации текста в большинстве случаев.

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

Ищите слово «текст» в статье Википедии о философии Unix , например, вы найдете такие выражения, как:

Макилрой, тогдашний глава CSRC Bell Labs (Исследовательский центр компьютерных наук) и изобретатель трубы Unix, [9] резюмировал философию Unix следующим образом: [10]

Это философия Unix: пишите программы, которые делают одно и делают это хорошо. Напишите программы для совместной работы. Написание программ для обработки текстовых потоков, потому что это универсальный интерфейс.

Или, например, из Основ философии Unix ,

Правило композиции: разрабатывать программы, связанные с другими программами.

Трудно избежать программирования слишком сложных монолитов, если ни одна из ваших программ не может общаться друг с другом.

Традиция Unix настоятельно рекомендует писать программы, которые читают и пишут простые текстовые, ориентированные на поток, независимые от устройства форматы. В классическом Unix столько программ, сколько возможно, написаны в виде простых фильтров, которые принимают простой поток текста при вводе и обрабатывают его в другой простой поток текста при выводе.

Несмотря на популярную мифологию, эта практика предпочтительна не потому, что программисты Unix ненавидят графический пользовательский интерфейс. Это потому, что если вы не пишете программы, которые принимают и генерируют простые текстовые потоки, гораздо сложнее соединить программы вместе.

Текстовые потоки предназначены для инструментов Unix, а сообщения - для объектов в объектно-ориентированной настройке. Простота интерфейса текстового потока обеспечивает инкапсуляцию инструментов. Более сложные формы межпроцессного взаимодействия, такие как удаленные вызовы процедур, демонстрируют тенденцию слишком сильно вовлекать программы друг в друга.

Любой может сделать это в течение двух дней в свободное время, почему люди не делают этого?

Хранение файла журнала в двоичном виде - это только начало (и тривиальное). Затем вам нужно написать инструменты для:

• Показать весь файл журнала ( edit)
• Показать конец журнала, не читая его начало ( tail -f)
• Искать вещи в файле ( grep)
• Фильтр, чтобы отображать только выбранные / интересные вещи (используя произвольно сложное выражение фильтра)
• Отправьте журнал по электронной почте кому-то, у кого нет программного обеспечения для файла-файла-декодера
• Скопируйте и вставьте фрагмент файла журнала
• Прочитайте файл журнала, пока программа (которая создает файл журнала) все еще разрабатывается и отлаживается
• Чтение файлов журнала со старых версий программного обеспечения (которые развернуты на сайтах клиентов и работают).

Очевидно, что программное обеспечение может и действительно использует двоичные форматы файлов (например, для реляционных баз данных), но это не стоит (в смысле YAGNI ), обычно не стоит делать, для файлов журналов.

Здесь много спорных предположений.

Ведение журнала было неотъемлемой частью (почти) каждой моей работы. Это важно, если вам нужна какая-либо информация о состоянии ваших приложений. Я сомневаюсь, что это «бахрома»; большинство организаций, с которыми я был связан, считают журналы очень важными.

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

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

Файлы журналов являются важной частью любого серьезного приложения: если регистрация в приложении хороша, то они позволяют увидеть, какие ключевые события произошли и когда; какие ошибки произошли; и общее состояние приложения, которое выходит за рамки того, для чего был разработан мониторинг. Обычно слышат о проблеме, проверяют встроенную диагностику приложения (открывают его веб-консоль или используют диагностический инструмент, такой как JMX), а затем прибегают к проверке лог-файлы.

Если вы используете нетекстовый формат, то вы сразу сталкиваетесь с препятствием: как вы читаете двоичные журналы? С инструментом для чтения журналов, которого нет на ваших производственных серверах! Или это так, но, дорогая, мы добавили новое поле, и это старый читатель. Разве мы не проверяли это? Да, но никто не развернул это здесь. Тем временем ваш экран начинает светиться, когда пользователи проверяют вас.

Или, возможно, это не ваше приложение, но вы оказываете поддержку и думаете, что знаете, что это другая система и WTF? логи в двоичном формате? Хорошо, начните читать вики-страницы, и с чего начать? Теперь я скопировал их на мой локальный компьютер, но они повреждены? Я сделал какой-то недвоичный перевод? Или инструмент для чтения журналов испорчен?

Короче говоря, инструменты для чтения текста являются кроссплатформенными и вездесущими, а журналы часто бывают долгоживущими, и иногда их нужно читать в спешке . Если вы изобрели двоичный формат, то вы отрезаны от целого мира хорошо понятных и простых в использовании инструментов. Серьезная потеря функциональности именно тогда, когда вам это нужно.

Большинство сред ведения журналов находят компромисс: сохраняйте текущие журналы доступными для чтения и представления и сжимайте старые. Это означает, что вы получаете преимущество от сжатия - более того, фактически, потому что двоичный формат не будет сокращать сообщения журнала. В то же время вы можете использовать меньше и grep и так далее.

Итак, какие возможные выгоды могут возникнуть от использования бинарного? Небольшая экономия пространства - всё более неважно. Меньше (или меньше) пишет? Ну, может быть - на самом деле, число записей будет зависеть от количества фиксаций на диске, поэтому, если строки журнала значительно меньше, чем размер блока диска, тогда SSD в любом случае будет назначать новые блоки снова и снова. Таким образом, двоичный файл является подходящим выбором, если:

• вы пишете огромное количество структурированных данных
• журналы должны быть созданы особенно быстро
• вам вряд ли придется анализировать их в «условиях поддержки»

но это звучит менее похоже на регистрацию приложений; это выходные файлы или записи активности. Размещение их в файле, вероятно, только один шаг от записи их в базу данных.

РЕДАКТИРОВАТЬ

Я думаю, что здесь есть общая путаница между «журналами программы» (согласно средам ведения журналов) и «записями» (как в журналах доступа, записях входа и т. Д.). Я подозреваю, что вопрос наиболее тесно связан с последним, и в этом случае проблема гораздо менее четко определена. Вполне приемлемо, чтобы запись сообщений или журнал операций были в компактном формате, особенно потому, что они, вероятно, будут четко определены и использованы для анализа, а не для устранения неполадок. Инструменты, которые делают это, включают tcpdumpи системный монитор Unix sar. Журналы программ, с другой стороны, имеют тенденцию быть намного более специальными.

Пример несколько бинарного журнала широко распространен: журнал событий Windows. Что касается профессионалов, это позволяет журнальным сообщениям быть довольно многословными (и, как мы надеемся, полезными) практически без затрат, возможно, что-то вроде

Предупреждение: очередь за foobars выросла на 517 пунктов за последние 90 секунд. Если это происходит примерно раз в день, беспокоиться не о чем. Если это происходит чаще или быстрее, вы можете проверить объем оперативной памяти, доступной для приложения foobar. Однако если это происходит вместе с событием 12345, вы, похоже, используете устаревшую базу данных, и вам лучше позвонить в службу поддержки по телефону + 1-555-12345, чтобы предотвратить потерю данных.

Основная часть этого сообщения существует только один раз как ресурс, установленный вместе с приложением. Однако, если этот ресурс установлен неправильно (например, потому что тем временем была установлена ​​более новая версия, которая больше не поддерживает это устаревшее сообщение), все, что вы видите в журнале событий, - это стандартное сообщение, которое является просто причудливой формулировкой для

Не знаю, что-то с "517" и "90".

и больше не помогает в любом случае.

Два основных вопроса, которые вы хотели бы задать, прежде чем выбирать между текстовым и двоичным:

• Кто моя аудитория?
• Какой контент мне нужно передать?

Распространено мнение, что аудитория сообщения журнала - это человек. Это, очевидно, не идеальное предположение, потому что существует множество сценариев сканирования журналов, но это распространенное явление. В этом случае имеет смысл передавать информацию в среде, удобной для людей. Текст имеет давнюю традицию быть этим средством.

Что касается содержимого, учтите, что двоичный журнал должен иметь четко определенный формат. Формат должен быть достаточно четко определен, чтобы другие люди могли писать программное обеспечение, которое работает с этими журналами. Некоторые журналы довольно хорошо структурированы (ваш вопрос содержит несколько). Другие журналы нуждаются в способности передавать контент в менее четко определенной форме естественного языка. Такие случаи на естественном языке плохо подходят для двоичных форматов.

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

TL; DR: Размер на самом деле не имеет значения, но удобство использования имеет

Прежде всего, хотя сопоставление соответствующих преимуществ текстового и двоичного форматов для кратковременного хранения журналов является важным вопросом, размер на самом деле не имеет значения. Две причины этого:

1. Журналы - это избыточная информация, которая хорошо сжимается: по моему опыту, нередко можно увидеть сжатые файлы журналов, размер которых составляет 5% или меньше от размера исходного файла. Следовательно, использование текстового или двоичного формата не должно оказывать какого-либо измеримого влияния на длительное хранение журналов.

2. Какой бы формат мы ни выбрали, журналы будут быстро заполнять диск сервера, если мы не реализуем «приемник файлов журнала», который сжимает и отправляет файлы журнала на платформу долгосрочного хранения. Использование двоичного формата может немного замедлить это, но даже изменение в 10 раз не будет иметь большого значения.

Текстовые и двоичные форматы журналов

Обещание систем Unix состоит в том, что, если мы научимся использовать стандартный набор инструментов, работающий с текстовыми файлами, структурированными по строкам - такими как grep , sort , join , sed и awk, - мы сможем использовать их для быстрой сборки прототипов, выполняющих любую работу. мы хотим, хотя и медленно и грубо. После того, как прототип продемонстрировал свою полезность, мы можем включить его в действительно разработанное программное обеспечение, чтобы повысить производительность или добавить другие полезные функции. Это, по крайней мере, в моем понимании, суть философии Unix.

Иными словами, если нам, вероятно, понадобится выполнить обработку и анализ, мы не сможем выяснить к сегодняшнему дню, если мы не знаем, кто должен проводить этот анализ и т. Д., То мы находимся на этапе, когда следует использовать прототипы и текстовые форматы для журналы наверное оптимальны. Если нам необходимо многократно выполнять небольшой набор четко определенных процедур, то мы находимся в ситуации, когда нам необходимо разработать многолетнюю программную систему для выполнения этого анализа, и двоичные или структурированные форматы для журналов, такие как реляционные базы данных, вероятно, будут оптимальный.

(Некоторое время назад я написал в блоге об этом.)

Файлы журналов представлены в текстовом формате, поскольку их можно легко прочитать с помощью любого типа текстового редактора или путем отображения содержимого с помощью команды консоли.

Однако некоторые файлы журналов имеют двоичный формат, если данных много. Например, продукт, над которым я работаю, хранит максимум 15000 записей. Чтобы хранить записи в наименьшем количестве места, они хранятся в двоичном виде. Однако специальное приложение должно быть написано для просмотра записей или преобразования их в формат, который можно использовать (например, электронные таблицы).

Таким образом, не все файлы журнала представлены в текстовом формате. Преимущество текстового формата заключается в том, что для просмотра контента не нужны специальные инструменты. Если данных много, файл может быть в двоичном формате. Для двоичного формата потребуется (специальное) приложение для чтения данных и отображения в удобочитаемом формате. Больше данных может быть упаковано в двоичный формат. Использовать ли текстовый формат или двоичный формат - это решение, основанное на объеме данных и простоте просмотра содержимого.

Во встроенных системах, где у меня может не быть выходного канала, доступного во время выполнения, приложение не может позволить себе потерю скорости, вызванную регистрацией, или регистрация изменила или замаскировала эффект, который я пытаюсь записать, я часто прибегает к вставке двоичных данных в массив или кольцевой буфер, а также либо к printf () их в конце выполнения теста, либо к дампу необработанных данных и написанию интерпретатора для печати как читабельного. В любом случае, я хочу получить читаемые данные.

В системах с большим количеством ресурсов зачем придумывать схемы для оптимизации того, что не требует оптимизации?

Файлы журнала предназначены для помощи в устранении неполадок. Как правило, место на жестком диске намного дешевле, чем время разработки. Файлы журналов используют текст, потому что есть много инструментов для работы с текстом (например, tail -f). Даже HTTP использует простой текст (см. Также, почему мы не отправляем двоичный код вместо текста в http ).

Кроме того, дешевле разработать систему ведения журнала в виде простого текста и проверить ее работоспособность, ее легче отладить, если она выйдет из строя, и проще восстановить любую полезную информацию в случае сбоя системы и повреждения части журнала.

Поврежденный текстовый файл все еще доступен для чтения вокруг поврежденной части. Поврежденный бинарный файл может быть восстановлен, но может и не быть. Даже если это будет восстановимо, это потребует немного больше работы. Другая причина заключается в том, что двоичный формат ведения журнала снижает вероятность того, что во время спешки создать «временное исправление» (то есть «самое постоянное из всех исправлений») решение для ведения журнала будет использоваться вместо чего-то, что может быть создано быстрее.

Мы рассчитываем на модульное тестирование для достижения и поддержания надежности нашего программного обеспечения. (Большая часть нашего кода выполняется на сервере без заголовка; ключевой стратегией является анализ файлов журналов после операции). Почти каждый класс в нашей реализации делает некоторые записи. Важной частью нашего модульного тестирования является использование «ложных» регистраторов, которые используются при модульном тестировании. Юнит-тест создает макет логгера и предоставляет его тестируемому элементу. Затем он (когда это полезно / уместно) анализирует то, что было зарегистрировано (особенно ошибки и предупреждения). Использование текстового формата журнала делает это намного проще по тем же причинам, что и анализ, выполненный на «реальных» журналах: в вашем распоряжении есть больше инструментов, которые можно быстро использовать и адаптировать.

Исторически, журналы были официальными, рукописными и последовательными записями событий. Когда машины стали способны записывать события, они были записаны на печатном устройстве вывода, таком как телетайпный принтер, который производил постоянную последовательную запись, но мог обрабатывать только текст и иногда звонить в колокол ...

В те времена, когда я работал с мэйнфреймами, мы использовали специально разработанный двоичный формат журнала. Основная причина заключалась не в экономии места, а в том, что мы хотели, чтобы журнал занимал конечное пространство, перезаписывая старые записи новыми; Последнее, чего мы хотели, - это невозможности диагностировать проблемы, вызванные переполнением дисков (в 1980 году дисковое пространство стоило 1000 долларов США / Мб, поэтому люди покупали не больше, чем им было нужно).

Теперь мне все еще нравится идея файла циклического журнала, и если бы операционные системы предлагали такого зверя, я бы использовал его без колебаний. Но двоичный код был плохой идеей. Вы действительно не хотите тратить время на поиск правильных команд для расшифровки файла журнала, когда вам нужно решить критическую проблему.