Comments 39
>Если приложение что-нибудь запишет в лог перед тем как упасть, в логе вы ничего не увидите, какой >тогда в нем смысл?
Как минимум будет видна точка падения, а на основании этого уже можно производить дальнейшие исследования.
>К тому-же, в лог не выводятся идентификатор процесса — потока, именованный мьютекс в коде говорит >о том, что могут быть запущены несколько экземпляров одной программы, пишущих в один файл(что >плохо), следовательно, нужно либо разделять вывод в разные файлы, либо указывать ид-р процесса
Про ID процесса это спорный вопрос, я считаю, что если будет необходимость в ID процесса то это должно быть частью message которое поступает в ф-ию записи извне. Разные файлы так же должны настраиваться при запуске приложения, почему это должно быть частью логики самого класса логирования?
>Ну и напоследок: лучше, что-бы логгер не бросал исключения, так-как он часто используется при >обработке критических ситуаций, а шанс, что что нибудь пойдет не так в этой ситуации выше
Если назначена процедура обработки ошибки, тогда будет выполнена она, что сделать в ней это уже дело пользователя. Можно просто проглатить ошибку, реализация класса это позволяет.
Как минимум будет видна точка падения, а на основании этого уже можно производить дальнейшие исследования.
>К тому-же, в лог не выводятся идентификатор процесса — потока, именованный мьютекс в коде говорит >о том, что могут быть запущены несколько экземпляров одной программы, пишущих в один файл(что >плохо), следовательно, нужно либо разделять вывод в разные файлы, либо указывать ид-р процесса
Про ID процесса это спорный вопрос, я считаю, что если будет необходимость в ID процесса то это должно быть частью message которое поступает в ф-ию записи извне. Разные файлы так же должны настраиваться при запуске приложения, почему это должно быть частью логики самого класса логирования?
>Ну и напоследок: лучше, что-бы логгер не бросал исключения, так-как он часто используется при >обработке критических ситуаций, а шанс, что что нибудь пойдет не так в этой ситуации выше
Если назначена процедура обработки ошибки, тогда будет выполнена она, что сделать в ней это уже дело пользователя. Можно просто проглатить ошибку, реализация класса это позволяет.
sourceforge.net/projects/log4cpp/
Я конечно понимаю, что лог в текстовые файлы это бородатая классика, и дозапись работает хорошо. Но почему бы ни писать логи, например, в sqlite?
Накрутить можно как угодно, если кому-то необходимо использовать для логов БД, то этого его право. Я такого не встречал и смысла в этом не вижу.
При грамотной организации структуры БД, для хранения логов, можно организовать удобный и быстрый поиск по ним. Тем более, что в некоторых случаях, логи — имеют критическую важность (системы охраны, банковские системы), а их размер достигает огромных значений. В таких случаях играет важность не только их информативность, но и их сохранность, и удобный интерфейс доступа к ним. БД, в таких случаях, — очень хороший вариант. Соответственно, хорошая система логгирования должна быть спроектирована так, чтобы предоставить приложению универсальный front-end, с возможностью выбора одного или нескольких back-end-ов, в том числе самописных, в том числе на лету.
логирование на полноценный сервер sql я ещё понимаю: централизованная система сбора отчётов, особенно, если приложение и так работает с БД — всякие логические ошибки искать проще, логированием занимается _самостоятельная_ надёжная система. Правда, локального не отменяет, но туда можно писать только определённую группу событий.
sqlite — это не самостоятельный сервис, т.е. имеет место дополнительное усложнение самого клиента. Иными словами словами, велика вероятность, что сам sqlite сломается в первую очередь.
sqlite — это не самостоятельный сервис, т.е. имеет место дополнительное усложнение самого клиента. Иными словами словами, велика вероятность, что сам sqlite сломается в первую очередь.
Читать неудобно. Логи должны быть текстовыми (привет, Майкрософт).
Как раз читать и удобнее: группировка, сортировка… ;)
>> Читать неудобно.
Так и вижу: выходит чувак из сортира с рулоном логов. XD
P.S.: Даже у FF есть расширение «SQLite Manager».
Так и вижу: выходит чувак из сортира с рулоном логов. XD
P.S.: Даже у FF есть расширение «SQLite Manager».
Вы знаете, один из самых говнистых интерфейсов чтения логов — это MS Event Log встроенный. Я виндовские логи читаю так: пересылаю посредством el2sl в соседний syslog-сервер на базе линукс (туда со всей локалки логи стекаются), а там уже в текстовых файлах — grep, tail и т. д.
Чтение логов — примерно 10% моего рабочего времени, и знаете ли, искал другие подходы — более удобного нет.
Чтение логов — примерно 10% моего рабочего времени, и знаете ли, искал другие подходы — более удобного нет.
Я вообще считаю, что изобретать велосипед в таких вещах — не совсем правильно. Если бы передо мною стояла бы такая задача, я либо использовал готовую проверенную библиотеку, либо писал бы все сам, но как обертку для родной системы логгирования ОС (syslog или windows event log). Т.к. в случае с тем же syslog-ом я получаю возможность использовать logrotate без костылей и геморроя (многие самописные системы логгирования глючат из-за logrotate), пересылку логов на удаленный сервер, стандартный для системы формат записи данных, запись логов от имени другого пользователя и т.п. Причем, что радует, тот же syslog старый и проверенный временем и в боях проект.
Посмотрите на glog (google logs), его использование можно найти в большинстве проектов Google (каждый раз почему-то модифицируется, не смотря на то что полная библиотека дает малый footprint и имплементирует в принципе все что нужно).
Так же не забываем, что если идем на Windows Logo, то логировать все-таки надо в Event Log (glog это не реализует, само собой).
Так же не забываем, что если идем на Windows Logo, то логировать все-таки надо в Event Log (glog это не реализует, само собой).
за google log спасибо, посмотрю.
А вот второго предложения я не понял, зачем использовать event log?
А вот второго предложения я не понял, зачем использовать event log?
Это из guide от MS, особенно, если вы планируете получить Works with * / Certified for * Logo. На самом деле в этом есть доля разумного. В ОС Windows есть отличный инструмент, который обладает большим функционалом, открытым API и т.д., почему бы его не использовать? Разумно не только для серверного семейства, на самом деле.
Event Log нужен и обязателен потому, что это стандартный системный сервис логирования. Реализует сбор, распределение, ротацию логов, в Windows Server 2008 — ещё и можно навесить триггеры, чтобы при появлении определённых событий выполнялось нужное действие.
В идеале, все программы пишут свои логи туда, а администратор при необходимости их читает при помощи унифицированного интерфейса. Унификация таких интерфейсов необходима, сокращает кучу, кучу времени.
В идеале, все программы пишут свои логи туда, а администратор при необходимости их читает при помощи унифицированного интерфейса. Унификация таких интерфейсов необходима, сокращает кучу, кучу времени.
А если логи генерятся со скоростью примерно 100 строк в секунду, что будет с event логом? Тем более, что он разделен для всех приложений. Просто если все приложения будут пистаь свои логи в event log, то он превратится в помойку.
Можно создать собственный лог, а не валить всё в Application например, тогда помойки не будет.
Не превратится. Там можно при желании фильтровать по приложению, сгенерировавшему событие, а можно, как посоветовали ниже, отдельный ивентлог завести.
И кстати, 100 строк в секунду в логах быть не должно — если у вас такая ситуация возникла, вы наверняка что-то неправильно делаете и такие логи наверняка бесполезны. Просто такую кучу сообщений потом читать нереально. Надо сразу задумываться о том, какие из них важные, а остальные вообще не логировать.
И кстати, 100 строк в секунду в логах быть не должно — если у вас такая ситуация возникла, вы наверняка что-то неправильно делаете и такие логи наверняка бесполезны. Просто такую кучу сообщений потом читать нереально. Надо сразу задумываться о том, какие из них важные, а остальные вообще не логировать.
Расскажите пожалуйста, чем ваш велосипед лучше, чем boost::log и log4cxx и почему нужно использовать именно его.
Учитывая, что об обеих библиотеках я узнал только сегодня, я не могу ответить на данный вопрос. А также учитывая то, что я не пытался сделать универсального решения на все случаи жизни, а предоставил всего лишь один из вариантов, для тех, кто не хочет писать свой класс, мне кажется некорректной попытка сравнения моего небольшого класса с полноценной библиотекой.
если вы используете буст то вместо GetSystemTime можно использовать вызов microsec_clock::local_time() из boost.date_time — это кроссплатформенно — плюс время само форматируется как удобно пользователю ( если вынести это в конфиг ).
Sign up to leave a comment.
Необходимо ли логирование программ?