Что такое наглядность для файла журнала стандартной погрешности?
Я пытаюсь разработать ошибку и предупреждаю файл журнала для своей настольной программы.
Поскольку моя программа читает входной файл пользователя, она может найти синтаксические ошибки или недопустимые какие-то данные. После того как все читается, и программа обрабатывает данные, больше проблем может быть найдено.
Я хочу записать сообщения о них в простой текстовый файл. Я могу также хотеть включать информационный текст для указания на прогресс, время, использование памяти, и т.д. Я захочу включать номера строки и возможно даже фактические входные строки, которые вызывают ошибки.
Это будет файлом, который пользователь захочет просмотреть, так очевидно, он должен быть хорошо размечен и простой в использовании.
Вы знаете о любых руководствах по стилю для этого или имеете Вас замеченный файл регистрации ошибок, который заставил Вас думать себе: "Теперь это - хорошо разработанный файл журнала!"
Продолжение:
Первые три ответа на самом деле более применимы для сервера или журнала событий.
Я действительно ищу формат для файла журнала для моей настольной программы для детализации любых проблем, которые она находит с входным файлом и успехом (или отказ) его обработки этого.
Я уверен, что существуют некоторые настольные приложения, что Вы использовали тот продукт такие файлы журнала. Вы видели какие-либо хорошие?
3 ответа
Вот исправить эту ошибку: http://github.com/mcurry/jquery/commit/a293f5938eb9efd41158b948f487672d43b7c820
Надеюсь, он будет вступить в 1.4.1
-121--4067285- Syslog и и LOG4J широко используются форматы, с помощью которых могут быть знакомы Sysadmins, и есть инструменты для работы с ними. Вы должны хотя бы посмотреть на них, прежде чем делать свой собственный формат.
Для Windows это в значительной степени всегда всегда журнал событий приложения, который мне не очень нравится, как текстовый файл, но это правильный путь. Я видел несколько приложений, которые пишут текстовые файлы в своем каталоге программы или что-то, но это всегда Ad Hoc, никогда не стандартно. McAfee Virusscan, например, файлы журналов в C: \ Документы и настройки \ Все пользователи \ Данные приложения \ McAfee \ DesktopProtection. У моей машины есть много логов установки в C: \ Documents и Settings \ username \ Локальные настройки \ temp * .log и c: \ windows \ temp * .log. Но опять же, они все разные и специальные и не заметно хорошо продуманные
Я пишу журналы в CSV-файлы и найдите его очень удобным (вы можете использовать их в качестве базы данных или открыть их с помощью программного обеспечения для разных видов электронных таблиц для сложного анализа). Файл журнала образца:
Date;Time;Severity;TID;Module;This;Source;Message
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@36;DLL_PROCESS_ATTACH
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@40;DLL_PROCESS_DETACH
Я не уверен, соответствует ли он вашим потребностям, но я думаю, что у вас есть основная идея. Удачи!
Есть несколько файлов журнала, которые я был действительно впечатлен - на самом деле, я изо всех сил пытаюсь подумать (и не могу найти ни одного). По моему опыту, проблемы, которые возникают, происходят частично, потому что журналы отформатированы для инсайдера (программиста), чтобы понять, а не для другой программы, либо посторонним (не программиру).
Решающая информация часто опущена; иногда даже данные даты и времени. Я бы порекомендовал сделать тех, кто легко разрабатывает; Я бы использовал нотацию ISO 8601, например, «2010-01-22T10: 23: 21-08: 00» (включая часовой пояс, обратите внимание). Я бы включал ID процесса (и потока); Я рассмотрю, включая имя программы, аргументы (например, имя файла); Я также включил идентификатор пользователя в какой-то форме. Некоторые из этого могут потребоваться только один раз за выполнение, но другие биты могут потребоваться для каждого сообщения. Часть зависит от того, является ли файл журнала уникальным за прогон или общий через прогоны, и можно использовать один файл более чем одним пользователем / процессом.
Затем вы должны решить, как вы собираетесь определить содержимое сообщения - и конец содержимого сообщения. Особенно для машинного анализа (но также для человеческого анализа) полезно, если контент однозначно отформатирован, и конец можно обнаружить. Возможно, вам может потребоваться избежать контента (это шаг, который наиболее часто отменил, поэтому, если сообщение об ошибке о необходимости сформированного сообщения об ошибке, действительно трудно сказать, какие данные из файла и какое новое сообщение об ошибке о данных в файл). В нескольких резьбовой программе - или где файл журнала может быть общим между процессами - вы должны учитывать, как пишеты также будут буферизованы, особенно если вам нужно иметь дело с длинными линиями. Вы хотите, чтобы каждое сообщение было индивидуально отделено в файле журнала. Это не обязательно тривиально - вам может даже иметь дело с протоколом блокировки для обеспечения контролируемого доступа.
Рассмотрим, нужно ли вам предоставить симпатичный принтер для журнала.
Рассмотрим, поможет ли формат на основе XML (с началом и конечными тегами). Я не большой поклонник XML, но у него есть некоторые преимущества для обработки машин.