Как стать автором
Обновить

Комментарии 39

НЛО прилетело и опубликовало эту надпись здесь
>Если приложение что-нибудь запишет в лог перед тем как упасть, в логе вы ничего не увидите, какой >тогда в нем смысл?
Как минимум будет видна точка падения, а на основании этого уже можно производить дальнейшие исследования.
>К тому-же, в лог не выводятся идентификатор процесса — потока, именованный мьютекс в коде говорит >о том, что могут быть запущены несколько экземпляров одной программы, пишущих в один файл(что >плохо), следовательно, нужно либо разделять вывод в разные файлы, либо указывать ид-р процесса
Про ID процесса это спорный вопрос, я считаю, что если будет необходимость в ID процесса то это должно быть частью message которое поступает в ф-ию записи извне. Разные файлы так же должны настраиваться при запуске приложения, почему это должно быть частью логики самого класса логирования?
>Ну и напоследок: лучше, что-бы логгер не бросал исключения, так-как он часто используется при >обработке критических ситуаций, а шанс, что что нибудь пойдет не так в этой ситуации выше
Если назначена процедура обработки ошибки, тогда будет выполнена она, что сделать в ней это уже дело пользователя. Можно просто проглатить ошибку, реализация класса это позволяет.
НЛО прилетело и опубликовало эту надпись здесь
> m_xOfstream << m_xParameters.m_pObfuscater(xFinalString) << std::endl;
так, что данные не буферизуются. А что за буферизация ОС? И даже если таковая будет иметь место, то на диск все равно будет сброшено, т.к буферизация ОС не может зависеть от приложения…
НЛО прилетело и опубликовало эту надпись здесь
sourceforge.net/projects/log4cpp/
там двольно серьезная реализация, на первый взгляд, не всем нужно подобное.
А когда вы C++ используете(он же серьезный ЯП), то обязательно всеми стандартными библиотеками в нем пользуетесь?)
Есть разные задачи. Логирование не такая сложная задача, чтобы тянуть с ней крупные библиотеки.
Я конечно понимаю, что лог в текстовые файлы это бородатая классика, и дозапись работает хорошо. Но почему бы ни писать логи, например, в sqlite?
Накрутить можно как угодно, если кому-то необходимо использовать для логов БД, то этого его право. Я такого не встречал и смысла в этом не вижу.
При грамотной организации структуры БД, для хранения логов, можно организовать удобный и быстрый поиск по ним. Тем более, что в некоторых случаях, логи — имеют критическую важность (системы охраны, банковские системы), а их размер достигает огромных значений. В таких случаях играет важность не только их информативность, но и их сохранность, и удобный интерфейс доступа к ним. БД, в таких случаях, — очень хороший вариант. Соответственно, хорошая система логгирования должна быть спроектирована так, чтобы предоставить приложению универсальный front-end, с возможностью выбора одного или нескольких back-end-ов, в том числе самописных, в том числе на лету.
Я просто не сталкивался с подобным, спасибо за обьяснение. Насчет front-end к логам это хорошая идея.
логирование на полноценный сервер sql я ещё понимаю: централизованная система сбора отчётов, особенно, если приложение и так работает с БД — всякие логические ошибки искать проще, логированием занимается _самостоятельная_ надёжная система. Правда, локального не отменяет, но туда можно писать только определённую группу событий.

sqlite — это не самостоятельный сервис, т.е. имеет место дополнительное усложнение самого клиента. Иными словами словами, велика вероятность, что сам sqlite сломается в первую очередь.
В случае «сломается» и усложнения да. Но к sqlite'у есть множество клиентов на любой «вкус и цвет». А для отлова «логических» ошибок копаться в гигабайтном текстовом логе, или паре сотен лог-файлов, или запускать полноценную бд, мне кажется перебором во многих случаях. В моём так точно.
Читать неудобно. Логи должны быть текстовыми (привет, Майкрософт).
Как раз читать и удобнее: группировка, сортировка… ;)
Какая ещё сортировка, логи должны быть в том порядке, в каком пришли — в хронологическом! А группировка отлично выполняется при помощи grep.
А у вас наверное всегда 1 поток в программе?))
А это тут при чём?

Если что, фильтровать по потокам можно grepом, а если нужно отладить именно взаимодействие потоков — как раз именно хронологический порядок возникновения событий в потоках важен, разумеется, ни о какой сортировке речи не идёт.
>> Читать неудобно.
Так и вижу: выходит чувак из сортира с рулоном логов. XD

P.S.: Даже у FF есть расширение «SQLite Manager».
Вы знаете, один из самых говнистых интерфейсов чтения логов — это MS Event Log встроенный. Я виндовские логи читаю так: пересылаю посредством el2sl в соседний syslog-сервер на базе линукс (туда со всей локалки логи стекаются), а там уже в текстовых файлах — grep, tail и т. д.

Чтение логов — примерно 10% моего рабочего времени, и знаете ли, искал другие подходы — более удобного нет.
Я вообще считаю, что изобретать велосипед в таких вещах — не совсем правильно. Если бы передо мною стояла бы такая задача, я либо использовал готовую проверенную библиотеку, либо писал бы все сам, но как обертку для родной системы логгирования ОС (syslog или windows event log). Т.к. в случае с тем же syslog-ом я получаю возможность использовать logrotate без костылей и геморроя (многие самописные системы логгирования глючат из-за logrotate), пересылку логов на удаленный сервер, стандартный для системы формат записи данных, запись логов от имени другого пользователя и т.п. Причем, что радует, тот же syslog старый и проверенный временем и в боях проект.
ППКС!
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите на glog (google logs), его использование можно найти в большинстве проектов Google (каждый раз почему-то модифицируется, не смотря на то что полная библиотека дает малый footprint и имплементирует в принципе все что нужно).

Так же не забываем, что если идем на Windows Logo, то логировать все-таки надо в Event Log (glog это не реализует, само собой).
за google log спасибо, посмотрю.
А вот второго предложения я не понял, зачем использовать event log?
Это из guide от MS, особенно, если вы планируете получить Works with * / Certified for * Logo. На самом деле в этом есть доля разумного. В ОС Windows есть отличный инструмент, который обладает большим функционалом, открытым API и т.д., почему бы его не использовать? Разумно не только для серверного семейства, на самом деле.
НЛО прилетело и опубликовало эту надпись здесь
Event Log нужен и обязателен потому, что это стандартный системный сервис логирования. Реализует сбор, распределение, ротацию логов, в Windows Server 2008 — ещё и можно навесить триггеры, чтобы при появлении определённых событий выполнялось нужное действие.

В идеале, все программы пишут свои логи туда, а администратор при необходимости их читает при помощи унифицированного интерфейса. Унификация таких интерфейсов необходима, сокращает кучу, кучу времени.
А если логи генерятся со скоростью примерно 100 строк в секунду, что будет с event логом? Тем более, что он разделен для всех приложений. Просто если все приложения будут пистаь свои логи в event log, то он превратится в помойку.
Можно создать собственный лог, а не валить всё в Application например, тогда помойки не будет.
Не превратится. Там можно при желании фильтровать по приложению, сгенерировавшему событие, а можно, как посоветовали ниже, отдельный ивентлог завести.

И кстати, 100 строк в секунду в логах быть не должно — если у вас такая ситуация возникла, вы наверняка что-то неправильно делаете и такие логи наверняка бесполезны. Просто такую кучу сообщений потом читать нереально. Надо сразу задумываться о том, какие из них важные, а остальные вообще не логировать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Расскажите пожалуйста, чем ваш велосипед лучше, чем boost::log и log4cxx и почему нужно использовать именно его.
Учитывая, что об обеих библиотеках я узнал только сегодня, я не могу ответить на данный вопрос. А также учитывая то, что я не пытался сделать универсального решения на все случаи жизни, а предоставил всего лишь один из вариантов, для тех, кто не хочет писать свой класс, мне кажется некорректной попытка сравнения моего небольшого класса с полноценной библиотекой.
если вы используете буст то вместо GetSystemTime можно использовать вызов microsec_clock::local_time() из boost.date_time — это кроссплатформенно — плюс время само форматируется как удобно пользователю ( если вынести это в конфиг ).
Спасибо большое! Я когда искал в бусте высокорезолюционное получение времени, то не нашел этого класса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории