Уровень 1. Начинающий.
Как правило, о протоколировании начинаешь задумываться, когда сталкиваешься с проблемами работы приложения на производственной среде Заказчика. Т.к., как говорилось ранее, не всегда у Заказчика возможно развернуть графические инструменты отладки, то приходится реализовывать инструмент протоколирования, например, запись в файл. Обычно разработчики начиняют свой код разного рода сообщениями, по которым он может понять до куда программа дошла, какие значения переменных имела и т.д. Иногда даже удается найти источник ошибки. После чего разработчику необходимо пересобрать приложение, убрав излишнее протоколирование или просто закомментировать, т.к. сильно частый вывод сообщений в протоколировании может уменьшить быстродействие приложения, поскольку тратится время на сам вывод сообщений. Но что происходит, когда появляется новая ошибка в приложении? Правильно, разработчик опять внедряет отладочные сообщения. Кстати, вполне реально, что он будет это делать в уже «отлаженном» в прошлый раз коде.
Какие минусы видны (самые очевидные):
· Не смотря на то, что мы внедрили протоколирование, может оказаться, что зря, т.к. не все ошибки удается повторно воспроизвести.
· Не все приложения можно перезапускать. Например, работающий веб-магазин.
· Хотелось бы управлять уровнями вывода сообщений: в момент отлова ошибки писать все сообщения, во время функционирования приложения – только самые важные.
· Приходится прибегать к перекомпиляции приложения. Хочется вообще не менять код.
· Trace. Это дополнительная возможность просматривать стек вызовов до момента наступления ошибки.
Уровень 2. Продвинутый.
Чтобы по сто раз не убирать и не добавлять трассировку, инструкции трассировки можно комментировать так, чтобы их можно было легко включать или отключать по мере необходимости (все сразу). Например, используя условную компиляцию.
Можно также использовать стандартные функции протоколирования из пространства имен System.Diagnostics: Debug.Write (или WriteLine - write to the Debug console) или Trace.Write (или WriteLine - writes trace output). Они работают похожим образом. Различие только в том, что каждая из них контролируется различной Pragma. Когда определена константа DEBUG, то Debug.Write и Debug.WriteLine разрешены. Когда определена Pragma TRACE, то включено Trace.Write и Trace.WriteLine. Оба метода (Debug и Trace) могут использоваться в режиме отладки приложения. Но в режиме Release работает только Trace. Т.о. на практике можно использовать для предоставлении информации, когда проводится модульное тестирование и для предоставления информации после развертывания приложения.
На этом уровне мы избавляемся от некоторых минусов:
· Не надо постоянно пересобирать приложение. Всегда в распоряжении будет два вида приложения: отладочное, в котором внедрено частое протоколирование, и релизное, в котором выводятся только самые важные сообщения.
· Также, но уже в зависимости от уровня разработчика, можно внедрить вывод Trace-информации.
Уровень 3. Профессиональный.
Когда разработчик устает от таких вот недологгеров (очень мало функциональности и они сложны в эксплуатации), он почему-то сразу хочет написать свой простенький логгер, в котором реализует свои лучшие практики протоколирования. Как говорилось выше, по этому пути пошел и я.
Была внедрена следующая функциональность:
· Протоколирование в разные места (реализация есть только для файла и системного лога).
· Формат - xml, могут быть разные сообщения. Планировалось писать viewer,который бы отображал по разному сообщения.
· Переименование файлов при достижении указанного размера
· Архивирование (zip)
· Удаление файлов старее на указанное количество времени относительно текущего
· Программная настройка
Как видно, функциональность не богатая. Перечислю какое расширение функциональности напрашивается:
· Вывод в лог информации о том, в каком методе было вызвано протоколирование и значение глобальных переменных (Logger.NET) или переменных класса (DebugWriter)
· Расширение функциональности (CSharpDotNetLogger)
· Для веб-приложений: лучшая запись информации в iis-логе (с человеколюбивыми названиями, отфильтрованная информация) (TrafficMonitor)
· Просмотр отладочных сообщений в приложении мониторинга (Tracert, Logview4net), в т.ч. в режиме реального времени (TraceRT.NET, DebugViewforWindowsv4.76, TcpTrace).
Уровень 4. Гуру.
Очевидно, что тема протоколирования не нова. Поэтому, скорее всего уже есть готовые профессиональные средства протоколирования, которыми пользуется ни одна тысяча разработчиков в мире. Поэтому надо попробовать поискать их.
Какие же требования можно выделить к таким решениям?
· Расширяемые.
· Протоколирование комплексных структур данных,стеки вызовов, поведение потоков.
· Поддержка мониторинга в режиме реального времени приложений по сети или на локальной машине.
· Изменение логики протоколирования без перекомпиляции приложения.
· И тд.
В следующем разделе рассмотрим более подробно требования к решениям. 
Комментариев нет:
Отправить комментарий