airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maycock, Luke" <>
Subject Re: Airflow Logging
Date Fri, 14 Oct 2016 14:43:03 GMT
Carrying on from the below. We believe it would be useful to have a number of additional configuration
options for logs as below. Do you think there are any important options we have missed or
do you have any other feedback? If so, please let us know.


Clears any handlers, inherited from the root logger, from the Airflow logger object and its


Turn on/off logging of all events to a file.

Turn on/off the logging of all errors to a file.

Turn on/off the logging of all events to the console.

Per log file
The Python logging library, being used for logging in the Airflow code, has the ability to
rotate log files based on time:

•         TimedRotatingFileHandler - (
- rotates based on the product of when and interval (see below).

The TimedRotatingFileHandler takes the following arguments:

 *   Filename – the filename
 *   When – used to specify the type of interval
 *   Interval – defines the interval
 *   BackupCount - If backupCount is nonzero, at most backupCount files will be kept, and
if more would be created when rollover occurs, the oldest one is deleted. The deletion logic
uses the interval to determine which files to delete, so changing the interval may leave old
files lying around.
 *   Encoding - if encoding is not ‘None’, it is used to open the file with that encoding.
 *   Delay - if delay is true, then file opening is deferred until the first call to emit()
– I don’t think this is suitable to expose as an Airflow configuration option.
 *   UTC - if the UTC argument is true, times in UTC will be used; otherwise local time is
I believe all of the above, except ‘delay’, should be exposed as Airflow configuration.

Luke Maycock

From: Maycock, Luke
Sent: 13 October 2016 14:52
Subject: Airflow Logging

Hi All,

We (owlabs - fork: have a high level design for
how to improve the logging throughout the Airflow code to be more consistent, maintainable
and extensible. We'd really appreciate any feedback on the design.

Design for Consolidating Logging Setup:

 *   Create a Class in the utils\ to instantiate and handle setup of an "airflow"
logger object. This allows us to easily find all setup code for further modification and extension
in the future.
 *   This class would be where any general logging configuration (from Airflow.cfg) would
be applied.
 *   Instantiate this class in this file, so that importing it allows easy control of the
logging setup from anywhere else in the application.
 *   Move all setup of the logging in general to this class with easy to call control methods
to turn forms of logging on and off (e.g. console/debugFile/errorFile).
 *   Move any other helper functions related to logging that are still required into the utils\
so that we can easily find them for modification and extension in the future.
 *   Ensure that all logging throughout the application is done via the "airflow" logger object,
or by a child of this logger object. This allows us to:
    *   Leave all settings of the root logger object alone, so that we are friendly to any
parent or child processes that are not part of the application, allowing them to safely manage
their own overriding logging setup.
    *   Modify the settings of logging throughout the entire application via a single simple
point of control.

Luke Maycock

This e-mail and any attachments may be confidential or legally privileged. If you received
this message in error or are not the intended recipient, you should destroy the e-mail message
and any attachments or copies, and you are prohibited from retaining, distributing, disclosing
or using any information contained herein. Please inform us of the erroneous delivery by return
e-mail. Thank you for your cooperation.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message