go trace
Тема дорожной карты · Golang
Распределённая трассировка в Go — техника наблюдаемости, записывающая причинно связанные спаны через несколько сервисов, goroutines и сетевых переходов, чтобы единственный запрос можно было визуализировать от начала до конца в таких инструментах, как Jaeger, Grafana Tempo или Zipkin. OpenTelemetry является стандартным SDK для распределённой трассировки в Go (go.opentelemetry.io/otel): tracer.Start(ctx, "span-name") создаёт спаны, которые автоматически распространяют W3C TraceContext-заголовки через инструментацию otelhttp и otelgrpc. context.Context — носитель распределённой трассировки в Go: каждая функция в цепочке вызовов получает ctx и передаёт его дочерним операциям — HTTP-вызовам клиентов, запросам к базе данных pgx, gRPC-вызовам сервисов, — чтобы полное дерево трассировки собиралось коллектором без ручной передачи. Команда go tool trace (отличная от OpenTelemetry) захватывает трассировки выполнения Go-рантайма — планирование goroutines, GC-паузы, системные вызовы, — полезные для диагностики скачков задержки, которые метрики Prometheus одни не могут объяснить. Полная настройка распределённой трассировки в Go направляет спаны в OpenTelemetry Collector, разветвляющийся к Grafana Tempo для трассировок, Prometheus для метрик и Loki для структурированных логов — три столпа наблюдаемости в Kubernetes-native Golang-развёртывании.
Как это работает
go trace использует pprof (CPU, memory, goroutine, block, mutex-профили), бенчмарки (go test -bench=.), trace-инструмент (go test -trace=trace.out + go tool trace), execution tracer для scheduling goroutines. -race-детектор для race conditions. Обычные победы: меньше аллокаций (sync.Pool, []byte slices, value-типы), избегать reflection в горячих путях, strings.Builder для конкатенации, профайл до оптимизации.
Когда применять
Всегда профайл до оптимизации — Go's pprof встроен и дружелюбен. pprof.StartCPUProfile в production за net/http/pprof (admin-эндпойнт, IP-restricted). Меньше аллокаций — обычно главная победа; вывод escape analysis (go build -gcflags="-m") показывает, что аллоцирует на heap vs stack.
Типичные ошибки
Ловушки go trace: микрооптимизация без замеров (Go-компилятор умный, преждевременная оптимизация часто вредит); sync.Pool для объектов, создаваемых раз на запрос (overhead pool > выгоды на низких rate); тюнинг GOGC по интуиции, не по бенчмарку (дефолт 100 обычно ок).