Former co-worker did this, and we still have tons of docker images in production that lack basic debugging functionality like... a shell. Alpine Linux is only like 8 MB more :(
Thus, I spend the investment up front in getting log streaming working, my logs are concise, I implement application monitoring, and I demand host monitoring from the platforms I use. If I check all of those boxes, I generally don't have anything I need to do with a shell.
Second to that is that I have dev stages that are built with containers that do have those tools, and generally if I run into those kinds of problems I see them in dev first.
That's a commendable security practice. A whole class of vulnerabilities is mitigated (and others are much harder to exploit) if you don't add unnecessary junk to your images, like a shell.
It's also endorsed by Google via distroless: https://github.com/GoogleContainerTools/distroless
I (as a devops engineer) did that because (rightfully) rhe developers i was working with at the time didn’t include some troubleshooting tools (like tcpdump) and the inages were running as non root anyway.
Look up the manpage for nsenter, it’s all you need really.
Btw, tcpdump in production, hunting the correct network interface on a kubernetes cluster node… fond memories:)
While novel, you really need to have the engineering excellence in your org to be able to struct log to another system, blue/green deployments, etc.
One place where I worked where did bare metal orchestration with containers, we had tooling around seeing which services were failing, where to go look at logs (and filter them), and we threw away the ssh keys to the AWS ECS hosts to force you into a CD deployment model. You’ll never get Sherlock Holmes access to production. Not even to run SQL queries against your production database.