Что такое хороший макет для стандартного файла журнала ошибок?

Question

Я пытаюсь создать файл журнала ошибок и предупреждений для моей настольной программы.

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

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

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

Вам известны какие-либо руководства по стилю для этого или вы видели файл журнала ошибок, который заставил вас задуматься: «Теперь это хорошо разработанный файл журнала!»

---

Продолжение:

Первые три ответа на самом деле более применимы для сервера или журнала событий.

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

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

Answer 1

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

Для Windows это почти всегда журнал событий приложений, который мне не очень нравится, как текстовый файл, но это правильный путь. Я видел несколько приложений, которые записывают текстовые файлы в каталог своей программы или что-то в этом роде, но это всегда нерегулярно, а не стандартно. Например, McAfee VirusScan регистрирует файлы в C: \ Documents and Settings \ All Users \ Данные приложения \ McAfee \ DesktopProtection. На моей машине много журналов установки в C: \ Documents and Settings \ username \ Local Settings \ temp * .log и C: \ WINDOWS \ temp * .log. Но опять же, они все разные и специальные и не очень хорошо продуманные

Answer 2

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

Важная информация часто опускается; иногда даже информация о дате и времени. Я бы порекомендовал сделать их легко разбираемыми; Я бы использовал обозначение ISO 8601, например, «2010-01-22T10: 23: 21-08: 00» (включая часовой пояс, примечание). Я бы включил идентификатор процесса (и потока); Я хотел бы рассмотреть в том числе имя программы, аргументы (например, имя файла); Я бы включил идентификатор пользователя в какой-то форме. Часть этого может потребоваться только один раз за цикл, но для каждого сообщения могут потребоваться другие биты. Частично это зависит от того, является ли файл журнала уникальным для каждого прогона или общим для прогонов, и может ли один файл использоваться более чем одним пользователем / процессом.

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

Подумайте, нужно ли вам предоставить симпатичный принтер для журнала.

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

Answer 3

Я пишу логи в 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

Я не уверен, соответствует ли это вашим потребностям, но я думаю, у вас есть основная идея. Удачи!