Технология ведения лога (диагностика)

  • Автор темы _Tanatos_
  • Дата начала
Статус
Закрыто для дальнейших ответов.
T

_Tanatos_

Гость
#1
День добрый!

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

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

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

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

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

И еще, в коде будут использоваться прерывания ... как бы все это совместить ??? пока предполагаю внутри функции всегда ставить try{}__finally{} для фиксации входа и выхода, иначе дерево в случае ошибки просто умирает (пока фиксирую родительскую запись через push в начале функции и pop в конце (в блоке __finally) - родитель всегда последний).

У кого какие мысли есть по этому поводу? Буду благодарен за любую помощь и подсказку!
Вообще вопрос довольно объемный, думаю многим будет интересно.

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

grigsoft

Well-Known Member
15.11.2005
735
0
#2
На codeproject можно найти пару проектов по сбору информации во время вылета. При условии, что стек жив - этого достаточно. Все полные логи годятся только для отладки - в реально работающем приложении это будет занимать непозволительно много времени\памяти.
 
T

_Tanatos_

Гость
#3
Спасибо за ссылку.

С утверждением насчет "непозволительности" позволю себе не согласиться с Вами. Когда нужно оперативно реагировать на все замечания и тем более на каши или сбои в работе такие расходы очень даже позволительны. С#, .NET и Java тоже использутся для чего-то, хотя тоже использут ресурсы "непозволительно" ...
 

grigsoft

Well-Known Member
15.11.2005
735
0
#4
Так это, всяких каш и сбоев в работе как бы быть не должно :) Я вовсе не против, но в видимых мной реальных приложениях попытки вести реальный лог вызовов приводили к не возможности использовать программу. Если в вашем случае это не мешает, я только рад. Обычно такие вещи можно навешивать на небольшие сложные участки, где не удается отловить ошибку обычными методами. И уверяю Вас, накладные расходы .NET и Java - это цветочки по сравнению с логом реально всех вызовов.
 
04.09.2006
2 566
2
#5
Для: _Tanatos_
Если у вас есть возможность отладки среднего проекта под Borland С++ Builder c включенным и выключенным CodeGuard-ом, то можете заметить, что разница в быстродействии - разы, причем это заметно на глаз. Вообще grigsoft прав:

<!--QuoteBegin-grigsoft+21:11:2007, 10:45 -->
<span class="vbquote">(grigsoft @ 21:11:2007, 10:45 )</span><!--QuoteEBegin-->Обычно такие вещи можно навешивать на небольшие сложные участки, где не удается отловить ошибку обычными методами.
[snapback]86733" rel="nofollow" target="_blank[/snapback]​
[/quote]
 
T

_Tanatos_

Гость
#6
Не спорю, вышесказанное по поводу быстродействия имеет место быть. но я и не говорил, что собираюсь протоколировать КАЖДЫЙ вызов - можно конечно навесить протоколирование вообще на каждую функцию но это уже абсурд. Потом можно компилировать программу с различной степенью детализации лога, плюс можно настраивать (программно) какие модули и до какой степени детализации надо писать в файл. Например есть сбой который неудается отловить, скомпилил нужную веросию с максимальной отладкой и подменил - вуаля есть подробнейший отчет, исправил и снова лог ведется в стандартном режиме. просто такие вещи надо писать изначально - потом уже недопишешь ведение лога в 200 функций, дабы разобраться с ошибкой, а эмулировать ситуацию не всегда возможно. иногда лог единственная имеющаяся информация для отладки.
 
Статус
Закрыто для дальнейших ответов.