Do not log
Logging is an important aspect of any software system. This post focuses on the perils of logging and proposes better ways of achieving end results. Although the author uses Haskell for examples, the principles are global.
- Using logs to monitor production systems is a fallacy. Use of better error tracking and monitoring products like Prometheus or Sentry to track business metrics leads to better systems. If the business metric isn't affected, does it matter that an error occurred?
- Logging is a side effect that can also fail. The juice is not worth the squeeze.
- Storing and Grepping through logs in a centralized location is a sub-system on its own. It's one more failure point in your architecture design.
- Any error log should include the complete business context of the object or activity that failed. Simply logging "Error occurred" is futile. Better error logging leads to the reproducibility of the error by the engineering team.
I think logging is a very nuanced subject that takes years for teams to understand and coalesce around. Good logging principles are not born but carefully farmed within a team through many years of trial and error.
Full post here, 11 mins read