Коррелировать трассировку MSMQ End-to-End с протоколом WCF Trace и протоколом уровня приложения

Фон:

Я пытаюсь устранить проблему, когда сообщения, отправленные WCF поверх транзакционного MSMQ (с netMsmqBinding), как будто исчезают. Код, который использует WCF, находится в сторонней сборке, которую я не могу изменить. У меня мало подсказок, в чем проблема, но планируем включить различные возможности трассировки, чтобы точно определить, где эта проблема.

Контекст:

Я включил MSMQ Концевая трассировка. Он регистрирует два события для каждого отправленного сообщения.
- Одно событие, когда сообщение отправляется в исходящую очередь. Это сообщение содержит идентификатор сообщения MSMQ (который состоит из guid и целого числа, то есть 7B476ADF-DEFD-49F2-AF5A-0CF27C5152C0\6481271).
- Другое событие, когда это сообщение отправляется по сети.
Я включил подробный трафик WCF.
У меня также есть регистрация уровня приложения, которая регистрирует идентификаторы сообщений, определенные кодом приложения (позвольте мне назвать это "идентификатор сообщения приложения" ).
Я включил положительное и отрицательное журналирование источника сообщений MSMQ, которые отправляются.
Я включил ведение журнала в очереди приема.

Проблема:

Когда сообщения пропадают, я знаю недостающий идентификатор приложения сообщения (он регистрируется отправляющей стороной). Теперь я хотел бы посмотреть трассировку End-to-End, чтобы увидеть было ли сообщение записано в исходящую очередь или нет.

Как я могу сопоставить события в трассе End-to-End с журналами уровня приложений и трассировками WCF?

Идеи:

При отправке сообщения MSMQ с использованием управляемого MSMQ API в System.Messaging сообщение MSMQ сообщения доступно после отправки сообщения. Однако я не нашел способ зарегистрировать это, когда WCF выполняет операцию отправки. Трасса WCF регистрирует MSMQMessageId guid, но это значение, на удивление, не является фактическим идентификатором MSMQ, как я предполагал. Возможно ли получить доступ к фактическому идентификатору сообщения MSMQ и зарегистрировать его?
Запишите идентификатор собственного потока в журнале приложений вместе с идентификатором уровня приложения и отметкой времени. Идентификатор собственного потока регистрируется в концевой трассировке MSMQ, поэтому на самом деле этого может быть достаточно для корреляции. Это план Б для меня, если я не найду более элегантное решение.

Ответ 1

Похоже, ты на правильном пути. Однако вы можете немного увеличить это:

Использование SvcConfigEditor.exe

Настроить подробный трассировки WCF для отслеживания активности и отслеживания активности.
Настроить WCF MessageLogging для "Отклоненные сообщения, служебные сообщения, транспортные сообщения"

Использовать LogEntireMessage

В конце до конца проследите все

Убедитесь, что эти *.config включены в обе стороны, ваш и сторонний исполняемый файл.

Соберите файлы журналов и добавьте их ALL в SvcTraceViewer.exe

Ответ 2

Вы можете настроить Windows MSMQ на предмет восприятия сообщений, а если тема содержит ключевое слово, то запустите приложение. Это приложение может регистрировать входящие сообщения. В стороне отправителя вы можете записать фактический идентификатор сообщения в тему сообщения и добавить свое ключевое слово к теме. В приложении, использующем приемник, можно получить доступ к фактическому идентификатору сообщения рядом с добавленным ключевым словом в теме.

Ответ 3

Похоже, что ваше сообщение отбрасывается WCF, потому что оно некорректно искажено (т.е. несоответствие контракта, превышен один из ограничений размера сообщения WCF).

Чтобы уловить эту ошибку, вы можете написать ErrorHanlder, который проверяет эти ошибки. Здесь ссылка к образцу этого.

Другой вариант, если вы используете Win 2008 R2 и выше, заключается в использовании встроенной обработки ядовитых сообщений. здесь ссылка в документы.

Чтобы задать вопрос, проследить до конца идентификатор трассировки приложения: Я бы передал идентификатор трассировки приложения в заголовке сообщения (посмотрите здесь пример).

Чтобы проверить заголовок сообщения на стороне службы, я бы использовал WCF IOperationInvoker для перехвата каждого вызова и проверки идентификатора в заголовке сообщения.

Это можно настроить в файле конфигурации для процесса, не изменяя сторонний код. здесь пример того, как реализовать invoker и как установить он в config.