ASP.NET и System.Diagnostics отслеживание - я что-то пропустил, или это плохая идея?

Question

По разным причинам я хотел использовать трассировку для своего приложения ASP.NET. Тем более, что я узнал о возможности использовать Service Trace Viewer , который позволяет вам мощно исследовать ваши следы.

Поскольку я никогда раньше не использовал эту трассировку, я начал ее изучать. Через некоторое время из Google, SO и MSDN у меня наконец появилось хорошее представление о том, как все работает. Но я также нашел одну очень неприятную вещь.

При использовании трассировки в приложениях ASP.NET имеет смысл сгруппировать сообщения трассировки по веб-запросам. Тем более, что одна из причин, по которой я хочу это использовать, - это изучение проблем с производительностью. Вышеупомянутый инструмент также поддерживает это с помощью тегов <Corrleation> в сгенерированных файлах XML. Которые в свою очередь происходят от System.Diagnostics.Trace.CorrelationManager. Он также позволяет использовать другие полезные функции, такие как запуск / остановка активности, что обеспечивает еще лучшую группировку сообщений трассировки. Круто, правда?

Я тоже так думал, пока не начал проверять, где на самом деле жил CorrelationManager. Ведь это было статичное свойство. После некоторой игры с Reflector я обнаружил нечто ужасное - оно хранится в CallContext! Какую вещь мы не должны использовать в ASP.NET , верно?

Так ... я что-то здесь упускаю? Является ли трассировка в корне ошибочной в ASP.NET?

Добавлено: Эмм, я вроде как на грани переписывания этого материала сам. Я все еще хочу использовать аккуратный инструмент для исследования следов. По какой причине я не должен этого делать? Может быть, есть что-то лучше? Было бы очень хорошо, если бы я получил ответы в ближайшее время. :)

Добавлено 2: Мой коллега подтвердил, что это не просто теоретическая проблема. Он заметил это в системе, над которой он работает. Так что это решено. Я собираюсь создать новую маленькую систему, которая будет делать все так, как я хочу. :)

Добавлено 3: Ух, круто ... ребята из Microsoft не смогли найти ничего плохого в использовании Correlation Manager в ASP.NET. Так что, видимо, мы все-таки не исправим эту ошибку ...

Answer 1

Вы поднимаете очень интересный вопрос. Посмотрев на Reflector, я также вижу, что CorrelationManager использует CallContext для хранения идентификатора активности. Я не слишком много работал с трассировкой, поэтому я не могу говорить от имени того, какие виды действий он отслеживает, но если он отслеживает одно действие в течение всего жизненного цикла запроса страницы, согласно статье, на которую вы ссылались выше, вероятность того, что идентификатор активности может быть не связан с фактической активностью. Эта деятельность, казалось бы, умерла на полпути.

HttpContext может показаться идеальным для отслеживания всего запроса страницы от начала до конца, поскольку он будет перенесен, даже если выполнение изменится на другой поток. Однако HttpContext не будет перенесен в ваши бизнес-объекты, где, как это делает CallContext. С другой стороны, я увидел, что CallContext также может быть передан при использовании удаленного взаимодействия между клиентскими и серверными приложениями, что довольно изящно, но в случае отслеживания веб-сайта это не очень полезно.

Если вы этого еще не сделали, проверьте сайт этого парня . Проблема, описанная в этой статье, не является той же самой проблемой, о которой упоминала статья Cup (Of T) , но она все еще довольно интересна. Он также предоставляет несколько очень информативных ссылок на странице, которые описывают компоненты CorrelateionManager.

К сожалению, у меня действительно нет ответа на ваш вопрос, но я определенно нахожу эту тему интересной и буду продолжать ее изучать. Поэтому, пожалуйста, обновите этот пост, как вы узнаете больше. Мне любопытно посмотреть, что вы или другие (надеюсь, кто-то там сможет пролить некоторый свет на эту тему) найдут, глядя на это.

В любом случае, удачи. Я поговорю об этом с некоторыми из писателей на моей работе и опубликую позже, если найду что-нибудь.

Chris

Answer 2

ОК, вот так все и закончилось.

Мой коллега позвонил в Microsoft и сообщил им об этой ошибке. Быть сертифицированным партнером означает, что мы получаем доступ к более приоритетной очереди исправлений или что-то в этом роде ... не знаю этого. Во всяком случае, они работают над этим. Надеюсь, мы скоро увидим патч. :)

В то же время я создал свой собственный маленький класс трассировки. Он не поддерживает все навороты, которые делает стандартная инфраструктура трассировки, но это как раз то, что мне нужно. :) Более конкретно:

• Он записывает в тот же формат XML, что и по умолчанию XmlWriterTraceListener, поэтому я могу использовать инструмент для анализа журналов.
• Он имеет встроенную ротацию логов - то, что мой коллега должен был сделать сам поверх XmlWriterTraceListener.
• Фактическое ведение журнала переносится в другой поток, поэтому производительность можно измерить более точно.
• Корреляции теперь хранятся в HttpContext.Items, поэтому особенности потоков ASP.NET на него не влияют.

Счастливый конец, я надеюсь. :)