Help with implementation

[BeRightBaack]

• PySeq version:
• Python version: Python 3.10.6
• Operating System: Ubuntu 22.04.1 LTS

Description

In my python FastAPI app i created loging config file that looks like this (now there are multiple instances of seq handler cause I was testing it out)

import logging
from logging.handlers import TimedRotatingFileHandler
from seqlog import structured_logging
import seqlog

logPath: str = './logs/log.log'

logging.basicConfig(
    handlers=[
        TimedRotatingFileHandler(logPath, when='midnight', interval=1, backupCount=30, encoding='utf-8')
        , structured_logging.SeqLogHandler(server_url='http://localhost:5341')
        , seqlog.SeqLogHandler(server_url='http://localhost:5341')
        , structured_logging.ConsoleStructuredLogHandler()
        #, logging.StreamHandler()
    ],
    level = logging.INFO,
    format = '%(asctime)s - %(name)s(%(lineno)d) - %(levelname)s - %(message)s',
    datefmt = '%d.%m.%Y %H:%M:%S'
)

logger = logging.getLogger(__name__)
logger.info('This is test')

At the start of my main.py this module is included to config logging

from modules.logging import loggingModel

Each module in my app has it's own logger Message from end of loggingModel.py file is sent to seq altough without format that is set in basic config, just plain message But all other log messages through app are not sent to seq

TimeRotatingFileHandler and even seqlog ConsoleStructuredHandler are working through entire app and log messages as expected ConsoleStructuredHandler TimeRotatingFileHandler

I'm not sure what am I doing wrong and how to fixit

What I Did

I tried to remove formatting, remove all other handlers expect seqlog, create handler with multiple different options, adding keys, json_encoders, nothing worked

[tintoy]

I suspect that this function's logic may be what's missing:

https://github.com/tintoy/seqlog/blob/226a3af4434628b076e343ac62f3ce48ff054891/seqlog/__init__.py#L216

[tintoy]

Or possibly this:

https://github.com/tintoy/seqlog/blob/226a3af4434628b076e343ac62f3ce48ff054891/seqlog/__init__.py#L110

[BeRightBaack]

Am I supposed to add this lines to my code? Or did I get it wrong?
I tried to add following lines to my loggingModel.py file

logging.setLoggerClass(structured_logging.StructuredLogger)
seqlog._override_root_logger()

But situation remains the same I do get additional info in that initial log message that is sent to seq (like logger name, thread,...)

But still without formatting and still messages from other parts of app are not logged Also tried to add same two lines of code to other modules that do the logging, but nothing changed And also tried to use commands one by one, testing with only setting logger class and testing with only overriding root logger, still no change

[tintoy]

Maybe we can try working backwards; is there a reason you're not just calling seqlog.log_to_seq()? That takes a list of additional handlers (although I'd suggest not adding more than one instance of the Seq log handler for now).

BTW, there are a couple of usage examples for it here that you may find useful.

[tintoy]

If you can't called log_to_seq() and want to set up logging directly, maybe try comparing the way that log_to_seq() calls logging.basicConfig() to your existing implementation.

[Vacant0mens]

@BeRightBaack, Maybe you can try setting up your config in a dict (you can read more about it here.) and use seqlog.configure_from_dict() or logging.config.dictConfig() or you can set up each handler object individually before calling basicConfig(). Separating out the handlers from the basicConfig() call would make it easier to debug the issue you're seeing (using breakpoints and whatnot in your IDE).

Initially, it seems like your SeqLogHandler just isn't using the format from your basicConfig() call. I believe the SeqLogHandler class uses the default formatter if you don't specify one. Or you can set it with: SeqLogHandler().setFormatter(custom_formatter).

If I read your initial post right, you said all of your modules are using different loggers? I'm still catching up on your use case, but is there a reason you set it up like that? Why not have one logging instance that you share between the modules?