Как обнаружить зависимости от исключений

Question

Ранее я задавал вопрос о конкретной выборке телеметрии , где можно отбросить 10% успешных вызовов.

Оказывается, что зависимости нужно обрабатывать отдельно.Фильтрация большинства успешных зависимостей, вероятно, приведет к потере информации о сбоях / исключениях.

Есть ли способ узнать, принадлежит ли зависимость исключению или кластерным элементам телеметрии, которые принадлежат друг другу?

Редактировать: Очевидно, существует свойство 'успешный вызов' .Но мало информации можно найти об этом.Означает ли это, что сама зависимость вышла из строя или исходный вызов не прошел?

Answer 1

Есть ли способ узнать, принадлежит ли зависимость исключению или кластерным элементам телеметрии, которые принадлежат друг другу?

Вы можете использовать operation_id, чтобы найти всю телеметрию за одну операцию. Однако вам, вероятно, это не нужно, поскольку выборка по умолчанию либо сохраняет, либо отбрасывает всю телеметрию от одной операции (т. Е. Тот же идентификатор operation_id).

Таким образом, если ваш запрос не удался, и эта телеметрия захвачена информацией о приложении, и выборка решает отправить этот запрос, то вся связанная с ней телеметрия, включая исключения, также будет сохранена.

Answer 2

Телеметрия, которая объединяет вместе должна иметь одно и то же operation_Id, поэтому, если вы ищете способ сгруппировать вещи вместе (как это делается в подробном представлении от конца до конца), вам нужнопосмотрите на operation_Ids.

в идеале, у вас будет входящий запрос, который устанавливает контекст operation_Id / operation_Name, а затем все , что произошло внутри этого запроса, включая журналы,зависимости, исключения, события, метрики и т. д. имеют одинаковое значение operation_Id и могут быть найдены вместе.

Успешный вызов зависимости указывает, что конкретный «исходящий» запрос успешно выполнен.У вас все еще могут быть запросы, которые успешно выполняются, даже если зависимости внутри этого запроса не выполняются, или наоборот, в зависимости от того, как работает ваша система.

Единственный «уловка» здесь - это использование асинхронной синхронизации.В тех случаях, когда асинхронный код фактически выполняется, он может не иметь доступа к запросу, который / выполнялся, когда был инициирован асинхронный код.в этих случаях вам, возможно, придется проделать дополнительную работу самостоятельно, чтобы убедиться, что контекст операции правильно передается через ваш асинхронный код.