Logging

​

Overview

OpenGB provides a powerful logging system to make sure you can pinpoint errors immediately in production.

​

Writing good logs

• Design for Debugging Write logs with the intention of making it easy to pinpoint the source of an issue. Explicilty log information that will make it easy to go back and identify issues quickly.
• Use Log Levels Log levels are helpful for quickly identifying the root cause of problems. Errors are for clear issues, warnings are for things that might be indicative of an issue, info is for notable events, debug is for detailed information useful during development, and trace is for used for pinpointing the exact flow of the program.
• Log Script-Specific Data Log information only relevant to the current script. Don’t worry about logging data as a response from other scripts; that log should be put in the script itself.
• Don’t Log Arrays & Objects Logging arrays & objects may be fine in development, but these objects frequently become large in production. For example, if logging a list of users, a single script may be returning hundreds of user rows at the same time. This is going to polute your logs. Instead, log aggregates like Fetching ${req.userIds.length} users and Returning ${users.length} users.
• Don’t Log Sensitive Information Don’t log things like tokens, passwords, or anything else that might be sensitive.

​

Reading logs

• Log Levels Filter logs by log level when diagnosing an issue. Start with errors and work down.
• Ray IDs All logs originating from the same request are grouped together. Filter logs by ray ID to find related logs.