Jaeger / Tempo для трейсов
Тема дорожной карты · Kubernetes
Jaeger и Grafana Tempo — два ведущих бэкенда распределённой трассировки, используемых в стеках наблюдаемости Kubernetes для сбора, хранения и запроса трассировок в формате OpenTelemetry от микросервисов. Jaeger — первоначально разработанный в Uber, а теперь выпускник CNCF — состоит из компонентов jaeger-collector, jaeger-query и jaeger-agent, развёртываемых в K8s, принимающих трассировки по протоколам OTLP, Thrift и gRPC и хранящих их в Cassandra, Elasticsearch или in-memory бэкенде. Grafana Tempo — горизонтально масштабируемый, экономичный бэкенд распределённой трассировки, хранящий трассировки в объектном хранилище (S3, GCS, Azure Blob) и запрашиваемый напрямую из Grafana с помощью TraceQL — специального языка запросов трассировок; является предпочтительным выбором в стеках Grafana LGTM (Loki, Grafana, Tempo, Mimir). Приложения, развёрнутые как Pod'ы Kubernetes, инструментируются с помощью OpenTelemetry SDK или авто-инструментирования через opentelemetry-operator, который внедряет sidecar-коллектор OTel и настраивает экспорт трассировок в Jaeger или Tempo через переменную окружения OTEL_EXPORTER_OTLP_ENDPOINT.
Как это работает
Jaeger / Tempo для трейсов даёт видимость поведения кластера и нагрузок через метрики (Prometheus, kube-state-metrics, cAdvisor), логи (kubelet шлёт stdout/stderr контейнера в log-агенты типа Fluent Bit / Vector / Loki) и трейсы (OpenTelemetry collectors + Jaeger/Tempo). Три сигнала коррелируют через labels — namespace, pod, container — так что во время incident response вы можете перейти от аномалии метрики к конкретным логам и трейсам.
Когда применять
Настройте Jaeger / Tempo для трейсов до масштабирования за одну команду или горстку сервисов — отладка проблем distributed system без метрик, логов и трейсов невозможно медленная. Используйте Prometheus + Grafana stack для self-hosted; managed-альтернативы (Datadog, New Relic) снижают операционную нагрузку при большей цене. SLO и alerts идут из того же metric pipeline; проектируйте вместе.
Типичные ошибки
Observability-ловушки: cardinality explosion (high-cardinality labels вроде user-id взрывают Prometheus storage); слишком много alerts (alert fatigue заглушает реальные проблемы); log volumes без retention policies (стоимость storage идёт в спираль); tracing только на API-границе (пропускаете медленные внутренние вызовы). Тюньте по мере роста трафика; observability-решения на низком масштабе не выживают 10x роста.