Pour mon exemple, je ne vais considérer que l'API proposée par SLF4J qui a un niveau de log en moins que celle de Log4j2 (le fatal) mais qui, à mon sens, ne sert à rien puisque logger le fait qu'une application se soit crashée est stupide... Puisqu'on le verra immédiatement qu'elle se soit arrêtée.

Reprenons :

ERROR
À ce niveau de log, il faut enregistrer les actions qui n'ont pas pu aboutir (typiquement une exception). Il faut savoir qu'une succession d'actions n'ayant pas abouties conduit en général à un crash applicatif, d'où le niveau error.

WARNING
À ce niveau de log, il faut enregistrer les événements qui sont incohérents mais vis-à-vis desquels l'application a pu retomber sur ses pâtes et donc poursuivre le traitement. Une succession de warnings trop importante engendre en général une erreur.

INFO
À ce niveau de log, il faut enregistrer l'activité des utilisateurs. Il ne s'agit pas de logs contenant l'état de l'application en elle-même mais ce que les utilisateurs ont essayé de faire avec l'application.

DEBUG
À ce niveau de log, il faut enregistrer l'activité technique de l'application (enregistrement sur le disque, ouverture/fermeture des connexions à la base, etc). Ce niveau de logs est à destination des admin-sys exclusivement pour leur permettre d'identifier un problème de configuration / comportement.

TRACE
À ce niveau de log, il faut enregistrer l'activité algorithmique de l'application, typiquement comment se comporte la mémoire, les threads, la création des objets, la validation / invalidation de contrôles conditionnels (if-else). Ce niveau est à destination des développeurs et uniquement eux pour leur permettre d'identifier l'origine d'un bug en production.