Is it not so bad to have many stacktraces in the log file?
I mean, you can see if something goes wrong - you can see where it comes from.
But what about performance? How badly it could be for the application with such logging format?
How can one switch the system between log with and without stacktraces in common loggers? Via log levels?
It is usually better to have stack traces in the log file - it will be easier to find a problem code.
If you are interested solely in the stacktrace generation performance - I have written an article about how long does it take to throw an exception In Java. Most of the time was being consumed by the stack trace generation: Throwing an exception in Java is very slow
Can I assume you are talking about stack traces triggered on a wall-clock time interrupt? These are valuable for locating performance problems. (They are much more valuable if they contain line number information at which calls take place, not just function/method names.)
However, they are only valuable if you can examine them, and you can't examine millions of them, so there's no value in taking them at anything close to high frequency. Almost any performance problem big enough to be worth fixing can be found in 20 or fewer stack samples, provided they are taken at random times during the overall execution phase you care about. Many people find that number surprising, but here's the math.
In principle, you could use more of them if you had a statistical summarizer, along the lines of the Zoom profiler, but you can actually do better manually, because your brain can recognize wasteful processing better than any statistic.