Трассировка — это мониторинг выполнения запущенного приложения. Вы можете добавить инструментирование трассировки и отладки в свое приложения .NET Framework при его разработке; кроме того, вы можете использовать это инструментирование при разработке приложения и после его развертывания. С помощью классов System.Diagnostics.Trace, System.Diagnostics.Debug и System.Diagnostics.TraceSource можно записывать сведения об ошибках и выполнении приложения в журналы, текстовые файлы или на другие устройства для последующего анализа.
Термин инструментирование относится к возможности мониторинга и измерения уровня производительности продукта и диагностики ошибок. В программировании это означает способность приложения включать следующие возможности.
- Трассировка кода — получение информационных сообщений о работе приложения во время выполнения.
- Отладка — отслеживание и устранение ошибок программирования в приложении при разработке. Дополнительные сведения см. в разделе Отладка.
- Счетчики производительности — компоненты, позволяющие отслеживать производительность приложения. Дополнительные сведения см. в статье Performance Counters.
- Журналы событий — компоненты, позволяющие получать и отслеживать основные события при выполнении приложения. Дополнительные сведения см. в описании класса EventLog.
Инструментирование приложения путем добавления операторов трассировки в стратегически важных местах кода особенно полезно для распределенных приложений. С помощью операторов трассировки можно инструментировать приложение не только для отображения сведений о неправильных моментах, но также отслеживать, насколько хорошо работает приложение.
Информатика 8 класс Трассировка алгоритма
Класс TraceSource предоставляет улучшенные функции трассировки и может использоваться вместо статических методов более старых классов трассировки Trace и Debug. Знакомые классы Trace и Debug по-прежнему широко используются, однако рекомендуется использовать класс TraceSource для новых команд трассировки, таких как TraceEvent и TraceData.
Классы Trace и Debug идентичны, за исключением того, что процедуры и функции класса Trace по умолчанию компилируются в сборки выпуска, а процедуры и функции класса Debug — нет.
Классы Trace и Debug предоставляют средства для мониторинга и исследования производительности приложения как во время разработки, так и после развертывания. Например, возможно использование класса Trace для отслеживания в развернутом приложении отдельных типов действий по мере их выполнения (например, создание новых подключений к базе данных) и последующего мониторинга производительности приложения.
Отладка и трассировка кода
Использование методов вывода класса Debug при разработке приложения позволяет отображать сообщения в окне вывода, доступном в интегрированной среде разработки Visual Studio. Пример:
Trace.WriteLine(«Hello World!») Debug.WriteLine(«Hello World!»)
System.Diagnostics.Trace.WriteLine(«Hello World!»); System.Diagnostics.Debug.WriteLine(«Hello World!»);
В каждом из этих примеров будет отображаться сообщение Hello World! в окне вывода при запуске приложения в отладчике.
Трассировка алгоритма
Это позволяет отлаживать приложения и оптимизировать их производительность на основе их поведения в среде тестирования. Возможна отладка приложения при отладочном построении с включенным условным атрибутом Debug, что позволяет получать все выходные данные отладки.
Когда приложение будет готово к выпуску, можно скомпилировать построение выпуска, не включая условный атрибут Debug, чтобы код отладки не включался компилятором в конечный исполняемый файл. Дополнительные сведения см. в разделе Практическое руководство. Условная компиляция с использованием атрибутов Trace и Debug. Дополнительные сведения о различных конфигурациях сборок для приложения см. в разделе Компиляция и сборка.
С помощью методов класса Trace можно отслеживать выполнение кода в установленном приложении. Процессом и масштабом трассировки можно управлять. Для этого добавьте в код переключатели трассировки. Так вы сможете отслеживать состояние приложения в рабочей среде.
Это особенно важно в бизнес-приложениях, которые используют различные компоненты, выполняющиеся на нескольких компьютерах. Вы можете управлять порядком использования переключателей после развертывания с помощью файла конфигурации. Дополнительные сведения см. в разделе Практическое руководство. Создание, инициализация и настройка переключателей трассировки.
При разработке приложения, для которого предполагается использовать трассировку, в код приложения обычно включают сообщения трассировки и отладки. Когда все будет готово для развертывания приложения, можно скомпилировать сборку выпуска без включения условного атрибута Debug. Тем не менее можно включить условный атрибут Trace, чтобы компилятор включил код трассировки в исполняемый файл. Дополнительные сведения см. в разделе Практическое руководство. Условная компиляция с использованием атрибутов Trace и Debug.
Этапы трассировки кода
Существует три этапа трассировки кода.
- Инструментирование — добавление кода трассировки в приложение.
- Трассировка — код трассировки записывает сведения в указанный целевой объект.
- Анализ — оценка сведений трассировки для определения и понимания проблем в приложении.
Во время разработки все методы вывода трассировки и отладки записывают сведения в окне вывода Visual Studio по умолчанию. В развернутом приложении эти методы записывают сведения трассировки в указанные целевые объекты. Дополнительные сведения об указании целевого объекта выходных данных трассировки и отладки см. в разделе Прослушиватели трассировки.
Ниже приведен полный обзор основных шагов, обычно выполняемых при использовании трассировки для анализа и исправления возможных проблем в развертываемом приложении. Дополнительные сведения о выполнении этих шагов см. по соответствующей ссылке.
Использование трассировки в приложении
- Обдумайте, какие выходные данные трассировки вы хотите получить на месте после развертывания приложения.
- Создайте набора переключателей. Дополнительные сведения см. в статье How to: Configure Trace Switches (Настройка переключателей трассировки).
- Добавьте операторы трассировки в код приложения.
- Определите, где вы хотите получать выходные данные трассировки, и добавьте соответствующие прослушиватели. Дополнительные сведения см. в разделе Создание и инициализация прослушивателей трассировки.
- Выполните тестирование и отладку своего приложения и содержащегося в нем кода трассировки.
- Скомпилируйте приложение в исполняемый код с помощью одной из следующих процедур.
- Используйте меню Сборка со страницей Отладка диалогового окна Страницы свойств в обозревателе решений. Используйте эту процедуру при компиляции в Visual Studio. — или —
- Используйте директивы компилятора Trace и Debug для компиляции из командной строки. Дополнительные сведения см. в разделе Условная компиляция с использованием атрибутов Trace и Debug. Используйте эту процедуру при компиляции из командной строки.
- Если во время выполнения возникает проблема, включите соответствующий переключатель трассировки. Дополнительные сведения см. в разделе Настройка переключателей трассировки. Код трассировки записывает сообщения трассировки в указанный целевой объект, например в экран, текстовый файл или журнал событий. Тип прослушивателя, включенного в коллекцию, Trace.Listeners определяет целевой объект.
- Проанализируйте сообщения трассировки, чтобы обнаружить и понять проблемы в приложении.
Инструментирование трассировки и распределенные приложения
При создании распределенного приложения тестирование приложения способом, которым оно будет использоваться, может показаться сложной задачей. Немногие группы разработчиков имеют возможность протестировать все возможные сочетания операционных систем или веб-браузеров (в том числе все параметры локализованных версий) или смоделировать большое число пользователей, которые будут обращаться к приложению одновременно. В таких обстоятельствах невозможно протестировать реакцию распределенного приложения на большую нагрузку, различные настройки и разные действия конечных пользователей. Кроме того, многие компоненты распределенного приложения не имеют пользовательского интерфейса, с которым можно взаимодействовать напрямую или просматривать активность этих компонентов.
Однако вы можете компенсировать это, позволив распределенным приложениям описывать определенные события, интересующие системных администраторов, особенно то, что работает неправильно, путем инструментирования приложения, то есть путем размещения операторов трассировки в стратегически важных местах кода. Затем, если во время выполнения произойдет что-либо неожиданное (например, слишком большое время отклика), можно будет определить вероятную причину.
Операторы трассировки помогают избежать сложностей проверки исходного кода, его изменения, перекомпиляции, а также попыток воспроизвести ошибку времени выполнения в среде отладки. Помните, что можно инструментировать приложение не только для отображения ошибок, но также для наблюдения за производительностью.
Стратегическое размещение операторов трассировки
Необходимо уделить особое внимание размещению операторов трассировки для использования во время выполнения. Вы должны учесть, какие сведения трассировки скорее всего потребуются в развертываемом приложении, чтобы в полной мере охватить все вероятные сценарии трассировки. Поскольку приложения, использующие трассировку, могут быть самыми разными, не существует общих принципов стратегического размещения трассировки. Дополнительные сведения о размещении операторов трассировки см. в разделе Практическое руководство. Добавление операторов трассировки в код приложения.
Выходные данные трассировки
Выходные данные трассировки собираются объектами, которые называются прослушивателями. Прослушиватель — это объект, который принимает выходные данные трассировки и записывает их в устройство вывода (обычно это окно, журнал или текстовый файл). При создании прослушиватель трассировки, как правило, добавляется к коллекции Trace.Listeners, что позволяет ему получать все выходные данные трассировки.
Сведения трассировки всегда записываются как минимум в целевой объект вывода Trace по умолчанию, DefaultTraceListener. Если по каким-то причинам объект DefaultTraceListener был удален, а другие прослушиватели не были добавлены в коллекцию Listeners, сообщения трассировки получены не будут. Дополнительные сведения см. в разделе Прослушиватели трассировки.
В следующей таблице перечислены шесть членов класса Debug и методов класса Trace, которые записывают сведения трассировки.
| Assert | Указанный текст; если ничего не указано, то стек вызовов. Выходные данные записываются, только если условие, указанное в качестве аргумента в операторе Assert , имеет значение false. |
| Fail | Указанный текст; если ничего не указано, то стек вызовов. |
| Write | Указанный текст. |
| WriteIf | Указанный текст, если условие, указанное в качестве аргумента в операторе WriteIf , выполнено. |
| WriteLine | Заданный текст и возврат каретки. |
| WriteLineIf | Указанный текст и каретки возвращаются, если выполняется условие, указанное в качестве аргумента WriteLineIf в операторе . |
Все прослушиватели в коллекции Listeners получают сообщения, описанные в приведенной выше таблице, но предпринимаемые ими действия зависят от вида прослушивателя, получившего сообщения. Например, отображает диалоговое DefaultTraceListener окно утверждения, когда получает Fail уведомление о сбое Assert или , но TextWriterTraceListener просто записывает выходные данные в свой поток.
Можно создавать пользовательские результаты путем реализации собственного прослушивателя. Пользовательский прослушиватель трассировки может, например, отображать сообщения в окне сообщения или подключаться к базе данных для добавления сообщений в таблицу. Все пользовательские прослушиватели должны поддерживать шесть вышеупомянутых методов. Дополнительные сведения о создании прослушивателей, определяемых разработчиками, см. в описании TraceListener в справочнике по .NET Framework.
Методы Write и WriteLine всегда записывают указанный текст. Assert , WriteIf и WriteLineIf требуют логического аргумента, который определяет, пишет ли указанный текст; они записывают указанный текст только в том случае, если выражение имеет значение true (для WriteIf и WriteLineIf ) или false (для Assert ). Метод Fail всегда записывает указанный текст. Дополнительные сведения см. в разделе Практическое руководство. Добавление операторов трассировки в код приложения и в справочнике по .NET Framework.
Проблемы безопасности
Если не отключить трассировку и отладку перед развертыванием приложения ASP.NET, то приложение может отображать сведения о себе, которые могут использоваться вредоносными программами. Дополнительные сведения см. в разделах Практическое руководство. Условная компиляция с использованием атрибутов Trace и Debug, Компиляция и сборка и Практическое руководство. Создание, инициализация и настройка переключателей трассировки. Отладка также настраивается через службы IIS.
См. также раздел
- Trace
- TraceSource
- Контракты для кода
- Типы проектов C#, F# и Visual Basic
- Практическое руководство. Добавление операторов трассировки в код приложения
- Практическое руководство. Условная компиляция с использованием атрибутов Trace и Debug.
- Практическое руководство. Создание, инициализация и настройка переключателей трассировки
- Практическое руководство. Создание и инициализация источников трассировки
- Практическое руководство. Использование TraceSource и фильтров с прослушивателями трассировки
- Прослушиватели трассировки
- Переключатели трассировки
Источник: learn.microsoft.com
Трассируемость требований
Трассируемость требований (англ. requirements traceability) — в дисциплине «управление требованиями» программной инженерии — возможность отследить жизненный цикл требований по устанавливаемому между артефактами требований бинарному отношению, в общем случае транзитивному и не симметричному. Трассирование — пошаговый анализ плана, сценария или алгоритма.
Borland Caliber — одно из специализированных средств управления требованиями, поддерживающее трассируемость
Трассируемость позволяет описывать и отслеживать связи между различными артефактами требований — бизнес-требованиями, системными требованиями в различных формах (в том числе в виде вариантов использования), а в широком смысле и артефактами процесса разработки вообще.
При этом транзитивность может быть проиллюстрирована следующим образом: допустим, имеется высокоуровневая бизнес-потребность заказчика, трассирующаяся на функцию системы, в свою очередь трассирующуюся на вариант использования. В этом случае очевидно, что изменение бизнес-потребности может оказать влияние не только на непосредственно связанную с ней высокоуровневую функцию, но и на вариант использования, с которым функция связана. Исходя из тех же условий, не симметричность трактуется следующим образом: изменение бизнес-потребности требует анализа изменений в связанной с ней функции, при этом обратное в общем случае не верно. В зависимости от конкретной модели требований, трассировка может иметь и отличные от описанных свойства.
Назначение
Трассировка требований является ключевым компонентом процесса управления изменяющимися требованиями к системе, позволяющим с использованием данных о связях определить масштаб влияния изменения в одном из источников требований (например, изменении законодательства, пожеланий заказчика) на артефакты требований (варианты использования, спецификации и т.д.), артефакты разрабатываемой ОС вообще и, следовательно, характеристики проекта в целом. Таким образом, трассировка является инструментом управления рисками проекта, снижающим вероятность превышения сроков и бюджета проекта за счет недооцененного влияния изменений требований.
В этом смысле трассируемость является важным свойством, поддерживающим определение системы как компромисса между конкурирующими интересами заинтересованных лиц, так как именно конкуренция интересов является одним из основных источников изменений требований.
Кроме того, трассировка может использоваться для определения приоритетов нижестоящих требований (вариантов использования, функциональных требований) по приоритету вышестоящих требований, описывающих бизнес-потребности заказчика, тем самым позволяя планировать проект, обеспечивая приоритетную реализацию функциональности системы, наиболее важной с точки зрения бизнеса, а не «удобной» команде разработчиков для реализации.
Инструменты трассируемости требований используются и для выявления артефактов системы, не связанных с другими артефактами, что позволяет выявить недостающие «звенья» разработки. Например, возможно выявление вариантов использования, с которыми не ассоциировано сценариев тестирования.
Разновидности
В зависимости от конкретной реализации в методологии или программном пакете управления с требованиями, трассировка может реализовываться в виде нетипизированной связи между артефактами. В таком случае причинно-следственные связи отслеживаются исходя из типа артефактов, между которыми устанавливается трассировка.
В более сложном случае, связь может принадлежать к одному из предопределенных фасетов (например «тестируется с помощью», «вытекает из», «является частью»). Таким образом увеличивается гибкость возможных выборок по связям между артефактами, однако, это происходит за счёт существенного усложнения модели. Очевидно, что использование второго подхода может быть оправдано только для крупных проектов со сложной структурой требований.
Трассируемость может осуществляться как исключительно между различными артефактами требований, так и между артефактами проекта вообще. В этом случае трассировки объединяют артефакты требований, проектирования, реализации, тестирования, позволяя оценивать влияние изменений требований не только на другие артефакты требований, но и на архитектурные решения, сценарии тестирования, исходный код системы. Таким образом повышается точность оценки влияния изменений требований на проект в целом, что позволяет повысить его управляемость, снизить риски некорректной оценки изменений.
Вместе с тем, реализация такой модели требует высокого уровня интеграции всех компонентов среды разработки, высокой методологической дисциплины в команде разработчиков и, в итоге, ограничивает выбор средств разработки, а также вариативность расходов, увеличивая одновременно затраты на обеспечение процесса. Поэтому очевидно, что степень такого рода интеграции должна тщательно оцениваться для каждого конкретного проекта с учётом его индивидуальных особенностей.
Инструментальная поддержка
Трассируемость требований в проекте может поддерживаться и без использования специализированных инструментальных средств, с помощью соглашений об именовании и соблюдения аналитиками формализованных процедур управления требованиями. При этом может использоваться функционал ПО общего назначения, например, механизмы управления структурой документа и составными документами, а также перекрестных ссылок и гиперссылок текстовых редакторов, функционал сортировки и фильтрации данных в электронных таблицах, механизмы настольных СУБД.
Такой подход, однако, предполагает дополнительные трудозатраты на поддержание трассируемости и ограничивает её применимость в проекте, а также резко теряет эффективность по мере увеличения масштаба проекта.
Ещё один подход к обеспечению трассируемости в рамках управления требованиями может заключаться в использовании различных баг-трекинговых и аналогичных систем. Такой подход предполагает подстройку подобных систем для целей управления требованиями, при этом встроенные механизмы выборок и генерации отчетов, поддержки рабочих потоков артефактов этих систем, а также механизмы обеспечения зависимостей могут обуславливать применимость этих средств для обеспечения трассируемости и управления требованиями вообще. Вместе с тем, функционал таких систем может накладывать свои, подчас существенные, ограничения на модель требований, а отсутствие интеграции со средствами визуального моделирования и редактирования текстовых артефактов требований также не служит экономии трудозатрат на поддержание модели.
Специализированные семейства программных продуктов управления жизненным циклом ПО обычно включают средства управления требованиями с поддержкой трассируемости. Отличительной чертой таких средств является включение или интеграция средств импорта требований из различных источников, поддержка визуального моделирования (в основном, на основе UML), тесная интеграция со средствами документирования. При этом автоматизирована работа с трассировками — анализ изменений и генерация отчетности о них (в том числе матриц трассировок), настраиваемые механизмы уведомлений заинтересованных лиц об изменениях, с учётом зон ответственности и зависимостей. В целом, такие средства позволяют снизить трудозатраты на поддержку механизма трассировок, при этом обеспечивая более гибкое их использование. Успех их применения, однако, как и многих других средств автоматизации, зависит от особенностей конкретного проекта, качеств команды разработчиков, степени зрелости процесса разработки ПО в компании в целом.
К специализированным средствам управления требованиями, поддерживающим трассируемость, относятся, в частности, средства Borland Caliber, IBM Rational RequisitePro, (IBM) Telelogic DOORS, Sparx Enterprise Architect, 3SL Cradle,
В рамках проекта Eclipse инициировано создание Open Source Requirements Framework, предназначенного для создания модели управления требованиями, а также инструментов на её базе.
Источники
- Open Source Requirements Framework project. ORMF Requirements model 2.0
- Wikipedia Contributors. Requirements Traceability
Источник: www.tadviser.ru
Протоколирование: рекомендации по трассировке
2012-08-30 в 20:24, admin , рубрики: Блог компании Инфопульс Украина, Программирование, Проектирование и рефакторинг
В данной статье я хочу поделиться своими мыслями/наблюдениями/рекомендациями относительно реализации такой важной задачи при разработке ПО как протоколирование. В Интернете существует множество статей описывающих инструменты для протоколирования, но очень мало информации о том, какие именно события, и какую информацию, нужно записывать в протокол работы программы.
Введение
Очень часто возникает проблема диагностики дефектов в тестовой или рабочей среде, где нет инструментов разработки и отладки. И единственным способом понять, в чем ошибка – добавление строк кода с отладочной информацией и повторная установка приложения, если такие строки не были добавлены ранее. А можно ли сразу писать код так, чтобы информации, которую протоколирует приложение, было бы достаточно для диагностики проблемы?
В статье я совсем не буду касаться таких вопросов как инструменты для протоколирования. Но в любом случае, нужно понимать, что такие инструменты существуют и позволяют фильтровать записываемые в протокол данные и настраивать запись протокола в различные источники.
Основная задача статьи – дать представление разработчикам, какими способами проводится протоколирование, и дать рекомендации о том, где в программе вставлять строчки кода для протоколирования. В этой статье, в основном, будем говорить о трассировке.
Протоколирование
Я рассматриваю протоколирование намного шире, чем просто запись в лог-файл. Для меня протоколирование — это набор средств и методов, которые решают такие задачи:
- Быть уверенным, что система работает и работает правильно
- Понимать, почему система и ее данные находятся в текущем состоянии
- Иметь возможность быстро найти неисправность
- Узнать, как систему можно усовершенствовать
Подходы к протоколированию
Вышеуказанные цели можно конкретизировать, выделив «пользователей» результатов протоколирования, и задачи этих «пользователей». Далее можно выделить средства и методы, с помощью которых эти задачи можно реализовать. Итак, я вижу 4 основных категории «пользователей»:
- Разработчик — специалист, который разрабатывает и улучшает приложение
- Тест инженер — специалист, который отвечает за качество приложения, обнаружение и локализацию дефектов в период разработки
- Системный администратор — специалист службы сопровождения, который отвечает за бесперебойную работу приложения в рабочей среде и своевременное обнаружение ошибок.
- Владелец приложения — бизнес-пользователь, который знает и понимает функционал приложения в целом и, по сути, является владельцем данных приложения; сотрудник для которого разрабатывалось это приложение
В таблице ниже для типов пользователей приведены наиболее часто используемые ими в работе методы и средства для решения своих задач.
- Найти место возникновения проблем и исправить их
- Выполнить оптимизацию
- Трассировка
- Счетчики производительности
- Состояние объектов/процессов
- Быть уверенным, что система работает корректно
- Обнаружение дефектов
- Максимально точно определить место и причину возникновения найденных дефектов
- Журнал событий
- Журнал аудита
- Состояние объектов/процессов
- Быть уверенным, что система работает
- Если есть ошибки понять почему (по чьей вине, где исправлять)
- Если работает медленно – понять почему
- Журнал событий
- Счетчики производительности
- Состояние объектов/процессов
- Быть уверенным, что система работает именно так, как нужно
- Журнал аудита
- Состояние объектов/процессов
Указанные в таблице средства и методы кратко описаны ниже.
- Трассировка — инструмент, который обычно называют «логом», по сути, хранилище, куда пишется подробная информация о ходе выполнения программы (последовательно, в порядке возникновения событий). Это обычно текстовый файл или таблица базы данных. Данный инструмент нужен разработчику, тест-инженеру или специалист службы сопровождения для детального анализа того, что происходит в приложении.
- Журнал событий — инструмент, который показывает события в приложении с точки зрения администратора. Т.е. события, по которым системный администратор может сказать в рабочем ли состоянии приложение или нет. Если говорить о разработке ПО для Windows —то это чаще всего Windows Event Log или собственные журналы приложений. Я сторонник того, чтобы не смешивать хранилища для трассировки и журнал событий.
- Журнал аудита — инструмент, который позволяет пользователю приложения понять, кто и какие действия выполнял (или пытался выполнять) в системе
- Счетчики производительности— инструмент системного администратора, который помогает обнаружить узкое место в производительности системы. Примером такого инструмента может быть Performance Monitor, встроенный в операционную систему Windows. Для других ОС существуют аналогичные инструменты
- Состояние объектов/процессов — инструмент, который помогает понять, в каком состоянии (или в какой стадии) находятся в текущий момент объекты или процессы в приложении, и как они в это состояние или стадию обработки они попали.
Например: представим себе приложение, которое обрабатывает входящие почтовые электронные сообщения. Для каждого такого сообщения можно выделить состояния: получено, обработано, удалено. В «журнал состояний объектов/процессов» в таком случае следует записать ключевую информацию по письму, историю смены состояний письма и сообщения при его обработке. Таким образом, полностью отделяется важная информация по процессу обработки письма от «мусора»
Выбор и реализация методов протоколирования — очень важная задача, от реализации которой зависит скорость и качество обнаружения и исправления дефектов и качества сопровождения. Поэтому на стадии планирования и разработки этой задаче нужно уделить досрочно внимания и подобрать достаточный набор методов протоколирования.
Трассировка
* картинка взята из статьи Lazy logger levels
- обо всех ошибках – обработанных и не обработанных
- параметры запуска и загруженную конфигурацию
- а также события, описанные ниже.
Трассировочная информация предназначена главным образом для разработчика и тест инженера (или в рабочей среде — для сотрудников службы сопровождения очень высокого уровня квалификации).
Особенность трассировки заключается в том, что обычно этот функционал не описывается в требованиях, и поэтому разработчикам в начале проекта обычно сложно представить какая трассирующая информация может понадобиться, и, поэтому, сложно понять, что и когда нужно записывать.
Самое главное — понять, что трассировка в рабочей среде включается только при необходимости, т.е. не засоряет журнал событий. Для среды разработчика и среды тестирования трассировка чаще всего включена постоянно для наблюдения за правильностью работы приложения и отладки.
Инструменты для протоколирования обычно дают возможность вести запись в журнал, указывать, куда именно эта информация будет записываться. Важным элементом является также возможность в конфигурации указывать, какие записи попадут в журнал, а какие — нет (обычно это делается на основе категорий событий и уровней событий).
Однако большой проблемой является то, что, несмотря на наличие инструментов редко можно встретить рекомендации как их правильно использовать, а именно:
- Какие события нужно писать в трассировочный лог
- Как правильно выбрать уровень для события
- Как правильно выбрать категории событий
- Какую информацию нужно записывать при возникновении того или иного события
Это и будет рассмотрено далее в статье.
Какие события нужно вносить в трассировочный лог
Важным фактором при выборе событий, которые нужно писать в трассировочный лог зависит, на мой взгляд, от двух факторов:
- Используется ли модульные тесты при разработке.
Использование модульных тестов позволяет значительно снизить количество ошибок в бизнес логике методов, не взаимодействующих с внешними системами (внешними по отношению к данному слою приложения). Однако при взаимодействии кода с внешней системой (взаимодействие кода бизнес слоя с базой данных, взаимодействие слоев бизнес логики, расположенных на разных компьютерах и прочее) модульные тесты не эффективны потому, что конфигурация разных слоев может быть разной в разных средах. Исходя из этого, можно сделать вывод, что при использовании модульных тестов логично выполнять только трассировку взаимодействий между слоями и трассировку ошибок (т.к. считаем, что логика каждого слоя в отдельности очень хорошо протестирована). Если же модульных тестов нет — трассировать нужно каждую ветку логики программы (вход в метод, выход, возникновение в методе ошибки, каждую ветку условного оператора) - Тип приложения.
В таблице представлены некоторые типы приложений и события для протоколирования в трассировочный лог (понятно, что есть и другие типы приложений).
| Тип приложения | Особенности протоколирования |
| Изолированное desktop приложение (даже не сохраняет ничего на диск) | Если такое приложение хорошо протестировано модульными тестами, то трассировку делать не имеет смысла |
| Приложение для внесения данных и получения отчетов | Тут уже имеется взаимодействие между приложением и хранилищем, и поэтому рационально протоколировать информацию о таком взаимодействии: запросы, количество внесенных и полученных записей, скорость обработки запросов, ключевые параметры для формирования отчетов |
| Инсталлятор приложения (исправления, обновления ) | В данном случае программа тесно взаимодействует с внешней системой и поэтому каждый шаг (попытка выполнить и результат выполнения) должны вносится в трассировочный лог |
| Интеграционная шина | Краткая или полная (полностью данные) информация о поступающих или отправляемых данных |
| Приложение, которое может быть сильно изменено пользователем (или расширено дополнительными модулями и плагинами) | Все взаимодействия с такими внешними модулями (входные/выходные параметры) и влияние установленных параметров конфигурации на работу программы |
Какие данные нужно вносить в трассировочный лог
Кроме простого названия (описания) события, для анализа работы часто нужна еще дополнительная информация. Следующая таблица показывает данные, которые полезно было бы записывать. Понятно, что далеко не всегда нужно писать события настолько подробно. Кроме того, обычно инструменты трассировки позволяют некоторую из указанной ниже информации записывать автоматически.
| Данные | Описание |
| Дата и время | Дата и время возникновения события |
| Сервер | Сервер, на котором событие возникло (полезно при анализе журналов, собранных с различных серверов) |
| Процесс | Название процесса, где возникло событие. Это необходимо, например, в случае если разные процессы используют общие библиотеки. |
| Метод | Название метода, возможно, включающий название класса и библиотеки |
| Категория события | Название слоя или логического модуля |
| Уровень | Уровень детализации события |
| Название | Название события (запуск или завершение метода, ошибка, изменение состояние объекта и прочее) |
| Детальная информация | Например, детальная информация об ошибке (а при критической ошибке может быть и детальная информация о системе), значение параметра(-ов), название объекта или описание действия над объектом |
| Учетная запись, под которой работает процесс | |
| Учетная запись пользователя, который вызвал действие | Учетная запись пользователя, который сделал начальный вызов, что привело к данному событию |
| Стек | Стек вызовов методов, которая привела к данному событию. Может быть полезен при детальном анализе события |
| Корреляционный номер процесса | Если приложение многопользовательское, то важно понимать к какому запросу (пользователю) относится та или иная запись о события |
| Корреляционный номер инициирующего процесса | Если приложение распределенное, то данный номер используется для сопоставления событий на разных серверах (или процессах). Например, можно передавать с клиента на сервер корреляционный номер и сохранять его при трассировке. В дальнейшем можно сопоставлять вызов клиентского приложения с событием на сервере |
Уровни трассировки
Уровни в основном используются для фильтрации событий при записи в журнал. Это нужно для предотвращения записи в журнал данных, которые в данный период времени не нужны.
Например, такой инструмент как NLog, предоставляет по умолчанию 6 уровней событий (от более детального до менее детального): trace, debug, info, warn, error, fatal (более детально см. в документации к NLog)
Далее, в конфигурации можно указать, что, например, в рабочей среде, в журнал трассировки писать события уровня Error и Fatal (а все остальные игнорировать), а при возникновении проблемы изменить конфигурацию так, чтобы записывать все события.
Следующая таблица показывает мои рекомендации по выбору уровней событий при трассировке
| Событие | Уровень |
| Загруженная конфигурация / смена конфигурации | Info |
| Действия пользователя | Info |
| Начало и окончание каждого «публичного» метода (или метода, который реализует логику согласно спецификации), входные/выходные параметры, результат работы такого метода | Info |
| В публичных методах входные/выходные параметры, которые являются наборами данных | Debug |
| Логика (ветки программы) описанная спецификацией | Info |
| Начало и окончание остальных методов, входные/выходные параметры, результат работы | Trace |
| Шаги остальных методов | Trace |
| Доступ к внешним ресурсам (например: БД, web-сервисы) | Info |
| Детальная информация о запросах (командах) доступа к внешним ресурсам и полученном результате | Debug |
| Неожиданные исключения (не критические) | Error |
| Исключение, описанное в спецификации | Warn/Error |
| Обработанные исключения | Warn/Info/ Debug |
| Критическое исключение (обработанное или не обработанное) | Fatal |
Выбор категорий событий
Второй важный параметр, по которому можно настроить фильтрацию записи событий в журнал — это категории событий. Эти категории разработчик должен выбирать сам (т.е. инструменты не предоставляют категории по умолчанию)
Я рекомендую придерживаться таких рекомендаций — для каждого отдельного логического уровня сделать отдельную категорию. Например: уровень интерфейса (UIControls), уровень бизнес-логики (BusinessLogic), уровень доступа к данным (DAL), модуль поиска (Search), программа настройки конфигурации (ConfigManager) и так далее.
Далее, если у вас есть отдельные компоненты внутри слоя, то можно для их трассировки выбрать отдельные подкатегории, отделяя от основной категории точкой.
Например, визуальный компонент для отображения облака тегов (который располагается в уровне интерфейса)— UIControls.TagsControl.
Таким образом, при возникновении проблемы с компонентом, с одной стороны вы всегда сможете по журналу определить, какой компонент создал то или иное событие, с другой — более гибко настроить фильтрацию записи в журнал событий только по выбранному компоненту.
Заключение
Протоколирование — важная функция в любом приложении и требует внимательного анализа и проектирования. Несмотря на то, что трассировка обычно не описывается в требованиях, правильное ее использование может в значительной степени ускорить процесс обнаружения и исправление дефектов на тестовой и рабочей среде.
Данные выкладки — это мои практика и наблюдения, и, соответственно, у вас могут быть свой опыт и своя методика по использованию протоколирования (и трассировки в частности). С удовольствием выслушаю критические отзывы и замечания для улучшения рекомендаций.
Что еще почитать по трассировке
- Способы отладки приложений: Протоколирование http://dtf.ru/articles/read.php?id=36547
- Каким должен быть правильный лог-файл — http://www.codeart.ru/2011/02/23/kakim-dolzhen-byt-pravilnyj-log-fajl/
- What Goes Into A Trace Log? — http://www.informit.com/guides/content.aspx?g=dotnethttps://www.pvsm.ru/programmirovanie/14132″ target=»_blank»]www.pvsm.ru[/mask_link]