Though we want to add the ability to emit logs in the format that's most useful for engineers (see #111), we also want to promote a standard logging format to reduce the cognitive overhead of switching between projects and provide the ability to more-easily search for logs that span multiple services.
The idea would be that instead of encouraging engineers to reference a format-specific class in their logging configuration (e.g. dockerflow.logging.MozlogHandler or google.cloud.logging.handlers.StructuredLogHandler), we can establish a generic class name like:
'console': {
'class': 'dockerflow.logging.DefaultHandler', #real name tbd
},
with some sort of ability to configure the class through an environment variable, like:
os.getenv("DOCKERFLOW_LOGGING_FORMAT", "MOZLOG")
With this setup, engineers have the freedom to:
accept the default format of DefaultHandler as the "current logging format standard of Mozilla".
maintainers of this library can change the format of DefaultHandler in accordance with the current logging standard of Mozilla, and if engineers only care about aligning with Mozilla's standard logging format, they'll automatically be compliant with the standard when they update this library
override the standard format to another commonly used format through environment configuration, like
export DOCKERFLOW_LOGGING_FORMAT=GCP
still (of course) have the ability to fully customize their logging setup by referencing specific logging handlers, formatters, and filters
Though we want to add the ability to emit logs in the format that's most useful for engineers (see #111), we also want to promote a standard logging format to reduce the cognitive overhead of switching between projects and provide the ability to more-easily search for logs that span multiple services.
The idea would be that instead of encouraging engineers to reference a format-specific class in their logging configuration (e.g.
dockerflow.logging.MozlogHandler
orgoogle.cloud.logging.handlers.StructuredLogHandler
), we can establish a generic class name like:with some sort of ability to configure the class through an environment variable, like:
With this setup, engineers have the freedom to:
DefaultHandler
as the "current logging format standard of Mozilla".DefaultHandler
in accordance with the current logging standard of Mozilla, and if engineers only care about aligning with Mozilla's standard logging format, they'll automatically be compliant with the standard when they update this library