Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: Observability · Уровень: Middle+/Senior ## TL;DR Distributed tracing восстанавливает путь **одного запроса** через множество сервисов как дерево/DAG **спанов**. Trace = набор спанов с общим `trace_id`; span = одна операция (start/end/attributes/events/status/kind), ссылающаяся на родителя. Связь между сервисами держится на **context propagation**: W3C `traceparent` (= `version-trace_id-span_id-flags`) инжектится в исходящие заголовки и извлекается на входе. **Sampling** решает, какие трейсы хранить: **head-based** (решение на старте, дёшево, но может пропустить редкие ошибки) или **tail-based** (решение после завершения трейса в коллекторе — можно отобрать по latency/error, но дорого по памяти/буферизации). Чтение трейса = поиск critical path, gaps (сеть/блокировки/GC), fan-out и N+1. Корреляция: `trace_id` в логах, exemplars из метрик в трейс. Senior-грабли: разрыв контекста на `context.Background()`, потеря спана в горутине без `ctx`, clock skew, и `RecordError` ≠ `SetStatus`. ## Теория ### Модель данных ```text trace_id = 4bf92f3577b34da6a3ce929d0e0e4736 (один на весь запрос) [SERVER] GET /checkout span A (root, 230ms) ├─[CLIENT] POST cart-service span B (parent=A, 40ms) │ └─[SERVER] cart handler span C (parent=B, в другом сервисе) ├─[CLIENT] POST payment span D (parent=A, 150ms) ← critical path └─[PRODUCER] publish order span E (parent=A, async) ⋮ link [CONSUMER] order-worker span F (link→E, позже) ``` **Span** содержит: - `trace_id`, `span_id`, `parent_span_id` - start/end time → duration - **attributes** (key=value: `http.method`, `db.statement`, `user.id`) - **events** (точечные отметки во времени: exception, cache miss) - **status** (Ok/Error/Unset) - **kind**: `SERVER`/`CLIENT`/`PRODUCER`/`CONSUMER`/`INTERNAL` — критично для бэкенда (как строить causality, кто инициатор сетевого вызова) - **links** — ссылки на другие спаны вне parent-child ```go tracer := otel.Tracer("checkout") ctx, span := tracer.Start(ctx, "charge", trace.WithSpanKind(trace.SpanKindClient), trace.WithAttributes(attribute.String("payment.provider", "stripe")), ) defer span.End() span.AddEvent("retry", trace.WithAttributes(attribute.Int("attempt", 2))) if err != nil { span.RecordError(err) // событие exception span.SetStatus(codes.Error, "charge failed") // помечает спан как failed } ``` ### Trace context propagation (W3C) ```text traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 │ │ │ │ │ trace_id (16 байт / 32 hex) span_id (8б) trace-flags version (00) (parent для next) (01 = sampled) tracestate: vendor1=value,vendor2=value (vendor-специфичный контекст, упорядочен) ``` - **version** `00` — текущая версия формата. - **trace_id** — 16 байт, общий на весь трейс. - **span_id** (parent-id в заголовке) — id текущего спана, станет parent'ом следующего hop'а. - **flags** — битовая маска; младший бит = `sampled`. Именно он переносит решение сэмплера между сервисами → consistent sampling. **Inject / Extract**: ```go // исходящий запрос — inject (обычно делает otelhttp.Transport) otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header)) // входящий запрос — extract (обычно делает otelhttp.Handler) ctx = otel.GetTextMapPropagator().Extract(ctx, propagation.HeaderCarrier(r.Header)) ``` **B3** (Zipkin legacy) — старый формат (`X-B3-TraceId`, `X-B3-SpanId`, `X-B3-Sampled`), часто поддерживают параллельно с W3C для миграции через composite propagator. ### Span links Parent-child выражает «вызвал и ждёт». Но бывает **fan-in / batch**, где у спана несколько «причин»: - **Batch processing**: воркер обрабатывает 100 сообщений из очереди в одном спане — у него 100 producer-спанов как links, а не один parent. - **Fan-out aggregation**: спан, агрегирующий результаты N параллельных запросов. - **Async**: producer (publish) и consumer (обработка позже) связаны link'ом, а не parent-child, т.к. consumer не «внутри» producer. ```go ctx, span := tracer.Start(ctx, "process-batch", trace.WithLinks( trace.Link{SpanContext: msg1SpanCtx}, trace.Link{SpanContext: msg2SpanCtx}, ), ) ``` ### Sampling | | Head-based | Tail-based | |---|-----------|-----------| | Когда решение | На старте корневого спана | После завершения **всего** трейса | | Где | В приложении (SDK) | В коллекторе (gateway) | | Критерии | Вероятность / rate / parent | latency, error, attributes — по факту | | Стоимость | Дёшево | Дорого (буфер всех спанов трейса в памяти) | | Минус | Пропускает редкие медленные/ошибочные трейсы (решает до того, как узнал результат) | Память, late spans, сложность | **Head-based** виды: - *Probabilistic* (`TraceIDRatioBased(0.1)`) — детерминированный хеш trace_id, 10%. - *Parent-based* — уважать решение родителя (флаг sampled в traceparent) → consistent trace. - *Rate-limiting* — N трейсов/сек. Каноничный head-config: `ParentBased(TraceIDRatioBased(p))` — корень бросает кубик, потомки уважают флаг родителя → трейс семплируется целиком или не семплируется вовсе. **Tail-based** — коллектор буферизует все спаны трейса до его завершения (по таймауту/закрытию root), затем применяет политику: «оставить все трейсы с ошибкой», «оставить если latency > 1s», «1% успешных». Так редкие проблемные трейсы не теряются. Цена — gateway-collector держит спаны в памяти и должен собрать весь трейс (проблема с очень долгими/незакрытыми трейсами и late spans, приходящими после решения). ### Как читать трейс - **Critical path** — самая длинная цепочка зависимых спанов, определяющая total latency. Оптимизировать имеет смысл только её. Параллельные ветки короче critical path не влияют на итог. - **Gaps между спанами** — белое пространство в timeline = время вне инструментированного кода: сеть, ожидание блокировки/lock, GC-пауза, очередь пула, time-to-first-byte. - **N+1 в трейсе** — лесенка из сотен одинаковых коротких CLIENT-спанов к БД = классический N+1 запрос. - **Fan-out** — много параллельных CLIENT-спанов из одного родителя; смотри, не ограничивает ли самый медленный (tail amplification). - **Async gaps** — большой разрыв между producer и consumer (link) = задержка в очереди, а не в обработке. ### Корреляция трёх сигналов - **Логи**: класть `trace_id`/`span_id` в каждую запись (через slog Handler из ctx) → из лога прыжок в трейс. - **Метрики → трейс**: **exemplars** — точки гистограммы латенси несут trace_id примера; кликаешь медленную точку → конкретный медленный трейс. - **Span events** — заменяют часть «локальных» логов внутри спана, давая контекст без отдельной log-строки. ## Подводные камни / gotchas - **Разрыв контекста**: где-то создан новый `context.Background()` вместо проброса входящего `ctx` → дочерний спан становится root, трейс рвётся. - **Потеря спана в горутине**: запустил `go func(){...}` без передачи `ctx` → работа не связана с трейсом. Передавай `ctx` в горутину (но не используй уже отменённый ctx, если работа должна пережить запрос). - **Head sampling пропускает редкие ошибки**: решение принято до того, как стало известно, что запрос упал/тормозил. Для «всегда ловить ошибки» нужен tail sampling. - **Tail sampling — память и late spans**: коллектор буферизует трейсы; спаны, пришедшие после принятия решения, теряются; долгие трейсы раздувают буфер. - **Partial traces**: несогласованный sampling между сервисами (разные политики, нет `ParentBased`) → часть спанов записана, часть нет → битый трейс. - **Clock skew**: рассинхрон часов между хостами искажает timeline — дочерний спан «раньше» родителя, отрицательные gaps. Бэкенды частично корректируют, но точность страдает. - **`RecordError` ≠ `SetStatus`**: первый добавляет event, но не делает спан failed; нужно ещё `SetStatus(codes.Error, ...)`, иначе error-rate и tail-policy не сработают. - **Слишком много спанов** = шум + стоимость хранения + оверхед. Не оборачивай каждую функцию; спан — это значимая граница (RPC, БД, важная стадия). - **trace_id в логе есть, а трейса нет**: трейс не прошёл sampling (флаг 0), а лог пишется всегда → ссылка ведёт в пустоту. Логируй sampled-флаг или принимай это как норму. ## Вопросы на собеседовании **В:** Что несёт `traceparent` и какой бит критичен для распределённого sampling? **О:** `version-trace_id-span_id-trace-flags`. trace_id общий на весь трейс, span_id текущего спана (станет parent'ом следующего hop'а), а в trace-flags младший бит = sampled. Именно он переносит решение сэмплера между сервисами: с `ParentBased` downstream уважает этот флаг, поэтому трейс семплируется целиком или не семплируется вовсе. **В:** Head vs tail sampling — trade-offs и где tail реализуется? **О:** Head решает на старте в SDK — дёшево, но не знает исхода запроса, поэтому теряет редкие медленные/ошибочные трейсы. Tail решает после завершения трейса в gateway-коллекторе, который буферизует все спаны трейса, и может оставить именно ошибочные/медленные. Цена tail — память на буфер, сложность сборки всего трейса и проблема late spans. На практике часто комбинируют: небольшой head-sample + tail для error/slow. **В:** Зачем span links, если есть parent-child? **О:** Parent-child = «вызвал и ждёт результат», одно дерево. Links нужны для many-to-one и async: batch-воркер обрабатывает много сообщений (links на все producer-спаны), fan-in агрегация, и producer/consumer через очередь (consumer связан с producer link'ом, а не parent, т.к. выполняется не внутри него). Без links эти связи либо теряются, либо ломают дерево. **В:** Как найти, что оптимизировать, по трейсу? **О:** Найти critical path — самую длинную цепочку зависимых спанов, она определяет общую латенси; ускорение параллельных веток короче её ничего не даст. Затем смотреть gaps (сеть/lock/GC/очередь), N+1 (лесенка одинаковых БД-спанов) и fan-out tail (самый медленный из параллельных). Атрибуты и events дают причину. **В:** Чем `RecordError` отличается от `SetStatus` и почему это важно для tail sampling? **О:** `RecordError` добавляет event-исключение, но спан остаётся Unset/Ok. `SetStatus(codes.Error, ...)` помечает спан как failed. Tail-политики и error-rate в UI смотрят именно на status, поэтому без `SetStatus` ошибочный трейс не попадёт в «оставить все ошибки» и не отразится в метриках ошибок. Нужны оба. **В:** Как обеспечить, чтобы один трейс не оказался «полузаписанным»? **О:** Consistent sampling: `ParentBased(TraceIDRatioBased(p))` на всех сервисах. Корень принимает решение по детерминированному хешу trace_id, потомки уважают флаг sampled из traceparent. Так все сервисы согласованно пишут или не пишут спаны одного трейса. Без ParentBased каждый сервис решает независимо → partial traces. **В:** Как трейсы коррелируются с логами и метриками? **О:** trace_id/span_id кладутся в каждую лог-запись (через ctx-aware Handler) → из лога открыть трейс. Метрики связываются через exemplars: точки гистограммы латенси несут trace_id примера, клик ведёт к конкретному медленному трейсу. Внутри трейса span events заменяют часть логов. Всё крутится вокруг общего trace_id. ## На что копают на senior+ - **Архитектура tail sampling**: gateway-collector, буферизация по trace_id, политики (latency/error/composite), проблема late spans и долгих трейсов, память и масштабирование. - **Consistent sampling across services**: ParentBased, детерминированный хеш trace_id, головной семплинг + согласование с метриками. - **Репрезентативность при sampling**: если считать RPS/error-rate из сэмплированных трейсов — нужна коррекция на sampling rate (или метрики должны идти отдельным неосэмплированным каналом). - **Critical path analysis** и автоматическое выявление аномалий по трейсам. - **Clock skew** и его влияние на timeline; стратегии нормализации. - **Cost/cardinality трейсинга**: где экономить, span vs event, ограничение глубины/числа спанов, exemplars вместо хранения всех трейсов. - **Корреляция трёх сигналов** end-to-end в Grafana Tempo/Loki/Mimir и в OTel Collector.