Нужно диагностировать проблему производительности в production-контейнере (высокая латентность) без влияния на обслуживание трафика и без установки дополнительных инструментов внутрь минимального/distroless образа. Какие подходы возможны и какие у них издержки?

Короткий ответ

Единственного правильного инструмента нет: можно подключать временный debug-контейнер с общими namespaces к целевому, использовать nsenter с хоста для захода прямо в namespaces процесса, либо заранее внедрённую систему continuous profiling (например, на основе eBPF), если экстренная точечная отладка на проде недопустима в принципе.

Как это работает подробнее

debug-контейнер, запущенный с --network=container:TARGET и --pid=container:TARGET, получает видимость процессов и сетевого стека целевого контейнера без его остановки, но не имеет доступа к его файловой системе, если она не смонтирована отдельно. nsenter -t PID -n ..., выполненный прямо на хосте с правами root, даёт более полный доступ (включая возможность работать с инструментами хоста напрямую в контексте namespaces процесса), но требует root-доступа к самому хосту, что расширяет поверхность риска при ошибке оператора. Continuous profiling системы (например, eBPF-based профилировщики) собирают данные постоянно в фоне с относительно низким оверхедом, устраняя необходимость экстренной точечной диагностики, но требуют заранее внедрённой инфраструктуры и добавляют постоянную (хоть и небольшую) нагрузку на все контейнеры, а не только проблемный.

Пример кода

Пример конфигурацииКопировать

$ PID=$(docker inspect -f '{{.State.Pid}}' app)
$ sudo nsenter -t $PID -n ss -tlnp
State   Recv-Q  Send-Q  Local Address:Port   Process
LISTEN  0       128     0.0.0.0:8080         users:(("app",pid=12345,fd=9))

Что использовать на практике

• Практика. выбор инструмента зависит от того, насколько критичен сервис (можно ли рискнуть доступом root на хосте в моменте инцидента), насколько часто повторяются подобные проблемы (разово — debug-контейнер достаточен, систематически — стоит внедрить постоянный профилировщик) и от зрелости observability-практик команды.

Подводные камни

• Риск. используют nsenter с хоста как "универсальный быстрый способ" без оценки риска повышенных прав в момент инцидента на критичном проде; откладывают внедрение continuous profiling до тех пор, пока проблема производительности не стала хронической, теряя время на повторяющуюся экстренную отладку вместо системного решения.