> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/devops1/monitoring/logging/logging_2.md). # Logging * Logging is everywhere * Helps maintain, and keep our programs up and running. * loggers rot at an unbelievable speed * After a while, we find ourselves fixing problems caused by loggers more often than the loggers give us useful information. * Code bloat * Memory bloat * Hard to find messages * Hard to link log messages ## What * Logging is the process of recording application actions and state to a secondary interface. * loggers don't belong to any particular layers of our systems. * Instead, we consider them to be application-wide and shared amongst different components. * cross cutting * logging itself is a subsystem within our application ## Issues * devs tend to focus on the format rather than the actual purpose of why we are writing logs. ## Rules * Don’t log * Overlogging is detrimental, too much noise to be helpful * Logging means more code to maintain, it incurs expense in terms of system performance, and more logging subjects us to more data privacy regulatory audits. * * * start without logging and work our way up to identify places where we need to log, rather than “log everywhere as we might need to look at them”. * rule of thumb for adding a line of logging is “if we can’t pin down an exact reason or a scenario when we will look at the log, don’t log". * Should be documented using tests ## Scenarios * catastrophic or unexpected scenarios that requires immediate action (like catastrophic errors that need an application restart) * Best to use alerting tools * logs give more context around what happened and possible cause * Just like the errors that they accompany, these logs should be kept to a minimum in our code and placed in a single location. They should also be designed/documented in the spec as a required system behavior for error handling. Also, they should be woven into the source code around where the error handling happens. * using log.error or log.fatal before a graceful shutdown and restart of the application. * attach the full error stack trace and the function or requests’ input data for reproduction if necessary. * addresses expected, handled errors like network issues and user input validation * only requires developers’ attention if there’s an anomaly with them. * Together with a monitor set up to alert developers upon an error, these logs are handy to mitigate potential serious infrastructure or security problems * making “visible” for developers, log.warn or log.error can be used * Log that should appear most often in our source code – but it's often the most difficult to get right * those associated with the “happy” steps of our applications, indicating the success of operations. * often abused by developers * indicating starting/successful execution operations in our system - interacttions with other apps (req/resp) - who accesses the app * log.info * need to pass the litmus test: are there any circumstances under which we would look at the log (be it a customer support request, an external auditor’s inquiry)? ## Cleaning up logs * first step is to identify where the criminals are hiding * A document (or spreadsheet if you would like to be organised) * weed out the bad apples * Logs which are duplicated or unreachable are low hanging fruits that we can immediately eliminate from our source code. * others should involve stakeholders * urning them into technical requirements with documented purpose for each one of them is essential to nail down a contract * Ask yourself what to do when a log.error happens, and who are we log.info-ing for? *