Зарегистрироваться или не зарегистрироваться?

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

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

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

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

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

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

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

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

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

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

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

• В моем случае полезно вести журнал?

см. выше.

 o Что мне нужно вести журнал?

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

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

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

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

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

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

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

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

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

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

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

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

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

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