structlog: add structlog logger factory#75
structlog: add structlog logger factory#75jrcastro2 wants to merge 1 commit intoinveniosoftware:masterfrom
Conversation
| from logging import StreamHandler | ||
| import sys | ||
|
|
||
| class LoggerFactory: |
There was a problem hiding this comment.
Not clear how all this is used, it would be nice to see an example.
It feels like that the class is not needed, but a simple func is enough.
There was a problem hiding this comment.
Right! Once I push to the vocabularies PR and it's ready to review we will see it there, but basically we can use it by simply doing:
stream_logger = LoggerFactory.get_logger("datastreams-" + stream)
stream_logger.info("Starting processing")
stream_logger.error(...)
stream_logger.exception(...)Yes, we could change it to be simply a func that returns the logger if it's better.
| """ | ||
| Retrieves a configured logger with the specified name. | ||
|
|
||
| Args: |
There was a problem hiding this comment.
are we introducing a new format for docstrings? it is a first time I see it, I think
There was a problem hiding this comment.
My bad, we are using the :param in invenio, I will keep it in mind, it's copilot who is generating this 😅
slint
left a comment
slint
left a comment
There was a problem hiding this comment.
Some minor comments on the docstrings/methods and usage.
On a side note, maybe we rushed a bit with the task for adding structured logs (doesn't matter that it's structlog specifically). I see also @ntarocco's question on what the end-usage will look like, and after reading through the docs a bit, I think we have to make it clear that we use structlog to help us:
- render structured logs in JSON format
- possibly take advantage of features like Context Variables to improve observability/tracing throughout actions that happen in the application
- overall be a bit more conscious and intentional about logging as a feature
So just to clarify, I'm not saying we shouldn't do a small minimal step towards logging, but we have to be careful on the design so that we're moving in the right direction, because I see from structlog docs this can become a very powerful feature if done right :)
| Returns: | ||
| structlog.BoundLogger: The configured logger. |
There was a problem hiding this comment.
I think this should be something like :returns: ... and :rtype: ....
| def get_logger(name=None, level=logging.INFO, handler=None, processors=None): | ||
| """ | ||
| Retrieves a configured logger with the specified name. | ||
|
|
||
| :param name (str): The name of the logger. If not provided, a root logger will be used. | ||
| :param level (int): The logging level. Defaults to logging.INFO. | ||
| :param handler (logging.Handler): The logging handler to use. If not provided, a StreamHandler with stdout will be used. | ||
| :param processors (list): The list of structlog processors to apply. If not provided, a default set of processors will be used. |
There was a problem hiding this comment.
nit: Do we need both get_logger and configure_logging, since this one just passes around the same parameters to the other?
I'm also somewhat skeptical about having docstrings at all at this point, since we're basically documenting what structlog accepts, in which case I would just point to the structlog docs.
|
|
||
| class LoggerFactory: | ||
| @staticmethod | ||
| def configure_logging( |
There was a problem hiding this comment.
comment/question: maybe another way to integrate would be to follow the structlog guides for specific frameworks like e.g. Flask and Celery. Especially for Celery that will really allow us to track individual tasks/jobs (though we'll need some central attribute/key to be able to group things logically).
4 participants
No description provided.