Регистрация протокольных буферов - PullRequest
6 голосов
/ 23 июня 2010

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

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

Например:

FileOutputStream output = new FileOutputStream ("\ files \ log.txt"); . Request.build () WriteTo (Outout);

Для тех, кто использовал протокольные буферы в вашем приложении, как вы регистрируете свой запрос / ответ, на случай, если он нам понадобится для отладки?

Спасибо

Ответы [ 3 ]

1 голос
/ 23 июня 2010

Мы используем метод ShortDebugString() для объекта C ++, чтобы записать удобочитаемую версию всех входящих и исходящих сообщений в текстовый файл. ShortDebugString() возвращает однострочную версию той же строки, возвращаемой методом toString () в Java. Не уверен, насколько легко сделать то же самое в Java.

1 голос
/ 08 апреля 2013

TL; DR: записывать журналы отладки в тексте, записывать долгосрочные журналы в двоичном формате.

Существует как минимум два способа ведения журнала (и, возможно, на самом деле следует сделать оба):

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

Честно говоря, это более или менее так, как это делается в том месте, откуда появилась эта технология.

0 голосов
/ 23 июня 2010

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

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

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

...