Итак, у меня есть служба WCF, которую я размещаю в консольном приложении на моей машине разработки. Я запускаю PerfView на том же компьютере для сбора событий ETW (отслеживание событий для Windows). Служба WCF использует TPL (параллельную библиотеку задач), и я пытаюсь сопоставить события ETW во всех потоках на протяжении всего времени существования запроса WCF. Я говорю строго о сервере, а не о клиенте и сервере. Однако, когда я просматриваю события в PerfView и фильтрую представление только для тех событий из моего пользовательского EventSource
, только события в некоторых потоках имеют ActivityId
. Для любого данного потока либо все события имеют ActivityId
, либо ни одно из событий не имеет. Кроме того, ни одно из событий не имеет RelatedActivityId
.
Эта ссылка относится к блоку приложения семантического ведения журнала (SLAB), но в нем упоминается, что:
При использовании задач TPL каждый поток получает свой собственный идентификатор действия, а код планирования TPL автоматически публикует события передачи, содержащие значения ActivityId и RelatedActivityId. Их можно использовать для корреляции связанных событий.
Мне кажется, это совсем не так. Я не только не вижу каких-либо событий передачи для сопоставления идентификаторов действий, но во многих случаях, как я упоминал ранее, идентификаторы действий вообще отсутствуют.
Согласно этому ответу SO: https://stackoverflow.com/a/27620321/1937249:
Если вы используете прослушиватели вне процесса, то возникает ошибка, что конфигурация TPL по имени не работает, и вместо нее должен использоваться GID: https://slab.codeplex.com/workitem/62
Поэтому я попытался добавить GUID источника события в «Дополнительные поставщики» PerfView вместо его имени, например:
Однако это не имело значения. Мои события были опубликованы, но многим из них все еще не хватало ActivityId
, а всем событиям не хватало RelatedActivityId
.
И последнее, что может иметь значение: я использую пространство имен Microsoft.Diagnostics.Tracing
в пакете Microsoft.Diagnostics.Tracing.EventSource
NuGet, а не System.Diagnostics.Tracing
, встроенное в фреймворк.
ИЗМЕНИТЬ
Вот изображение, показывающее все типы событий, которые были захвачены из TplEventSource. Я предполагаю, что это означает, что TplEventSource включен. Мне не ясно, должен ли я видеть в списке «событие перевода» или одно из событий должно иметь ключевое слово или другое поле, указывающее, что это был перевод. Если предполагается фактическое «событие передачи», я не вижу ничего подобного в списке.
PerfView Вывод
Вот изображение списка событий из моего пользовательского EventSource
для одного запроса WCF. Вы можете видеть, что запрос начинается с идентификатора потока 10 724. Каждое событие в этом потоке имеет ActivityId
. «Asi-Geoservices/StartAuthenticateRequest/Start» выполняет асинхронный вызов базы данных, и приложение возобновляет работу в потоке 8268. Ни одно из событий в потоке 8268 не имеет ActivityId
. 'Asi-Geoservices/StartServiceProviderRequest/Start' делает асинхронный HTTP-запрос, и приложение возобновляет работу в потоке 11 764, где, опять же, каждое событие в этом потоке имеет ActivityId
. После «Asi-Geoservices/StartServiceProviderRequest/Stop» выполняется еще один асинхронный вызов базы данных, и приложение снова возобновляет работу в потоке 8268, где запрос в конечном итоге завершается, но на этот раз каждое событие в потоке теперь имеет ActivityId
.
ActivityId
должен быть ненулевым, у меня просто не было быRelatedActivityId
для их сопоставления. Это мое понимание этого до сих пор, но я могу ошибаться. - person Jason Boyd   schedule 15.04.2016