|
1 | 1 | # How to use the logging framework |
2 | 2 | Al our services runs in GCP. To get the best out of the log traces, we should use a common pattern acrosss all functions and services. This documents describes how to use the shared logging functions. |
3 | 3 |
|
| 4 | +## General guidances |
| 5 | + |
| 6 | +- Parameters instead of string interpolation |
| 7 | + |
| 8 | +Use log parameters instead of string interpolation. String interpolation always creates a string concatenation even if the log is not send due to the environment log level settings. |
| 9 | +Example: |
| 10 | +``` |
| 11 | +# Avoid string interpolation. |
| 12 | +logging.info(f"Total of feeds: {total}") |
| 13 | +
|
| 14 | +# Use this optimized version |
| 15 | +logging.info(f"Total of feeds: %s", total) |
| 16 | +``` |
| 17 | + |
| 18 | +- Use logging levels properly |
| 19 | +By default the logging level the functions are set to INFO. |
| 20 | +Avoid to log unnecessary or repetitive information in INFO level. It might make sense to log every single message in a loop; this can be overwhelming in production. |
| 21 | +Use info, warning and debug levels wisely. |
| 22 | + |
| 23 | +- Logging a dictionary or json |
| 24 | +When logging a dictionary or JSON use a field named "message" to be able to easily spot the record on the GCP Log Explorer. Example: |
| 25 | +```python |
| 26 | +dict = { |
| 27 | + "message": "This will be visible in the log explorer without expanding the record", |
| 28 | + "single_field": "my value", |
| 29 | + "another_dictionary": { |
| 30 | + "internal": "value1" |
| 31 | + } |
| 32 | +} |
| 33 | +logging.info(dict) |
| 34 | +``` |
| 35 | + |
| 36 | +- Log main function reponse |
| 37 | +This is necessary in cases that we would like to get the response in the logs as GCP doesn't log the responses by default. |
| 38 | + |
| 39 | +## API implementation |
| 40 | +The API logging is based in a custom GCP Logging filter. This is necessary as the GCP internal mechanism is based on Flask, not fully compatible with our FastApi in terms of to stackdriver(cloud logging) compatibility. |
| 41 | + |
| 42 | +The logging context is already inittialized when the application starts. |
| 43 | +To log messages use the standard logging library. Example: |
| 44 | +```python |
| 45 | +import logging |
| 46 | + |
| 47 | +logging.info("This message is awesome") |
| 48 | +``` |
| 49 | + |
4 | 50 | ## Python functions |
5 | 51 |
|
6 | 52 | ### Logging level |
@@ -32,17 +78,4 @@ There are two ways to log messages: |
32 | 78 |
|
33 | 79 | logger = logging.get_logger("my logger name", "mdb-001") |
34 | 80 | logging.info("Total feeds: %s", total_feeds) # This will output the following format for total_feeds equals to 10: [mdb-001] Total feeds: 10 |
35 | | -
|
36 | | -``` |
37 | | - |
38 | | -Use log parameters instead of string interpolation. String interpolation always creates a string concatenation even if the log is not send due to the environment log level settings. |
39 | | -Example: |
40 | 81 | ``` |
41 | | -# Avoid string interpolation. |
42 | | -logging.info(f"Total of feeds: {total}") |
43 | | -
|
44 | | -# Use this optimized version |
45 | | -logging.info(f"Total of feeds: %s", total) |
46 | | -``` |
47 | | - |
48 | | - |
|
0 commit comments