Трассировка веб браузера что это
Microsoft Windows 2000 версия этой статьи 162326см.
Аннотация
В данной статье описывается TRACERT (Trace Route), служебная программа командной строки, который можно использовать для трассировки путь, который принимает пакет Internet Protocol (IP) до места назначения. В данной статье рассматриваются следующие вопросы:
Использование служебной программы TRACERT
Использование команды TRACERT для устранения неполадок
Сведения о параметрах команды TRACERT
Дополнительная информация
Использование служебной программы TRACERT
C:\>tracert 11.1.0.1В результате выполнения команды: Tracing route to 11.1.0.1 over a maximum of 30 hops --------------------------------------------------- 1 2 ms 3 ms 2 ms 157.54.48.1 2 75 ms 83 ms 88 ms 11.1.0.67 3 73 ms 79 ms 93 ms 11.1.0.1 Trace complete.
Использование команды TRACERT для устранения неполадок
TRACERT можно использовать, чтобы узнать в каком месте сети останавливаются пакеты. В следующем примере основной шлюз обнаружил, что существует не правильный путь для размещения на 22.110.0.1. Вероятно, либо маршрутизатор имеет проблемы конфигурации или 22.110.0.0 сети не существует, отражая неправильный IP-адрес. Команда:
C:\ > tracert 22.110.0.1В результате выполнения команды: Tracing route to 22.110.0.1 over a maximum of 30 hops ----------------------------------------------------- 1 157.54.48.1 reports: Destination net unreachable. Trace complete. TRACERT полезна для устранения неполадок в больших сетях, где несколько путей может привести к той же точке или где задействовано множество промежуточных компонентов (мосты или маршрутизаторы).
Сведения о параметрах команды TRACERT
Существует несколько параметров командной строки, которые можно использовать с помощью команды TRACERT, несмотря на то, что параметры не являются обычно требуются для стандартных неполадок. В следующем примере синтаксис команды показывает все возможные варианты:
Tracert -d -h максЧисло -j списокУзлов - w Таймаут target_hostЧто делают параметры: -d Specifies to not resolve addresses to host names -h maximum_hops Specifies the maximum number of hops to search for the target -j host-list Specifies loose source route along the host-list -w timeout Waits the number of milliseconds specified by timeout for each reply target_host Specifies the name or IP address of the target host
Когда-нибудь трассировали рантайм вашего приложения? Знаете сколько запросов делает вон тот серый ендпоинт, который? А как долго вычитываются те кросс-референсы на схожий тип ресурсов с каждой странички сущностей, которую нужно вернуть в запрос? Пытались ли вы замерить как долго приходится ждать пользователю из-за опциональных полей запроса, которые он время от времени добавляет? Задумывались ли вы что будет если запараллелизировать эти шесть запросов к тем двум базам данных?
Если что-нибудь выше звучит интересно, или как минимум знакомо — добро пожаловать под кат.
chrome://tracing
Если ввести chrome://tracing в адресную строку Chrome, то вы попадёте на вот такую страничку:
Сам инструмент очень близко дружит с трассировочными данными самого V8 (и хрома). А с недавних пор node тоже позволяет нативно трассировать рантайм с поддержкой chrome://tracing в качестве фронтенда. Для трассировки достаточно просто нажать заветную “Record” и сделать несколько пассов над соседней вкладкой, после чего можно пронаблюдать в деталях чем именно занимался браузер, когда вы старательно болтали курсор внутри окна, хаотично крутя мышкиным колесом. Для нашего удобства, добрые люди даже написали очень подробную статью о том как интерпретировать результаты.
Формат данных, потребляемых этим визуализатором хорошо задокументирован, и отлично подходит даже для трассировки вещей отдаленных от рендеринга, вычисления разметки и отлова мусорной отрисовки. Благодаря открытости и способности загружать внешние файлы, этот трассировщик достаточно легко интегрируется с любой средой, способной на любой I/O. Кроме того, помимо самой визуализации есть и некоторые встроенные возможности для анализа групп событий. В общем, полезный и гибкий инструмент, который может пригодится и здорово помочь там, где в традиционном случае нужно было бы парсить тонны логов в поисках определенности.
Весь фронтенд трассировщика, кстати, написан на ванильном JS и лежит на GitHub. Сама chrome://tracing — обычная веб-страничка и её можно инспектировать через DevTools как и любую другую. То есть, если инструмент не сможет удовлетворить вас… полностью, то его можно спокойно помять под необходимый сценарий.
В опыте автора, необходимость в таком инструменте появилась во время работы над бессерверной системой для интерента вещей. В определенных сценариях, количество запусков лямбда функций достигало десятков и сотен для выполнения одной единственной операции. Анализировать все внутренности этих запусков по одним только логам было отнюдь не весело. Хотелось чего-то, что помогло бы окинуть картину одним взглядом целиком. Помог самописный трассировщик, который умел инструментировать внутренности наших функций и все запросы, которые они делали. О горе, автор тогда и не подозревал о существовании chrome://tracing, поэтому для трассировщика был написан с нуля фронтенд на d3, которому можно посвятить отдельный пост (tldr; не рендерьте ничего сложного через DOM, только canvas и WebGL). Давайте теперь посмотрим на несколько примеров, где трассировка помогла с оптимизацией:
Дано: асинхронный мемоизирующий сервис и несколько суб-сервисов, которые его вызывают.
Проблема: при нескольких вызовах кеширующего сервиса подряд, результат не успевает попадать в кеш, соответственно вместо одного запроса, сервис делает n.
Решение: прогревание кеша (префетч, работает если серия вызовов нуждается в одной и той же зависимости), либо ленивая блокирующая мемоизация (название импровизированное)
Дано: один из SDK при каждой инициализации делал дополнительные блокирующие запросы (и пусть весь мир подождёт) о которых мы не подозревали, они никак не логировались и не были задокументированы.
Решение: инструментирование SDK для отключения этого “вредного” запроса.
Дано: трассировка показала, что пользовательские скрипты на несколько строк выполняются на два порядка дольше ожидаемого. Дебаг показал что проблема в чрезмерном использовании переменных из глобального скоупа.
Решение: симуляция глобального скоупа для пользовательского кода через аргументы функции
Код выше симулирует глобальные переменные для скрипта через аргументы виртуальной функции (привет, CommonJS).
Дано: Некоторые сущности достаточно велики (2.5-3Мб)
Проблема: подозрение на то, что такие сущности долго и дорого загружать по сети.
Решение: трассировка показала, что загрузка таких сущностей — одна из самых дешевых операций и есть куда более глубинные проблемы требующие решения. Данные помогли сконцентрировать рефакторинг на частях системы, которые дали многократный прирост в производительности после улучшения.
Помимо этих примеров, была масса случаев, когда трассировщик помогал быстро и точно оценить последствия изменений, давал возможность смотреть на всю картину целиком, избегая “построчного” поглощения информации, в целом проявив себя как инструмент упрощающий жизнь.
Устройство простейшего трассировщика
Переходя к практической реализации простейшего трассировщика, их можно условно разделить на две большие группы, по способу инструментации кода:
- Централизованный — все точки захвата устанавливаются из единственной точки в коде. Трассировщик вызывает необходимые модули приложения и перегружает точки входа в них.
- Распределенный — все точки захвата определяются по месту необходимости, напрямую вызывая код трассировщика. Непосредственно определяют начало события и его конец.
Распределенный подход хорош тем, что можно очень ситуативно определять длительность и содержание событий, включая в них целые блоки полезного кода. Также, он проще для начальной реализации, потому что трассировщик избавлен от необходимости абстрактно отлавливать потенциальные ошибки и обеспечивать неизменный поток исполнения.
Самый банальный пример трассировщика второго типа может выглядеть так:
Все достаточно банально и трассировщик не должен беспокоиться ни о каких сторонних эффектах инструментируемого кода. Также, никогда не используйте ничего наподобие `Math.random().toString(16).substr(2);`, этот пример сугубо для иллюстрации, есть куда более правильные способы.
Как только мы захотим перейти к централизованному подходу, нам нужен будет абстрактный интерфейс для установки точек захвата:
Такой метод можно будет вызывать в том единственном месте, которое будет сердцем конфигурации. Обычный monkey-patching, даже нечего добавить. Легко заметить что метод имеет несколько недостатков:
- Расположение модуля относительно трассировщика
- Никаких проверок ввода
- Никакая поддержка асинхронных функций
Помимо более явного поведения для пользователя, это позволяет упростить валидацию на существование:
Поведение при невалидной конфигурации может быть жёстким (выбросить ошибку) или мягким (игнорировать модуль, продолжить работу). Теоретически хороший трассировщик должен позволять следовать любому из путей при помощи конфигурации, так как оба варианта могут быть оправданы в разных случаях.
Обработка асинхронных функций — уже чуть более интересная задача. Во первых, нужно определить является ли инструментируемый метод асинхронным, и изменить поведение трассировщика для определения конца события. Для этого можно модифицировать наш перегруженный метод следующим образом:
Из интересного, трассировщик должен гарантировать отсутствие сторонних эффектов во время выполнения. Поэтому он должен пробрасывать любые словленные ошибки назад в поток приложения.
Вот и все, такой примитивный трассировщик уже можно использовать для чего-то полезного. Из дополнительных возможностей, которыми можно озадачится:
- Поддержка before и after точек захвата для инструментируемого кода, с передачей аргументов и возвращаемого результата для любых других дополнительных действий
- Поддержка событий различных типов по именам, это просто удобно
- Поддержка сохранения метаданных об успешности каждого события
- Поддержка сохранения результатов выполнения инструментированного метода
- Библиотека стандартных точек захвата для публичных интерфейсов node.js и популярных библиотек
- Поддержка экспорта в других форматах, например: Open Tracing
- Возможность удалённого запуска трассировочных сессий с отправкой результата на клиент
- Защита от непреднамеренно долгих сессий (на нашей памяти были случаи, когда включенный трассировщик генерировал несколько гигабайт данных и ронял родительское приложение).
Суть в том, что каждое событие трассировщика раскрывается в два объекта представляющих начало и конец асинхронного события chrome://tracing. Помимо асинхронных событий, можно создавать и “законченные” (Completed) события. Но они перекрывают друг друга при рендере в chrome://tracing из-за чего их не так просто анализировать :3
После того как все события сконвертированы, останется просто аккуратно сложить их массивом в поле объекта `traceEvents` и сохранить его куда-нибудь, откуда его не будет мучительно долго искать через файловый проводник.
Заключительным шагом будет добавить инструментацию в части вашего приложения где происходит что-то неявное, запустить его и загрузить полученный файл в chrome://tracing.
Далеко не секрет, что любой сайт размещается на определенном сервере и вводя в адресной строке установленного браузера адрес необходимого сайта, а затем нажимая кнопку «перейти», пользователь отправляет запрос на сервер. По пути до сайта, запрос проходит через промежуточные узлы связи. Если они функционируют нормально, то происходит загрузка ресурса в браузере.
Когда загрузка сайта не происходит, значит, отправленный запрос не смог дойти по причине проблем на одном из узлов связи. Понять, какой участок канала связи вызывает потерю запроса, поможет осуществление трассировки маршрута.
Как сделать трассировку сайта
Дальше я расскажу, как сделать трассировку маршрута в ОС Windows. Для этого нам понадобится воспользоваться служебной программой Tracert, которая, аналогично программе ping, запускается командной строкой. Чтоб в нее попасть, можно использовать один из трех предлагаемых мной способов:
1. Жмем кнопку «Пуск» и выбираем далее «Выполнить», а в поле с текстом «Открыть» набираем на клавиатуре cmd, после чего — «ОК» либо используем клавишу Enter.
2. Воспользоваться комбинацией клавиш вида Win+R, которая открывает окно как в первом способе. Дальше все действия одинаковы.
3. Жмем «Пуск», далее «Все программы» (либо просто «Программы» в более старых версий ОС), переходим к пункту «Стандартные» и выбираем «Командная строка».
Время отклика характеризует загруженность выделенного канала. При большом времени отклика, загрузка сайта будет идти, но весьма трудно. Но если появляется надпись с предупреждением о превышении интервала ожидания запроса, то на конкретном узле наблюдается потеря данных. Следовательно, этот узел – проблемный.
Таким образом, трассировка маршрута позволяет определить проблемы на узлах. Если поступление данных происходит нормально, а теряются они уже в узле назначения, то проблема именно с сайтом. При обрыве трассировки на середине маршрута – проблема с промежуточным маршрутизатором. Если пакеты теряются в сети провайдера, которым вы пользуетесь, то такая проблема решается уже непосредственно с ним.
В данной статье рассмотрим что такое трассировка, как её сделать на разных устройствах и что делать с результатом.
Что такое трассировка и MVNO
Рассмотрим случай, когда сайт может быть недоступен с одного интернет провайдера, а с других провайдеров данной проблемы не наблюдается.
Как правило, при обращении к сайту, вы можете наблюдать подобную ошибку (рис.1).
Рисунок 1.
Перед началом следует сделать отступление и рассказать про MVNO.
MVNO или по другому виртуальные операторы - это компании, арендующие оборудование другого провайдера. Они предоставляют услуги мобильной связи и интернета под своими флагами, используя вышки других компаний.
По состоянию на 2022 год в России действует несколько виртуальных операторов, которые сами себя позиционируют как полноценных операторов. Эти фирмы объединяет то, что раньше у них была собственная инфраструктура, но позже они перешли на использование оборудования других компаний:
На сети Мегафон: YOTA, NetByNet;
На сети Tele2: Тинькофф мобайл, Сбермобайл, Ростелеком, TTK Mobile, Danycom;
На сети МТС: МГТС.
Если сайт недоступен с одного из данных провайдеров, первое, что необходимо сделать, проверить работает ли сайт с другого главного провайдера (помните про MVNO). Далее необходимо реализовать трассировку с интернета, где наблюдается недоступность сайта. Как это сделать, мы расскажем ниже.
Трассировка - это команда, которая показывает, через какие узлы информация проходит в интернете, когда вы открываете сайт в браузере. С помощью трассировки иногда можно определить, почему медленно открывается сайт, или открывается "через раз" или совсем не доступен.
Внимание!
Команду трассировки необходимо выполнять с того устройства, где наблюдается недоступность сайта.
Трассировка на Windows
Чтобы выполнить трассировку на устройстве с Windows, нажимаем на сочетание клавиш Windows + R, затем вводим команду cmd и нажимаем на Enter или OK (рис.2).
Рисунок 2.
Либо в поиске вводим "Командная строка" и выбираем приложение с таким же названием (рис. 2a)
Рисунок 2a.
Появится окно командной строки, в нём нам нужно ввести команду:
Для трассировки IP адреса (если это необходимо, например 127.0.0.1) укажите команду: tracert 127.0.0.1
Получится вот так (рис.3)
Рисунок 3.
Нажимаем Enter и ждем завершения выполнения команды, примерно ~20 секунд.
Пример результата выполнения команды трассировки (рис.4):
Рисунок 4.
В зелёной рамке на рис. 4 показан результат выполнения команды. Далее смотрите секцию ниже, в которой рассказывается, что делать с полученным результатом.
Трассировка на MacOS
Для того чтобы выполнить трассировку на MacOS, необходимо запустить приложение "Терминал".
Для этого нажмите значок Launchpad в панели Dock (рис. 5).
Рисунок 5.
Введите «Терминал» в поле поиска (рис. 6)
Рисунок 6.
Затем нажмите на значок Терминала.
Рисунок 7.
Появится окно командной строки, в нём нам нужно ввести команду:
Для трассировки IP адреса (если это необходимо, например 127.0.0.1) укажите команду: traceroute 127.0.0.1
Далее нажимаем Enter и наблюдаем за выполнением команды (~ 1 минуту), получаем результат (рис.8)
Рисунок 8.
На рис. 8 показан результат выполнения команды.
Далее смотрите секцию ниже, в которой рассказывается, что делать с полученным результатом.
Трассировка на устройстве с iOS (iPhone/iPad).
Мы рассмотрели применение трассировки на компьютере. Что же касается мобильного трафика. Самый простой способ это раздать интернет через телефон на ноутбук и выполнить трассировку, или же воспользоваться бесплатными приложениями.
Рассмотрим пример трассировки на устройстве iOS установив бесплатное приложение "IP Tools: Network Insights".
Выглядит оно вот так (рис. 9)
Рисунок 9.
Открыв приложение, выбираем пункт "Traceroure", затем на следующем экране вводим нужный нам домен и нажимаем Start (рис. 10)
Рисунок 10.
Результат выполнения команды будет отображён ниже.
Готово, далее можно сделать скриншот и поделится результатом.
Трассировка на устройстве с Android
Также как на устройство iOS, чтобы выполнить трассировку на Android, необходимо установить приложение. Для примера мы взяли два бесплатных и популярных приложения:
Рассмотрим процесс трассировки на примере приложения "Ping & Net".
После установки, вводим в поле нужный нам домен и выбираем опцию "Traceroute" (рис.11).
Рисунок 11.
В открывшемся окне оставляем опции как есть, и нажимаем ОК.
Рисунок 12.
В новом окне появится результат выполнения команды.
Готово, далее можно сделать скриншот и поделится результатом.
Что делать с результатом?
Также необходимо обратиться в поддержку интернет провайдера с уточнением причины недоступности сайта с их стороны, возможно ip находится в черном списке и необходимо его удалить из списка для корректной работы сайта, либо какой-то локальный сбой на стороне регионального интернет провайдера. Результат трассировки будет хорошим подспорьем для технических специалистов поддержи интернет провайдера.
Дополнительно возможной причиной недоступности сайта может быть обновление NS записей, т.е. когда Вы привязали домен к магазину, указали на стороне регистратора домена NS записи, необходимо время для их обновления примерно от 2х до 72х часов. Если же после 72х часов сайт все равно будет недоступен, то в этом случае необходимо выполнить действия выше.
Готово. Мы рассмотрели, как произвести трассировку сайта в случае его недоступности.
В данной статье я хочу поделиться своими мыслями/наблюдениями/рекомендациями относительно реализации такой важной задачи при разработке ПО как протоколирование. В Интернете существует множество статей описывающих инструменты для протоколирования, но очень мало информации о том, какие именно события, и какую информацию, нужно записывать в протокол работы программы.
Введение
Очень часто возникает проблема диагностики дефектов в тестовой или рабочей среде, где нет инструментов разработки и отладки. И единственным способом понять, в чем ошибка – добавление строк кода с отладочной информацией и повторная установка приложения, если такие строки не были добавлены ранее. А можно ли сразу писать код так, чтобы информации, которую протоколирует приложение, было бы достаточно для диагностики проблемы?
В статье я совсем не буду касаться таких вопросов как инструменты для протоколирования. Но в любом случае, нужно понимать, что такие инструменты существуют и позволяют фильтровать записываемые в протокол данные и настраивать запись протокола в различные источники.
Основная задача статьи – дать представление разработчикам, какими способами проводится протоколирование, и дать рекомендации о том, где в программе вставлять строчки кода для протоколирования. В этой статье, в основном, будем говорить о трассировке.
Протоколирование
- Быть уверенным, что система работает и работает правильно
- Понимать, почему система и ее данные находятся в текущем состоянии
- Иметь возможность быстро найти неисправность
- Узнать, как систему можно усовершенствовать
Подходы к протоколированию
Трассировка
* картинка взята из статьи Lazy logger levels
- обо всех ошибках – обработанных и не обработанных
- параметры запуска и загруженную конфигурацию
- а также события, описанные ниже.
- Какие события нужно писать в трассировочный лог
- Как правильно выбрать уровень для события
- Как правильно выбрать категории событий
- Какую информацию нужно записывать при возникновении того или иного события
Какие события нужно вносить в трассировочный лог
- Используется ли модульные тесты при разработке.
Использование модульных тестов позволяет значительно снизить количество ошибок в бизнес логике методов, не взаимодействующих с внешними системами (внешними по отношению к данному слою приложения). Однако при взаимодействии кода с внешней системой (взаимодействие кода бизнес слоя с базой данных, взаимодействие слоев бизнес логики, расположенных на разных компьютерах и прочее) модульные тесты не эффективны потому, что конфигурация разных слоев может быть разной в разных средах. Исходя из этого, можно сделать вывод, что при использовании модульных тестов логично выполнять только трассировку взаимодействий между слоями и трассировку ошибок (т.к. считаем, что логика каждого слоя в отдельности очень хорошо протестирована). Если же модульных тестов нет — трассировать нужно каждую ветку логики программы (вход в метод, выход, возникновение в методе ошибки, каждую ветку условного оператора) - Тип приложения.
В таблице представлены некоторые типы приложений и события для протоколирования в трассировочный лог (понятно, что есть и другие типы приложений).
Какие данные нужно вносить в трассировочный лог
Кроме простого названия (описания) события, для анализа работы часто нужна еще дополнительная информация. Следующая таблица показывает данные, которые полезно было бы записывать. Понятно, что далеко не всегда нужно писать события настолько подробно. Кроме того, обычно инструменты трассировки позволяют некоторую из указанной ниже информации записывать автоматически.
Данные | Описание |
Дата и время | Дата и время возникновения события |
Сервер | Сервер, на котором событие возникло (полезно при анализе журналов, собранных с различных серверов) |
Процесс | Название процесса, где возникло событие. Это необходимо, например, в случае если разные процессы используют общие библиотеки. |
Метод | Название метода, возможно, включающий название класса и библиотеки |
Категория события | Название слоя или логического модуля |
Уровень | Уровень детализации события |
Название | Название события (запуск или завершение метода, ошибка, изменение состояние объекта и прочее) |
Детальная информация | Например, детальная информация об ошибке (а при критической ошибке может быть и детальная информация о системе), значение параметра(-ов), название объекта или описание действия над объектом |
Учетная запись, под которой работает процесс | |
Учетная запись пользователя, который вызвал действие | Учетная запись пользователя, который сделал начальный вызов, что привело к данному событию |
Стек | Стек вызовов методов, которая привела к данному событию. Может быть полезен при детальном анализе события |
Корреляционный номер процесса | Если приложение многопользовательское, то важно понимать к какому запросу (пользователю) относится та или иная запись о события |
Корреляционный номер инициирующего процесса | Если приложение распределенное, то данный номер используется для сопоставления событий на разных серверах (или процессах). Например, можно передавать с клиента на сервер корреляционный номер и сохранять его при трассировке. В дальнейшем можно сопоставлять вызов клиентского приложения с событием на сервере |
Уровни трассировки
Уровни в основном используются для фильтрации событий при записи в журнал. Это нужно для предотвращения записи в журнал данных, которые в данный период времени не нужны.
Например, такой инструмент как 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.
Таким образом, при возникновении проблемы с компонентом, с одной стороны вы всегда сможете по журналу определить, какой компонент создал то или иное событие, с другой — более гибко настроить фильтрацию записи в журнал событий только по выбранному компоненту.
Заключение
Протоколирование — важная функция в любом приложении и требует внимательного анализа и проектирования. Несмотря на то, что трассировка обычно не описывается в требованиях, правильное ее использование может в значительной степени ускорить процесс обнаружения и исправление дефектов на тестовой и рабочей среде.
Данные выкладки — это мои практика и наблюдения, и, соответственно, у вас могут быть свой опыт и своя методика по использованию протоколирования (и трассировки в частности). С удовольствием выслушаю критические отзывы и замечания для улучшения рекомендаций.
Читайте также: