Debugging: Log Levels
I'm a community-minded engineer based in Berlin, originally from Romania, and I grew up in sunny Spain. I combine the best of both communication and technical skills, with experience in both the engineering world and the business side of things. I'm proficient in a wide range of technologies like JavaScript, React.js, Redux, TypeScript, Node.js, HTML/CSS, Styled Components, SASS, and REST APIs. I love going beyond just writing code by sharing knowledge with my team through Communities of Practice (COPs), Employee Resource Groups (ERGs), and detailed technical documentation. My main interests are in frontend frameworks, web standards, accessibility (A11y), and Clean Code. My passion for programming started in high school when I built my first website. Since 2019, I've been working as a professional software developer, thriving in agile and iterative environments. Nearly five years later, I'm still excited to dive into code and collaborate with my colleagues. I'm very open and friendly, good at turning technical concepts into easy-to-understand information for everyone.
Understanding why something is failing is crucial to finding a solution and improving our application's performance, code quality, and so on...
How often have you found yourself debugging a service that is down, encountering troubles, or not receiving/requesting some information you are supposed to have/get?
To resolve stoppers, we will have to check the logs.
These are crucial for finding the root cause of the bug and proposing a solution. So here are some insights on how to read them.
First, we have different levels (or logs labelled in this way):
Trace: The lowest level, providing the most detailed information about the execution flow of the application. Used to trace the execution path of various components. Tracing code and trying to find one part of a function.
Debug: General information for troubleshooting in production environments. For IT system admins or developers, these logs are more verbose than Trace logs.
Info: Generally useful information to log (service start/stop, configuration assumptions, etc.). Information is always available but not too important. “Out-of-the-box” config level.
Warn: Indicates potential issues but nothing too critical, but may require some attention.
Error: Any error that is fatal to the operation but not the service or application (can’t open a required file, missing data, etc.). Error logs indicate that an unexpected error or exception has occurred during the execution of the application.
Critical: Any error that is forcing a shutdown of the service or application to prevent data loss (or further data loss), such as system crashes or unrecoverable errors.
You could also add “critical” between Error and Fatal.
It depends on where your service is running and what you are debugging.
Let’s imagine you have Traefik working on a docker container that mounts a website.
To debug (Traefik has its infrastructure for it sure), let’s focus on the logs of a container.
Understanding the logs is what will make you go to the next level.
It’s like a really good detective trying to solve a case but now he has lots of kinds of clues.
Good seniors are great at this. I did not write logs yet, but I do get to work with them, and it is quite interesting to understand them.
Here’s a really good resource to get a final grasp on it:
