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

Тема в разделе "Общие вопросы по С и С++", создана пользователем _Tanatos_, 20 ноя 2007.

Статус темы:
Закрыта.
  1. _Tanatos_

    _Tanatos_ Гость

    День добрый!

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

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

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

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

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

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

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

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

    grigsoft Well-Known Member

    Регистрация:
    15 ноя 2005
    Сообщения:
    735
    Симпатии:
    0
    На codeproject можно найти пару проектов по сбору информации во время вылета. При условии, что стек жив - этого достаточно. Все полные логи годятся только для отладки - в реально работающем приложении это будет занимать непозволительно много времени\памяти.
     
  3. _Tanatos_

    _Tanatos_ Гость

    Спасибо за ссылку.

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

    grigsoft Well-Known Member

    Регистрация:
    15 ноя 2005
    Сообщения:
    735
    Симпатии:
    0
    Так это, всяких каш и сбоев в работе как бы быть не должно :) Я вовсе не против, но в видимых мной реальных приложениях попытки вести реальный лог вызовов приводили к не возможности использовать программу. Если в вашем случае это не мешает, я только рад. Обычно такие вещи можно навешивать на небольшие сложные участки, где не удается отловить ошибку обычными методами. И уверяю Вас, накладные расходы .NET и Java - это цветочки по сравнению с логом реально всех вызовов.
     
  5. European

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    Для: _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]
     
  6. _Tanatos_

    _Tanatos_ Гость

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

Поделиться этой страницей