Я работаю с критически важными для безопасности системами реального времени, и регистрация часто является единственным способом ловить редкие ошибки, которые появляются один раз в синюю луну каждый 53-й вторник, когда наступает полнолуние, если вы ловите мой дрейф. Этот вид делает вас одержимым предметом, поэтому я сейчас извинюсь, если начну пениться у рта. Следующее было написано для журналов отладки собственного кода, но большинство из них применимо и к управляемому миру ...
Используйте текстовые файлы журнала. Кажется очевидным, но некоторые люди пытаются сгенерировать двоичные файлы журналов: это просто глупо, потому что мне не нужно искать инструмент для чтения, когда я в поле. Плюс, если это текст, а отладка многословна, есть хороший шанс, что полевой инженер сможет прочитать файл и диагностировать проблему, не возвращаясь ко мне. Все побеждают.
Я проектирую системы, которые способны регистрировать практически все, но я не включаю все по умолчанию. Отладочная информация отправляется в скрытое диалоговое окно отладки, которое ставит метки времени и выводит его в список (ограниченный до 500 строк перед удалением), и диалоговое окно позволяет мне остановить его, автоматически сохранить в файле журнала или перенаправить в прикрепленный отладчик. Это отвлечение позволяет мне видеть вывод отладки из нескольких приложений, все аккуратно сериализованные, что иногда может быть спасением. Я использовал , чтобы использовать цифровые уровни ведения журнала (чем выше вы установите уровень, тем больше вы захват):
off
errors only
basic
detailed
everything
но это слишком негибко - поскольку вы работаете над ошибкой, гораздо эффективнее иметь возможность сосредоточиться на входе именно на том, что вам нужно, без необходимости разбираться с кучей детрита, и это может быть один конкретный вид транзакции или операции это вызывает ошибку. Если для этого требуется, чтобы вы все включили, вы просто усложняете свою работу. Вам нужно что-то более мелкое.
Итак, сейчас я нахожусь в процессе перехода к ведению журнала на основе системы флагов. Все, что регистрируется, имеет флаг, подробно описывающий, какая это операция, и есть набор флажков, позволяющих мне определять, что регистрируется. Обычно этот список выглядит так:
#define DEBUG_ERROR 1
#define DEBUG_BASIC 2
#define DEBUG_DETAIL 4
#define DEBUG_MSG_BASIC 8
#define DEBUG_MSG_POLL 16
#define DEBUG_MSG_STATUS 32
#define DEBUG_METRICS 64
#define DEBUG_EXCEPTION 128
#define DEBUG_STATE_CHANGE 256
#define DEBUG_DB_READ 512
#define DEBUG_DB_WRITE 1024
#define DEBUG_SQL_TEXT 2048
#define DEBUG_MSG_CONTENTS 4096
Эта система ведения журнала поставляется с версией сборки, включенной и сохраняемой в файл по умолчанию. Уже слишком поздно выяснять, что вы должны были регистрироваться ПОСЛЕ того, как произошла ошибка, если эта ошибка возникает в среднем раз в шесть месяцев, и у вас нет возможности ее воспроизвести. Ведение журнала, которое работает только с отладочными сборками, просто. равнина. тупой.
Программное обеспечение обычно поставляется с включенными ERROR, BASIC, STATE_CHANGE и EXCEPTION, но это можно изменить в поле через диалоговое окно отладки (или настройки реестра / ini / cfg, где эти вещи сохраняются).
Да, и одно: моя система отладки генерирует один файл в день. Ваши требования могут отличаться. Но убедитесь, что ваш код отладки начинает каждый файл с даты, версии кода, который вы запускаете, и, если возможно, некоторого маркера для идентификатора клиента, местоположения системы или чего-либо еще. Вы можете получить кучу файлов журналов, поступающих с поля, и вам понадобится некоторая запись того, откуда и какая версия системы, на которой они работали, на самом деле в самих данных, и вы не можете доверять клиенту. / Инженер-полевой, чтобы сказать вам, какая у них версия - они могут просто сказать вам, какую версию, по их мнению, они получили. Хуже того, они могут сообщить версию exe, которая находится на диске, но старая версия все еще работает, потому что они забыли перезагрузить компьютер после замены. Пусть ваш код скажет вам сам.
Наконец, вы не хотите, чтобы ваш код генерировал свои собственные проблемы, поэтому вставьте функцию таймера для очистки файлов журнала через столько дней или недель (просто проверьте разницу между временем сейчас и временем создания файла). Это нормально для серверного приложения, которое работает постоянно, в клиентском приложении вы можете очистить все старые данные при запуске. Обычно мы производим очистку через 30 дней или около того, в системе без частых посещений инженера вы можете оставить ее подольше. Очевидно, это также зависит от размера ваших файлов журнала.