Если частота выборки трассировок в вашей сетевой службе (Service Mesh) установлена на слишком низком уровне, вы можете увидеть данные трассировки только в том случае, если запросов будет достаточно много.
Вы можете увеличить частоту выборки в зависимости от ваших потребностей.
При запросе данных трассировок из последних временных интервалов (например, за последние 30 минут), если результаты трассировки не включают данные за последние 10 секунд, это нормально. Вы можете подождать немного и обновить страницу, чтобы попробовать снова.
Это происходит потому, что данные трассировки хранятся в Elasticsearch, который предоставляет возможности поиска почти в реальном времени.
Кроме того, ASM настраивает индекс трассировки в Elasticsearch с настройкой по умолчанию "refresh_interval": "10s"
, что означает, что Elasticsearch обновляет данные из памяти на диск каждые 10 секунд, после чего они становятся доступными для поиска.
Эта конфигурация индекса эффективно снижает нагрузку по слиянию данных в Elasticsearch, улучшая скорость индексации и начальную производительность запросов, но немного ухудшает реальное время обработки данных.
Вы можете настроить эту конфигурацию, используя параметр запуска --es.asm.index-refresh-interval
для jaeger-collector
. Значение по умолчанию — 10s
.
Если этот параметр установлен в "null"
, то refresh_interval
индекса не будет настроен.
При выполнении запросов трассировок, если технические принципы, лежащие в основе параметра Span kind
, не совсем понятны, это может привести к отсутствию возвращаемых данных. Поэтому не рекомендуется использовать этот параметр произвольно. Особенно, когда одновременно указаны и Client
, и Server
, это может привести к пустым результатам запроса.
Span kind
установлен на Root Span
, и указаны оба Client
и Server
В этом случае запрос не вернет никаких данных. Причина в том, что когда и клиент, и сервер контролируются OTel Agent, корневой спан трассировки обычно находится на стороне клиента, и данные сервера не будут извлечены. Для решения этой проблемы удалите условие Server
или избегайте выбора Root Span
.
Span kind
установлен на Service Entry Span
, и указаны оба Client
и Server
Аналогично, этот запрос также не вернет никаких данных. Это связано с тем, что когда и клиент, и сервер имеют внедренный Sidecar, Service Entry Span
относится к первому запросу, полученному сервером, но данные трассировки хранятся на стороне клиента. Чтобы решить эту проблему, удалите условие Client
или избегайте выбора Service Entry Span
.
При запросе данных трассировок за последние временные интервалы (например, за последние 30 минут), если спаны внутри трассировок неполные, это нормально. Вы можете подождать немного и обновить страницу, чтобы попробовать снова.
Это происходит потому, что в то время как Elasticsearch обновляет последние спаны на диск, некоторые спаны могут еще не быть сгенерированы или записаны на диск, что приводит к неполным результатам трассировки.
Если запрашиваемые трассировки имеют длительные временные интервалы (например, превышающие один час), могут быть возвращены неполные данные, что нормально.
По умолчанию, когда ASM запрашивает трассировки для спана, временной диапазон охватывает один час до и один час после времени начала и окончания спана.
Например, если спан начинается в 08:12:30 и заканчивается в 08:12:32 , временной диапазон запроса для этой трассировки составит с 07:12:30 по 09:12:32 .
Таким образом, если трассировка занимает более одного часа, запрос по этому спану может не извлечь полную трассировку.
Если трассировки в вашей среде обычно имеют длительные временные интервалы, вы можете отрегулировать временной диапазон запроса для отдельных трассировок, используя параметр запуска --es.asm.span-trace-query-time-adjustment-hours
для jaeger-query
.
Значение по умолчанию для этого параметра составляет один час, но вы можете увеличить его по мере необходимости.