Файлы журналов являются важной частью любого серьезного приложения: если регистрация в приложении хороша, то они позволяют увидеть, какие ключевые события произошли и когда; какие ошибки произошли; и общее состояние приложения, которое выходит за рамки того, для чего был разработан мониторинг. Обычно слышат о проблеме, проверяют встроенную диагностику приложения (открывают его веб-консоль или используют диагностический инструмент, такой как JMX), а затем прибегают к проверке лог-файлы.
Если вы используете нетекстовый формат, то вы сразу сталкиваетесь с препятствием: как вы читаете двоичные журналы? С инструментом для чтения журналов, которого нет на ваших производственных серверах! Или это так, но, дорогая, мы добавили новое поле, и это старый читатель. Разве мы не проверяли это? Да, но никто не развернул это здесь. Тем временем ваш экран начинает светиться, когда пользователи проверяют вас.
Или, возможно, это не ваше приложение, но вы оказываете поддержку и думаете, что знаете, что это другая система и WTF? логи в двоичном формате? Хорошо, начните читать вики-страницы, и с чего начать? Теперь я скопировал их на мой локальный компьютер, но они повреждены? Я сделал какой-то недвоичный перевод? Или инструмент для чтения журналов испорчен?
Короче говоря, инструменты для чтения текста являются кроссплатформенными и вездесущими, а журналы часто бывают долгоживущими, и иногда их нужно читать в спешке . Если вы изобрели двоичный формат, то вы отрезаны от целого мира хорошо понятных и простых в использовании инструментов. Серьезная потеря функциональности именно тогда, когда вам это нужно.
Большинство сред ведения журналов находят компромисс: сохраняйте текущие журналы доступными для чтения и представления и сжимайте старые. Это означает, что вы получаете преимущество от сжатия - более того, фактически, потому что двоичный формат не будет сокращать сообщения журнала. В то же время вы можете использовать меньше и grep и так далее.
Итак, какие возможные выгоды могут возникнуть от использования бинарного? Небольшая экономия пространства - всё более неважно. Меньше (или меньше) пишет? Ну, может быть - на самом деле, число записей будет зависеть от количества фиксаций на диске, поэтому, если строки журнала значительно меньше, чем размер блока диска, тогда SSD в любом случае будет назначать новые блоки снова и снова. Таким образом, двоичный файл является подходящим выбором, если:
- вы пишете огромное количество структурированных данных
- журналы должны быть созданы особенно быстро
- вам вряд ли придется анализировать их в «условиях поддержки»
но это звучит менее похоже на регистрацию приложений; это выходные файлы или записи активности. Размещение их в файле, вероятно, только один шаг от записи их в базу данных.
РЕДАКТИРОВАТЬ
Я думаю, что здесь есть общая путаница между «журналами программы» (согласно средам ведения журналов) и «записями» (как в журналах доступа, записях входа и т. Д.). Я подозреваю, что вопрос наиболее тесно связан с последним, и в этом случае проблема гораздо менее четко определена. Вполне приемлемо, чтобы запись сообщений или журнал операций были в компактном формате, особенно потому, что они, вероятно, будут четко определены и использованы для анализа, а не для устранения неполадок. Инструменты, которые делают это, включают tcpdumpи системный монитор Unix sar. Журналы программ, с другой стороны, имеют тенденцию быть намного более специальными.