self-written code, mature modules output to info level, newly written modules debug level, 99% of the possible problems are here.
other people's modules, just output warn.

here you refer to yourself or your team.
other people's home refers to systems and open source frameworks or tools.

the trick is:
do not log during high concurrency, or collect logs above info through the logging system.
it doesn't matter if it is not high concurrency.

when there is high concurrency, the problem is not located through the log at all. With so much traffic, how do you know which error is caused?

I like to split files by nature. Here is a simple example
http://www.itdfy.com/details/.

there are mainly two kinds of logs, error log and analysis log

errors are thrown by each module, and errors are handled uniformly at the top level, and error messages are output to the error log
Analysis log is generally used for statistics. Generally, there is only one request at a time, including all the information related to this request, including some statistical indicators

use github.com/sirupsen/logrus + github.com/sohlich/elogrus to collect logs to es, for statistical analysis based on es, and monitor alarms

what is said above is actually true. Let me also talk about some of my personal experience:
1. Do not print too many logs, but only print logs involving adding, modifying and deleting
2, thread names and lines of code should be printed with
3. It is best to type object attributes
4. Log of statistical type must be typed, for example, the execution time of a task, so the service becomes slow. You can quickly find

log classification: run log, operation log, interface log, etc.
different logs print information that requires different types of logs according to business requirements