Log levels
Log levels are labels that mark how important each log line is. Common levels, from most to least verbose, are DEBUG, INFO, WARN, ERROR and FATAL, and some libraries add TRACE below DEBUG. A service runs with one level as its threshold and drops every line below it, so the same code can be chatty on a laptop and quiet in production.
How it works
Each level has a job. DEBUG holds detail for developers, such as query parameters or cache hits. INFO records normal events worth keeping, such as a request served or a job finished. WARN means something unexpected happened but the service carried on, like a retry. ERROR means an operation failed. FATAL means the process cannot continue and is about to exit. A threshold of INFO keeps INFO, WARN, ERROR and FATAL and drops DEBUG.
Say a service handles 2,000 requests per second and writes 1 INFO line and 5 DEBUG lines per request. At DEBUG that is 12,000 lines per second; at INFO it is 2,000. The 10,000 DEBUG lines per second you drop add up to 864 million lines a day that you do not pay to ship, index and store. When an incident needs them, raise the level on one instance, for example with LOG_LEVEL=debug, and lower it again afterwards.
Why it matters in production
Levels only help when they are used consistently. Do not log expected conditions, such as a client asking for a missing record, at ERROR, or real errors drown in noise and ERROR-rate alerts stop meaning anything. Pair levels with structured logging so the level is a field you can filter and count, and add a correlation ID so all the lines from one request can be found together.
See also
On the One2N blog
References
