Buffering logs in complex workloads with multiple logger instances

[leandrodamascena]

Hi @dreamorosi, I'm starting this discussion here so as not to pollute issues with a topic that doesn't necessarily belong there.

In Python, when a customer creates a Logger instance, we create a handler and a formatter and attach them to the instance. For new Logger instances with the same service_name, we create a object in memory for that Logger instance, but attach the same handler that was created previously, this way we ensure that all logging instances are using the same log formatter and methods, such as append_keys, which will work for both instances, because they are defined at the formatter level. This is our implementation of Logger and sometimes confused with the Singleton pattern, but it is not.

That said, the ideal world for complex workloads would be to create just one instance in a separate file and import it into all the files you need, so you literally have just one instance that will do everything you need.

The names are for illustration purposes only:

create_logger.py

from aws_lambda_powertools import Logger
logger = Logger(level="DEBUG", service_name="my_workload")

app.py

from create_logger import logger
from functions import my_function

@logger.inject_lambda_context
def lambda_handler(event, context):
    logger.info("Log 1")
    logger.debug("Log 2")

    my_function()

functions.py

from create_logger import logger

def my_function():
    logger.debug("My function")
    return "A"

But we know that customers are doing it differently, and that's completely fine, because we never know all the requirements that customers have, and our job is to provide the best experience for customers without making too many assumptions about their requirements. I know many customers, myself included in some workloads, who are creating multiple instances of Logger because we say that in our documentation:

app.py

from aws_lambda_powertools import Logger
from functions import my_function

logger = Logger(level="INFO")

@logger.inject_lambda_context
def lambda_handler(event, context):
    logger.info("Log 1")
    logger.debug("Log 2")

    my_function()

functions.py

from aws_lambda_powertools import Logger

logger = Logger(level="INFO")

def my_function():
    logger.debug("My function")
    return "A"

In this case, the Logger instance created in functions.py will create the initial handler and formatter and the Logger instance created in app.py will copy them. So far this has not created any problem because as we are attaching the formatter and handler to all Powertools Logger instances and customers are happy with it, but this brings a problem when it comes to buffer logs in Python.
We are creating a new BufferCache instance for each Logger instance and they are not sharing it across instances, so the buffer mechanism will not work for customers who want to buffer logs in complex workloads where Logger instances with the same service_name are created in many files and the customer wants to buffer logs across them. The way I'm solving this in Python is by creating a BufferCache instance only for the first log creation with a certain service_name and copying it for subsequent Logger instance creation with same service_name. In practical terms it would be:

app.py

from create_logger import logger
from functions import my_function # functions is being imported before creating a Logger instance here, so, it take precedence 

logger = Logger(level="INFO")

@logger.inject_lambda_context
def lambda_handler(event, context):
    logger.info("Log 1")
    logger.debug("Log 2")

    my_function()

functions.py

from aws_lambda_powertools import Logger
from aws_lambda_powertools.logging.buffer import LoggerBufferConfig

logger_buffer_config = LoggerBufferConfig(max_size=20480, minimum_log_level="DEBUG")
logger = Logger(level="INFO", logger_buffer=logger_buffer_config) # This is the valid buffer mechanism and will be copied to other instances

logger = Logger(level="INFO")

def my_function():
    logger.debug("My function")
    return "A"

I'm curious to know if you have the same issue in TypeScript and if so, how you're thinking of solving it.

Thanks and please let me know if anything is unclear here.

[dreamorosi]

In TypeScript we encourage the first pattern you shared, which is having a single logger instance and importing it from other modules. We don't have this in the documentation (we probably should), but we show this in our example app and workshop. Besides where we show it, that's the pattern I see the most whenever a I see customers using a logger (be it Powertools or others).

Because of this, the log buffering will work since it's always the same instance. If instead multiple logger instances are created, then they'll all have their own buffer, which is expected and not something I think we should solve in TypeScript.

Regarding the entire handler and formatter discussion, the internal implementation on our side is quite different, but just like the buffer pretty much anything needed by a logger instance lives within the instance and there's no limit/conflict in creating multiple copies. This is because we don't have a logging module in the standard library, which means we own the entire thing from API to stdout.

The only related case that I haven't tested is when creating a child logger, at least with the current design parent & child will have separate buffers - this is consistent with how child loggers work in our Logger: rather than children they're really independent clones. With that said, I don't know if the buffer should be shared or not.

[leandrodamascena]

Thanks @dreamorosi! Closing as resolved.