Устранение неполадок
Jaeger backend сам по себе является распределенной системой, состоящей из различных компонентов, которые потенциально могут работать на множестве хостов. Возможно, один из этих элементов работает неправильно, из-за чего spans не обрабатываются или не сохраняются. Если что-то идет не так, обязательно проверьте перечисленные здесь пункты.
Если вы используете OpenTelemetry Collector в составе вашего pipeline, обязательно ознакомьтесь с его собственным руководством по устранению неполадок.
Содержание
Проверьте стратегию samplingOpenTelemetry SDKsИспользование debug ExporterОбойдите промежуточные collectorsСетевая связностьУвеличьте подробность logsПроверьте endpoint /metricsService Mesh: отсутствующие spansПроверьте стратегию sampling
Прежде всего убедитесь, какая стратегия sampling используется. Для разработки или сценариев с низким трафиком полезно выполнять sample для каждого trace. В production, возможно, потребуется использовать более низкие rates. При диагностике причин, по которым spans не поступают в backend, убедитесь, что SDK настроен на sample каждого trace. Обычно стратегию sampling можно задать через environment variables.
OpenTelemetry SDKs
Если вы используете OpenTelemetry SDKs, по умолчанию должен использоваться sampler parentbased_always_on, что фактически означает sampling на уровне 100%. Его можно изменить через environment variable OTEL_TRACES_SAMPLER (см. документацию).
Использование debug Exporter
OpenTelemetry SDKs можно настроить с помощью debug exporter, который выводит записанные spans в консольный log. Включение этого режима позволяет проверить, действительно ли spans записываются.
Обойдите промежуточные collectors
Если ваши приложения отправляют данные не напрямую в Jaeger, а через промежуточные уровни, например OpenTelemetry Collector, запущенный как host agent, попробуйте настроить SDK на прямую отправку данных в Jaeger, чтобы сузить область поиска проблемы.
Сетевая связность
Если ваш Jaeger backend по-прежнему не может принимать spans (см. следующие разделы о проверке logs и metrics), то, скорее всего, проблема связана с конфигурацией network namespace. При запуске компонентов Jaeger backend в контейнерах типичными ошибками являются:
- Не выполняется экспонирование соответствующих ports наружу из контейнера. Например, collector может слушать
:4317внутри network namespace контейнера, но порт недоступен извне. - В качестве host name для server endpoints используется
localhost.localhostподходит при запуске на bare metal, но в контейнере рекомендуется слушать на0.0.0.0. - Host name Jaeger не виден из network namespace приложения. Например, если вы запускаете и приложение, и Jaeger backend в отдельных контейнерах, управляемых containerd, они должны либо находиться в одном network namespace, либо контейнер приложения должен быть подключен к той же сети, что и Jaeger backend, с помощью
nerdctl network connect.
Увеличьте подробность logs
Jaeger предоставляет полезную отладочную информацию, если уровень log установлен в debug.
Проверьте endpoint /metrics
В случаях, когда невозможно или нежелательно повышать подробность logging, endpoint /metrics можно использовать для проверки того, как trace data принимается и обрабатывается Jaeger. Дополнительные сведения о настройке generation metrics см. в разделе Configuring the Jaeger Metrics. Ниже приведен пример вызова curl для получения metrics:
Если Jaeger может принимать traces, счетчик otelcol_receiver_accepted_spans должен увеличиваться. Если он может успешно записывать traces в storage, счетчик otelcol_exporter_sent_spans также должен увеличиваться с той же скоростью.
Service Mesh: отсутствующие spans
При развертывании приложения в составе service mesh, например Istio, количество взаимодействующих компонентов значительно возрастает, что может повлиять на то, как (и какие) spans отправляются. Если вы ожидаете увидеть spans, сгенерированные service mesh, но они не отображаются в Jaeger UI, проверьте руководства по устранению неполадок для используемого вами service mesh. Например, на website Istio.