This lesson's interactive features are locked, please to keep using them
Best Practices
Logging is often taken for granted. We all want useful logs when something goes wrong, but while writing new code, it's easy to forget about logging.
Let's be better.
Click to play video
Who Are Logs For?
Logs serve different purposes depending on who is reading them.
Think about the last time you looked at logs for a program you didn't write. How did you approach them differently from logs for a program you did write?
It's always easier to understand logs for a program you wrote, because you have full context. Good logging practices ensure that others can understand your logs too. Examples include:
- Developers: (You and your team) the folks who build the software
- Operations: (SREs or Ops engineers) the folks who install and run the software
- Customer Support: the folks who help customers directly
- Customers / End-Users: the folks who use the software
- Auditors: the folks who ensure compliance with regulations
In this course, we'll focus on creating good logs for developers and operators – the most common readers in backend applications.
What Makes Good Logs?
Developers and operators typically read logs when something goes wrong. They want to understand what happened and why it happened. As such, valuable logs tend to be:
- Discoverable: Easy to find, access, and search.
- Clear: Easy to read, parse, and understand.
- Specific: "File not found" isn't very specific... What file? What function failed? Did the underlying syscall return an error?
- Contextual: Which handler produced the error? Which user made the request? What permissions did they have?
- Privacy-sensitive: Logs should not include passwords, credit card numbers, or other personally identifiable information (PII). Better to log IDs than emails.