Какие инструменты для профилирования сервисов на Go существуют и как их использовать

Что проверяют

Умеете ли вы искать узкое место по данным, а не наугад, и знаете ли, какой профиль отвечает на какой вопрос. Следом спрашивают, как вы профилировали сервис на проде и безопасно ли держать pprof включённым.

Как отвечать

Основа встроена в стандартную библиотеку:

• net/http/pprof: пустой импорт регистрирует /debug/pprof/ на http.DefaultServeMux. Снимают так: go tool pprof -http=:8080 http://host:6060/debug/pprof/profile?seconds=30, в веб-интерфейсе есть top, граф вызовов и flame graph;
• виды профилей: profile для CPU, heap с выбором inuse_space (текущая память) или alloc_space (все аллокации), goroutine для утечек горутин, block и mutex для ожиданий. Последние два выключены по умолчанию, их включают runtime.SetBlockProfileRate и runtime.SetMutexProfileFraction;
• бенчмарки: go test -bench=. -benchmem -cpuprofile cpu.out, с Go 1.24 цикл пишут как for b.Loop(). Результаты до и после сравнивают benchstat на нескольких прогонах;
• трассировка: go tool trace показывает планировщик, паузы GC и блокировки, которых не видно в CPU-профиле. В Go 1.25 появился trace.FlightRecorder: держит последние секунды трассы в памяти и сбрасывает по событию;
• непрерывное профилирование: Pyroscope или Parca собирают профили со всех инстансов, и профиль до релиза сравнивается с профилем после.

Хорошо упомянуть PGO: CPU-профиль с прода, положенный в пакет main как default.pgo, компилятор использует для оптимизаций при сборке.

Где спотыкаются

Открывают pprof наружу. Если основной сервер работает на DefaultServeMux, пустой импорт отдаёт профили всем. Обработчики вешают на отдельный порт, доступный только изнутри.

Ищут причину высокой задержки в CPU-профиле. Если сервис ждёт базу или мьютекс, процессор простаивает, и ответ дадут block, mutex или трасса.

Путают inuse_space и alloc_space. Для утечки нужна текущая память, для давления на GC нужны суммарные аллокации.