[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-nablyudaemost-chto-takoe-distributed-tracing":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},764,"chto-takoe-distributed-tracing",20,"nablyudaemost","Наблюдаемость","📊","Что такое distributed tracing?","Distributed tracing (распределённая трассировка) — метод отслеживания прохождения запроса через множество сервисов в распределённой системе. Каждый запрос получает уникальный идентификатор (traceId), который передаётся между сервисами, позволяя восстановить полную картину обработки.\n\n### Зачем нужен distributed tracing\n\nВ микросервисной архитектуре один пользовательский запрос может вызвать цепочку вызовов:\n\n```\nПользователь → API Gateway → Order Service → Payment Service → Notification Service\n                                  │                                    │\n                                  └── Inventory Service                └── Email Service\n                                         │\n                                         └── Warehouse Service\n```\n\nБез distributed tracing невозможно:\n- Понять, какой сервис в цепочке вызвал задержку\n- Отследить, где произошла ошибка\n- Увидеть зависимости между сервисами\n- Оценить влияние одного сервиса на остальные\n\n### Основные концепции\n\n| Концепция | Описание |\n|-----------|----------|\n| Trace | Полная запись обработки одного запроса через все сервисы (уникальный `traceId`) |\n| Span | Единица работы внутри trace: spanId, parentSpanId, operationName, startTime, duration, tags, status |\n| Context Propagation | Механизм передачи traceId\u002FspanId между сервисами через HTTP-заголовки, Kafka headers, gRPC metadata |\n\n### W3C Trace Context (стандарт)\n\n```http\nGET \u002Fapi\u002Forders HTTP\u002F1.1\nHost: order-service\ntraceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01\n\n# traceparent формат:\n# {version}-{trace-id}-{parent-id}-{trace-flags}\n# 00       - 4bf92f...  - 00f067...  - 01 (sampled)\n```\n\n### Waterfall-диаграмма (визуализация трейса)\n\n```\nTraceID: abc123def456\n\n├── API Gateway: GET \u002Fapi\u002Forders [250ms] ────────────────────────────────────\n│   ├── Order Service: getOrders [200ms] ────────────────────────────────\n│   │   ├── PostgreSQL: SELECT * FROM orders [15ms] ──────\n│   │   ├── Redis: GET cache:orders [2ms] ──\n│   │   ├── Inventory Service: checkStock [120ms] ─────────────────\n│   │   │   └── Warehouse DB: SELECT stock [10ms] ────\n│   │   └── Payment Service: validatePayments [50ms] ──────────\n│   │       └── Stripe API: GET \u002Fcharges [40ms] ────────\n│   └── Auth: validateToken [5ms] ──\n```\n\nПо этой диаграмме видно:\n- Общее время запроса — 250ms\n- Самая долгая операция — checkStock (120ms) — кандидат на оптимизацию\n- Запросы к Redis и Auth выполняются быстро\n- Order Service ждёт последовательно Inventory и Payment — можно параллелить\n\n### Стратегии семплирования (Sampling)\n\nТрейсить 100% запросов в production дорого. Стратегии:\n\n| Стратегия | Описание | Когда использовать |\n|-----------|----------|-------------------|\n| Head-based | Решение о семплировании принимается в начале трейса | Простая, но может пропустить интересные трейсы |\n| Tail-based | Решение принимается после завершения трейса | Позволяет сохранять трейсы с ошибками или высокой задержкой |\n| Rate limiting | Фиксированное количество трейсов в секунду | Контроль нагрузки |\n| Probabilistic | Фиксированный процент (1%, 10%) | Простейший вариант |\n\n\u003Cdetails>\u003Csummary>Пример tail-based sampling в OTel Collector\u003C\u002Fsummary>\n\n```yaml\nprocessors:\n  tail_sampling:\n    decision_wait: 10s\n    policies:\n      - name: errors\n        type: status_code\n        status_code: {status_codes: [ERROR]}\n      - name: slow-traces\n        type: latency\n        latency: {threshold_ms: 1000}\n      - name: probabilistic\n        type: probabilistic\n        probabilistic: {sampling_percentage: 10}\n```\n\n\u003C\u002Fdetails>\n\n### Важное\n- **Context propagation** — критически важен. Если хотя бы один сервис в цепочке не передаёт контекст, трейс обрывается.\n- **Span — не лог**. Span описывает единицу работы с началом и концом. Не создавайте span для каждой строки кода.\n- **Instrumentation библиотеки** (JDBC, HTTP-клиенты, Kafka, gRPC) автоматически создают spans — не нужно оборачивать каждый вызов вручную.\n- **Sampling** обязателен в production: без него overhead на трейсинг может составлять 5-15% ресурсов.\n\n### Частые ошибки\n- **Потеря контекста при асинхронных вызовах**: при использовании `@Async`, `CompletableFuture`, реактивных цепочек контекст нужно передавать явно.\n- **Слишком детальные спаны**: создание span на каждый вызов метода перегружает систему. Спаны нужны для I\u002FO-операций и бизнес-логики.\n- **Игнорирование семплирования**: 100% трейсов в production — это огромный объём данных и нагрузка на хранилище.\n- **Несогласованные имена операций**: `getOrder`, `GET_ORDER`, `order.get` — разные имена для одной операции усложняют анализ.\n\n### Как используется в 2026\n- **W3C Trace Context** — стандарт де-факто для propagation.\n- **OpenTelemetry** — единый API и SDK для трейсинга, заменивший Jaeger client, Zipkin Brave и OpenTracing.\n- **Grafana Tempo** и **Jaeger v2** — популярные бэкенды для хранения трейсов.\n- **Trace-based testing** (Tracetest) — использование трейсов для написания интеграционных тестов.\n- **Continuous profiling + tracing** — связка профилирования с трейсами (Grafana Pyroscope).\n\n> **На собеседовании:** объясните концепции Trace\u002FSpan\u002FContext Propagation и покажите, что умеете читать waterfall-диаграмму. Упомяните необходимость семплирования в production и W3C Trace Context как стандарт. Частая ошибка — забыть про потерю контекста в асинхронных вызовах.","","middle",[15],"observability",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":23,"featuredSnippetReady":24},"Что такое distributed tracing? — Gymterview","Distributed tracing (распределённая трассировка) — метод отслеживания прохождения запроса через множество сервисов в распределённой системе. Каждый запрос получ","Distributed tracing (распределённая трассировка) — метод отслеживания прохождения запроса через множество сервисов в рас",[15,13],"Distributed tracing (распределённая трассировка) — метод отслеживания прохождения запроса через множество сервисов в распределённой системе. Каждый запрос получает уникальный идентификатор (traceId), который передаётся между сервисами, позволяя восстановить полную картину обработки.",true]