Этикет ведения журнала

Question

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

Какое из этих решений является способом работы в Linux / Unix / MacOS?

Кроме того, кто-нибудь может предложить библиотеку журналов для C ++ / C? Мне нужно, независимо от ответа на поставленный выше вопрос.

Answer 1

Загляните в /var/log/... Вы увидите, что файлы структурированы как

serverlog
serverlog.1
serverlog.2

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

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

Answer 2

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

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

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

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

Также есть несколько полезных советов:

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

• Записи в журнале должны быть настолько автономными, насколько это возможно, с минимальными затратами. Вам не нужно иметь специальный заголовок с цветами, колокольчиками и свистками, чтобы объявить, что ваш сервер запускается - простого MyServer (PID = XXX), начинающегося с порта YYYYY , будет достаточно для grep ( или функция поиска любого приличного средства просмотра журнала), чтобы найти.

• Вам необходимо определить гранулярность каждого канала регистрации. Отправка нескольких ГБ данных журнала отладки системному журналу регистрации - не хорошая идея. Хорошим подходом может быть использование отдельных файлов журнала для каждого уровня ведения журнала и объекта, например, активность пользователя не смешивается с низкоуровневыми данными, которые полезны только при отладке кода.

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

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

• Используйте средства обработки системного журнала. Например. в Linux это означало бы добавление к одному и тому же файлу и разрешение внешнему демону, например logrotate, обрабатывать файлы журнала. Мало того, что это будет меньше работать для вас, это также автоматически поддержит все общие политики ведения журнала в целом.

• Наконец: всегда копируйте важные данные журнала также в системный журнал. Операторы следят за системными журналами. Пожалуйста, пожалуйста, пожалуйста не заставляйте их искать в других местах, просто чтобы узнать, что ваше приложение собирается запустить МБР ...

Answer 3

https://stackoverflow.com/questions/696321/best-logging-framework-for-native-c

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