Чтобы зарегистрироваться или не войти?

Ответ 1

Это важно. Вход

• все ошибки со связанными данными (методы args и т.д.). В противном случае у вас будет целый ряд проблем, связанных с ошибками, которые вы не можете проанализировать.
• ключевые точки входа и выхода (что делает ваша программа? Должны ли вы называть эти методы на этом этапе?)
• возможные трудоемкие методы/операции (вход и выход), поэтому вы можете измерить, что происходит, и знать, что делает ваша программа/где она находится.
• где вы загружаете конфигурации, если это применимо. Это означает, что вы можете указать, как ваша программа сама настраивается (какой config она использует?)

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

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

Вы должны найти подходящие рамки для ведения журнала (например, log4c для C, log4j для Java) для вашей конкретной платформы, которая позволяет выбрать подходящую фильтрацию и выбор места назначения. Это означает, что вы можете записывать файлы (и ограничивать размеры журналов), базы данных, удаленные мониторы и т.д. И изменять это решение "на лету" (через конфигурационный файл или аргументы командной строки). Правильная структура должна требовать очень мало изначально, кроме как вставлять соответствующие протоколирующие заявления. Вам не нужно много писать в способе управления файлами или другом коде управления журналом.

Здесь полезная запись в блоге по этому вопросу, с дальнейшими рекомендациями.

Ответ 2

Ведение журнала важно и полезно. Зачем? Для отслеживания. Пока вы работаете на локальной машине, вы можете быстро отлаживать, устанавливать точки останова и определять, где все идет не так. После того, как вы развернете свое производство, ваш клиент позвонит вам, сообщив, что он не видел, чего он ожидал (появилось сообщение об ошибке). Поверьте мне, вам будет сложно выяснить, что произошло, если у вас нет журналов.

Хмм... Брайан ответил, просто выскочил, говоря в основном, где я хотел продолжить:)

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

Что касается типа ведения журнала: я обычно отлично разбираюсь в текстовых файлах (с определенным максимальным размером), если вам не нужно отслеживать все действия пользователя (юридические причины, что бы то ни было). В таком случае, вероятно, более подходящим будет журнал БД.

Ответ 3

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

Я рекомендую вести журнал в плоский файл по базе данных.

Ответ 4

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

Ответ 5

Это очень общий вопрос... Для начала я бы сказал, что у вас должно быть несколько уровней регистрации. На уровне трассировки запишите все, что вы имеете в виду. На уровне ошибок регистрировать только ошибки. Позвольте выбрать уровень ведения журнала во время выполнения, хотя выбор не должен быть доступен для конечных пользователей. Кроме того, имейте в виду, что, если вы делаете свои журналы доступными для людей, отличных от вас (например, ваша группа поддержки), убедитесь, что ваши сообщения являются читаемыми человеком, а не только вы можете понять.

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

Ответ 6

• Хорошо регистрировать действия или события, которые происходят в программах (например, ошибки)?

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

• В моем случае хорошо регистрировать вещи?

см. выше.

      o What I need to log?

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

При ведении класса вы также должны записывать соответствующие данные.

• Как лучше всего записывать файлы (текстовые файлы, базы данных...)?

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

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

Ответ 7

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

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

Аналогично, если у вас нет инструментов для отладки в реальном времени, вам нужно зарегистрировать или включить ведение журнала для точек ввода/выхода.

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

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

Ответ 8

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

Хорошие журналы становятся важными во время производства. Перечислите проблемы, с которыми вы столкнетесь, и запишите информацию, необходимую для решения этих проблем. Будете ли вы привлечены к ответственности за нарушение авторских прав? Затем запишите, что вам нужно, чтобы защитить себя. Будут ли люди сообщать об ошибках со своими читателями и просить о помощи? Затем запишите, что вам нужно, чтобы ответить на вопросы и свести к минимуму расходы на поддержку.

Легко записывать слишком много (бесполезную) информацию. Если вам это не нужно, не регистрируйте его. Попадут ли серверы? Сбой сетей? У вас закончится хранение? Да, и вы можете войти в систему, чтобы помочь диагностировать эти проблемы, но это главным образом работа для мониторинга, а не регистрация.

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