Logging in module or application¶

Overview¶

Logging is a base library that support create logging handler that can use for component

Why we need logging¶

For more component

Level of LOG

flowchart LR
    logging_level[Logging Level]
    logging_level --> debug[DEBUG]
    logging_level --> info[INFO]
    logging_level --> critical[CRITICAL]
    logging_level --> error[ERROR]
    logging_level --> warning[WARNING]

For debug

Because when we deployed in other environment, it's hard to communication or go back on what happend?

Some question that alway work with logging

Configuration¶

There are 3 basic type of method of configuration ¹

flowchart LR
lc[logging.config method]
lc --> d[dictConfig] --> dm[Using JSON to declare schema] --> dr[Can use json package read]
lc --> f[fileConfig] --> fm[Using logging.ini to declare schema] --> fr[Use configparser to read]
lc --> l[listen] --> s[Socket Mode]
lc --> k[stopListening] --> s
s --> o[Handle in raw test on the script]

The method with dict or file is familar together and can switch. But from the note of element, there are various differnt which the lower API in the backend.

Note The fileConfig() API is older than the dictConfig() API and does not provide functionality to cover certain aspects of logging. For example, you cannot configure Filter objects, which provide for filtering of messages beyond simple integer levels, using fileConfig(). If you need to have instances of Filter in your logging configuration, you will need to use dictConfig(). Note that future enhancements to configuration functionality will be added to dictConfig(), so it’s worth considering transitioning to this newer API when it’s convenient to do so.

Formatter¶

Formatter instances are used to convert a LogRecord to text.

Formatters need to know how a LogRecord is constructed. They are responsible for converting a LogRecord to (usually) a string which can be interpreted by either a human or an external system. The base Formatter allows a formatting string to be specified. If none is supplied, the style-dependent default value, "%(message)s", "{message}", or "${message}", is used.

The Formatter can be initialized with a format string which makes use of
knowledge of the LogRecord attributes - e.g. the default value mentioned
above makes use of the fact that the user's message and arguments are pre-
formatted into a LogRecord's message attribute. Currently, the useful
attributes in a LogRecord are described by:

%(name)s            Name of the logger (logging channel)
%(levelno)s         Numeric logging level for the message (DEBUG, INFO,
                    WARNING, ERROR, CRITICAL)
%(levelname)s       Text logging level for the message ("DEBUG", "INFO",
                    "WARNING", "ERROR", "CRITICAL")
%(pathname)s        Full pathname of the source file where the logging
                    call was issued (if available)
%(filename)s        Filename portion of pathname
%(module)s          Module (name portion of filename)
%(lineno)d          Source line number where the logging call was issued
                    (if available)
%(funcName)s        Function name
%(created)f         Time when the LogRecord was created (time.time()
                    return value)
%(asctime)s         Textual time when the LogRecord was created
%(msecs)d           Millisecond portion of the creation time
%(relativeCreated)d Time in milliseconds when the LogRecord was created,
                    relative to the time the logging module was loaded
                    (typically at application startup time)
%(thread)d          Thread ID (if available)
%(threadName)s      Thread name (if available)
%(process)d         Process ID (if available)
%(message)s         The result of record.getMessage(), computed just as
                    the record is emitted

Example¶

Reference¶

Official Logging Configuration ↩