Распределённый трейсинг

Распределённый трейсинг следует за одной логической операцией через процессы: browser → API → БД → очередь → worker → сторонний HTTP. Показывает, где копится latency и какая зависимость владеет сбоем.

					[browser]──►[api]──►[postgres]
                └──►[payment-api]
                └──►[queue]──►[worker]
				

Sampling балансирует стоимость и покрытие: всегда трейсить ошибки и медленные пути; сэмплировать happy path. Трейсы полезны при общих ID с логами и exemplars метрик.

На интервью: critical path checkout, head-based vs tail-based sampling и трейсинг async после HTTP-ответа.

Типовые ошибки: контекст рвётся на очереди; только frontend; spans слишком мелкие (каждая функция) или грубые (один span на сервис).

Компромисс — overhead хранения и instrumentation против времени понимания cross-service инцидентов.

Чеклист:

• Propagation контекста на HTTP и messaging.
• Spans на границах зависимостей.
• Связь traces с логами через trace ID.
• Sampling осознанный, не 100% везде.