#Невозможно выполнить запрос необходимого трассировочного покрытия

#Описание проблемы

При выполнении запроса трассировки в сервисной сетке вы можете столкнуться с ситуациями, когда целевую трассировку невозможно извлечь.

#Анализ коренной причины

#1. Слишком низкий коэффициент выборки трассировки

Когда параметр коэффициента выборки для трассировки установлен слишком низко, система будет собирать данные трассировки пропорционально. В периоды недостаточного объема запросов или в низкопиковые времена это может привести к тому, что собранные данные окажутся ниже порога видимости.

#2. Ограничения Elasticsearch в реальном времени

Конфигурация индекса Elasticsearch по умолчанию составляет "refresh_interval": "10s", что приводит к задержке в 10 секунд перед тем, как данные обновляются из буфера памяти в состояние доступности для поиска. При запросе недавно созданных трассировок результаты могут отсутствовать, поскольку данные еще не были сохранены.

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

#3. Неправильные настройки условий запроса

При выполнении запросов трассировки, если технические принципы, стоящие за параметром Span kind, не понятны, это может привести к отсутствию возвращаемых данных. Поэтому не рекомендуется использовать этот параметр произвольно. Особенно когда и Client, и Server указаны, это может привести к пустым результатам запроса.

#Пример 1: Span kind установлен на Root Span с указанными обоими Client и Server

В этом случае запрос вернет нет данных. Причина заключается в том, что когда и клиент, и сервер управляются OTel Agent, корневое покрытие трассировки обычно находится на стороне клиента, и данные сервера не будут извлечены. Чтобы решить эту проблему, удалите условие Server или избегайте выбора Root Span.

#Пример 2: Span kind установлен на Service Entry Span с указанными обоими Client и Server

Аналогично, этот запрос также вернет нет данных. Причина в том, что когда и клиент, и сервер имеют инъектированный Sidecar, Service Entry Span относится к первому запросу, полученному сервером, но данные трассировки хранятся на стороне клиента. Чтобы решить эту проблему, удалите условие Client или избегайте выбора Service Entry Span.

#Решение для коренной причины 1

• Соответствующим образом увеличьте коэффициент выборки в соответствии с требованиями.
• Используйте более богатые методы выборки, такие как выборка по хвосту.

#Решение для коренной причины 2

Отрегулируйте интервал обновления с помощью параметра запуска --es.asm.index-refresh-interval для jaeger-collector, со значением по умолчанию 10s.

Если значение этого параметра установлено на "null", то конфигурация для refresh_interval индекса отсутствует.

Примечание: Установка значения на "null" повлияет на производительность и скорость запросов Elasticsearch.

#Решение для коренной причины 3

При использовании параметра Span kind в запросах трассировки:

• Избегайте одновременного использования условий Client и Server
• Для запросов Root Span:
  • Удалите условие Server, если присутствуют и клиент, и сервер
  • Или избегайте выбора Root Span, если вам нужны данные со стороны сервера
• Для запросов Service Entry Span:
  • Удалите условие Client, если присутствуют и клиент, и сервер
  • Или избегайте выбора Service Entry Span, если вам нужны данные со стороны клиента