From b7cecbb92948c4526818d50c4d68d2db0f6554b9 Mon Sep 17 00:00:00 2001 From: Michal Vanko Date: Fri, 18 Dec 2020 15:55:28 +0100 Subject: [PATCH] =?UTF-8?q?Create=20Blog=20=E2=80=9C2020-12-18-logging-rec?= =?UTF-8?q?ommendations=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../2020-12-18-logging-recommendations.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 _posts/blog/2020-12-18-logging-recommendations.md diff --git a/_posts/blog/2020-12-18-logging-recommendations.md b/_posts/blog/2020-12-18-logging-recommendations.md new file mode 100644 index 0000000..f9b827a --- /dev/null +++ b/_posts/blog/2020-12-18-logging-recommendations.md @@ -0,0 +1,96 @@ +--- +layout: blog +title: Logging recommendations +published: true +date: 2020-12-18T14:39:53.533Z +tags: + - Development + - Guide +--- +## Back-end + +### 1. Use a logger + +**Do not** use `console` directly. Programs should be able to define logging strategies dependant on the environment. +We strongly recommend using a logging library such as [Winston](https://github.com/winstonjs/winston) (commonly used in _node.js_ programs). + +Libraries should provide an easy way to choose a _transport_ which will be used as on output for logs. +Examples of transports: + +- File +- Console +- 3rd party monitoring tools (e.g: [loggly](https://www.loggly.com/)) + +### 2. Log levels + +You can set up as many log levels as needed. +_npm_ uses these 7: + +```json +{ + error: 0, + warn: 1, + info: 2, + http: 3, + verbose: 4, + debug: 5, + silly: 6 +} +``` + +These are sorted by priority and should be used appropriately. +What is logged depends on the environment(dev, test, prod...) in which the program operates. +_In the production environment, `debug` logs won't be displayed since they would cause a lot of unnecessary noise._ +_Verbose logs might be useful for staging environments where you want to see more information about what is happening in the system._ + +### 3. What to log + +It is very important to log all the information required for developers and DevOps to retrieve as much valuable information from the logs as possible. + +Messages are usually generated in a way where developers don't have to add things like timestamps, log levels, etc., and repeat themselves. +Timestamps and log levels are attached to the messages that are logged automatically. + +#### Errors + +Not every error should be logged. +Validation errors and expected errors such as handled errors +are common and they're expected to happen frequently, so they shouldn't interrupt the system in any way whatsoever. +Therefore they should not be seen in logs. They can be shown in the access logs. + +Unexpected errors should be logged with the highest priority (error). These errors should be monitored, prevented, and handled. + +#### System state changes + +Back-end apps strive to be stateless but they also do have some state like: + +- served endpoint, port +- database connection +- 3rd party integrations + +Changes in the system with valuable information should be logged with the `info` level. They serve as a great source of information about the system prior to the failure. + +#### Debug + +Don't be hesitant to use `debug` logs. They can always be turned off or turned on back again while debugging. +Most of the time developers tend to use `console.log` and then remove it before committing. +I'd encourage you to use `debug` level and leave it there. +It can be a big help in the future which can point you to the part of the code which is responsible for the manipulation of the data. + +### 4. Don't log sensitive information + +**Never, ever log credentials, passwords, or any sensitive information.** + +## Front-end + +Front-end logging is fundamentally different from the back-end. +There is a new instance of the program for every opened window and it is only opened for 1 particular client. +Developers should **not** expose the functionality to users. + +There is an _npm package_ [debug](https://www.npmjs.com/package/debug) that +enables developers to write debug logs that persist in the codebase. +To reveal the logs in the console they have to be enabled. + +There are 3rd party **error monitoring** services, that can help us collect information from errors that occur in different parts of the application. + +- [bugsnag](https://www.bugsnag.com/) +- [Sentry](https://sentry.io/welcome/)