logging.config —ログ設定
ソースコード: :source: `Lib / logging / config.py`
重要
このページには、参照情報のみが含まれています。 チュートリアルについては、を参照してください
このセクションでは、ロギングモジュールを構成するためのAPIについて説明します。
構成機能
次の関数は、ロギングモジュールを構成します。 それらは logging.config モジュールにあります。 これらの使用はオプションです。これらの関数を使用するか、メインAPI( logging 自体で定義)を呼び出し、 logging または logging.handlers 。
- logging.config.dictConfig(config)
ディクショナリからロギング構成を取得します。 この辞書の内容は、以下の構成辞書スキーマで説明されています。
構成中にエラーが発生した場合、この関数は ValueError 、 TypeError 、 AttributeError 、または ImportError を適切な説明メッセージとともに生成します。 以下は、エラーを発生させる条件の(おそらく不完全な)リストです。
文字列ではない、または実際のログレベルに対応していない文字列である
level
。ブール値ではない
propagate
値。対応する宛先がないID。
インクリメンタル呼び出し中に存在しないハンドラーIDが見つかりました。
無効なロガー名。
内部または外部オブジェクトに解決できない。
解析は
DictConfigurator
クラスによって実行されます。このクラスのコンストラクターには、構成に使用されるディクショナリが渡され、configure()
メソッドがあります。 logging.config モジュールには、呼び出し可能な属性dictConfigClass
があり、最初はDictConfigurator
に設定されています。dictConfigClass
の値を、独自の適切な実装に置き換えることができます。dictConfig()は、指定されたディクショナリを渡して
dictConfigClass
を呼び出し、次に返されたオブジェクトでconfigure()
メソッドを呼び出して、構成を有効にします。def dictConfig(config): dictConfigClass(config).configure()
たとえば、
DictConfigurator
のサブクラスは独自の__init__()
でDictConfigurator.__init__()
を呼び出し、後続のconfigure()
呼び出しで使用できるカスタムプレフィックスを設定できます。dictConfigClass
はこの新しいサブクラスにバインドされ、 dictConfig()は、デフォルトのカスタマイズされていない状態とまったく同じように呼び出すことができます。バージョン3.2の新機能。
- logging.config.fileConfig(fname, defaults=None, disable_existing_loggers=True)
configparser 形式のファイルからログ構成を読み取ります。 ファイルの形式は、構成ファイルの形式で説明されているとおりにする必要があります。 この関数は、アプリケーションから数回呼び出すことができ、エンドユーザーがさまざまな事前に用意された構成から選択できるようにします(開発者が選択肢を提示し、選択した構成をロードするメカニズムを提供する場合)。
- パラメーター
fname –ファイル名、ファイルのようなオブジェクト、または RawConfigParser から派生したインスタンス。
RawConfigParser
から派生したインスタンスが渡されると、そのまま使用されます。 それ以外の場合は、Configparser
がインスタンス化され、fname
で渡されたオブジェクトから構成が読み取られます。 それが readline()メソッドを持っている場合、それはファイルのようなオブジェクトであると見なされ、 read_file()を使用して読み取られます。 それ以外の場合は、ファイル名と見なされ、 read()に渡されます。defaults –ConfigParserに渡されるデフォルトをこの引数で指定できます。
disable_existing_loggers –
False
として指定されている場合、この呼び出しが行われたときに存在するロガーは有効のままになります。 デフォルトはTrue
です。これは、下位互換性のある方法で古い動作を有効にするためです。 この動作は、既存の非ルートロガーまたはその祖先がロギング構成で明示的に指定されていない限り、それらを無効にすることです。
バージョン3.4で変更: RawConfigParser のサブクラスのインスタンスが、
fname
の値として受け入れられるようになりました。 これにより、次のことが容易になります。ロギング構成がアプリケーション構成全体の一部にすぎない構成ファイルの使用。
ファイルから読み取られ、使用するアプリケーションによって変更された構成の使用(例:
fileConfig
に渡される前に、コマンドラインパラメータまたはランタイム環境の他の側面に基づいて)。
- logging.config.listen(port=DEFAULT_LOGGING_CONFIG_PORT, verify=None)
指定されたポートでソケットサーバーを起動し、新しい構成をリッスンします。 ポートが指定されていない場合、モジュールのデフォルトの
DEFAULT_LOGGING_CONFIG_PORT
が使用されます。 ロギング構成は、 dictConfig()または fileConfig()による処理に適したファイルとして送信されます。 start()を呼び出してサーバーを起動でき、必要に応じて join()できる Thread インスタンスを返します。 サーバーを停止するには、 stopListening()を呼び出します。verify
引数は、指定されている場合、ソケットを介して受信されたバイトが有効であり、処理される必要があるかどうかを検証する呼び出し可能である必要があります。 これは、verify
呼び出し可能オブジェクトが署名の検証および/または復号化を実行できるように、ソケットを介して送信されるものを暗号化および/または署名することによって行うことができます。verify
呼び出し可能オブジェクトは、単一の引数(ソケットを介して受信したバイト)で呼び出され、処理するバイトを返すか、None
でバイトを破棄する必要があることを示します。 返されるバイトは、渡されたバイトと同じである可能性があります(例: 検証のみが行われる場合)、または完全に異なる可能性があります(おそらく復号化が実行された場合)。構成をソケットに送信するには、構成ファイルを読み込み、
struct.pack('>L', n)
を使用してバイナリでパックされた4バイトの長さの文字列が前に付いた一連のバイトとしてソケットに送信します。ノート
構成の一部は eval()を介して渡されるため、この関数を使用すると、ユーザーがセキュリティリスクにさらされる可能性があります。 この関数は
localhost
のソケットにのみバインドするため、リモートマシンからの接続を受け入れませんが、 listen()[を呼び出すプロセスのアカウントで信頼できないコードが実行される可能性があるシナリオがあります。 X224X]。 具体的には、 listen()を呼び出すプロセスが、ユーザーが相互に信頼できないマルチユーザーマシンで実行されている場合、悪意のあるユーザーは、被害者の listen()ソケットと、攻撃者が被害者のプロセスで実行したいコードを実行する構成を送信します。 これは、デフォルトのポートが使用されている場合は特に簡単ですが、別のポートが使用されている場合でも難しくはありません。 これが発生するリスクを回避するには、 listen()のverify
引数を使用して、認識されない構成が適用されないようにします。バージョン3.4で変更:
verify
引数が追加されました。ノート
既存のロガーを無効にしない構成をリスナーに送信する場合は、構成にJSON形式を使用する必要があります。これは、構成に dictConfig()を使用します。 この方法では、送信する構成で
disable_existing_loggers
をFalse
として指定できます。
- logging.config.stopListening()
- listen()の呼び出しで作成されたリスニングサーバーを停止します。 これは通常、 listen()からの戻り値で
join()
を呼び出す前に呼び出されます。
構成辞書スキーマ
ロギング構成を説明するには、作成するさまざまなオブジェクトとそれらの間の接続をリストする必要があります。 たとえば、「console」という名前のハンドラーを作成してから、「startup」という名前のロガーがそのメッセージを「console」ハンドラーに送信すると言うことができます。 これらのオブジェクトは、 logging モジュールによって提供されるオブジェクトに限定されません。これは、独自のフォーマッターまたはハンドラークラスを作成する場合があるためです。 これらのクラスのパラメータには、sys.stderr
などの外部オブジェクトを含める必要がある場合もあります。 これらのオブジェクトと接続を記述するための構文は、以下のオブジェクト接続で定義されています。
辞書スキーマの詳細
dictConfig()に渡される辞書には、次のキーが含まれている必要があります。
- version -スキーマバージョンを表す整数値に設定されます。 現在有効な値は1のみですが、このキーを使用すると、下位互換性を維持しながらスキーマを進化させることができます。
他のすべてのキーはオプションですが、存在する場合は、以下のように解釈されます。 「configuringdict」が言及されている以下のすべての場合において、カスタムインスタンス化が必要かどうかを確認するために特別な'()'
キーがチェックされます。 その場合、以下のユーザー定義オブジェクトで説明されているメカニズムを使用してインスタンスを作成します。 それ以外の場合は、インスタンス化する対象を決定するためにコンテキストが使用されます。
formatters -対応する値は、各キーがフォーマッターIDであり、各値が対応する Formatter インスタンスの構成方法を説明するdictであるdictになります。
構成辞書は、キー
format
およびdatefmt
(デフォルトはNone
)を検索し、これらを使用して Formatter インスタンスを構築します。バージョン3.8で変更: a
validate
キー(デフォルトはTrue
)を構成辞書のformatters
セクションに追加できます。フォーマットを検証します。filters -対応する値は、各キーがフィルターIDであり、各値が対応するFilterインスタンスの構成方法を説明するdictであるdictになります。
構成辞書でキー
name
(デフォルトは空の文字列)が検索され、これを使用して logging.Filter インスタンスが作成されます。handlers -対応する値は、各キーがハンドラーIDであり、各値が対応するHandlerインスタンスの構成方法を説明するdictであるdictになります。
構成辞書で次のキーが検索されます。
class
(必須)。 これは、ハンドラークラスの完全修飾名です。level
(オプション)。 ハンドラーのレベル。formatter
(オプション)。 このハンドラーのフォーマッターのID。filters
(オプション)。 このハンドラーのフィルターのIDのリスト。
すべての other キーは、キーワード引数としてハンドラーのコンストラクターに渡されます。 たとえば、スニペットが与えられた場合:
handlers: console: class : logging.StreamHandler formatter: brief level : INFO filters: [allow_foo] stream : ext://sys.stdout file: class : logging.handlers.RotatingFileHandler formatter: precise filename: logconfig.log maxBytes: 1024 backupCount: 3
ID
console
のハンドラーは、sys.stdout
を基になるストリームとして使用して、 logging.StreamHandler としてインスタンス化されます。 IDfile
のハンドラーは、キーワード引数filename='logconfig.log', maxBytes=1024, backupCount=3
を使用して logging.handlers.RotatingFileHandler としてインスタンス化されます。loggers -対応する値は、各キーがロガー名であり、各値が対応するLoggerインスタンスの構成方法を説明するdictであるdictになります。
構成辞書で次のキーが検索されます。
level
(オプション)。 ロガーのレベル。propagate
(オプション)。 ロガーの伝搬設定。filters
(オプション)。 このロガーのフィルターのIDのリスト。handlers
(オプション)。 このロガーのハンドラーのIDのリスト。
指定されたロガーは、指定されたレベル、伝播、フィルター、およびハンドラーに従って構成されます。
root -これはルートロガーの構成になります。
propagate
設定が適用されないことを除いて、構成の処理は他のロガーと同じです。増分-構成を既存の構成の増分として解釈するかどうか。 この値のデフォルトは
False
です。これは、指定された構成が既存の構成を、既存の fileConfig() APIで使用されるのと同じセマンティクスに置き換えることを意味します。指定した値が
True
の場合、インクリメンタル構成のセクションで説明されているように構成が処理されます。disable_existing_loggers -既存の非ルートロガーを無効にするかどうか。 この設定は、 fileConfig()の同じ名前のパラメーターを反映しています。 存在しない場合、このパラメーターはデフォルトで
True
になります。 インクリメンタルがTrue
の場合、この値は無視されます。
インクリメンタル構成
インクリメンタル構成に完全な柔軟性を提供することは困難です。 たとえば、フィルターやフォーマッターなどのオブジェクトは匿名であるため、構成がセットアップされると、構成を拡張するときにそのような匿名オブジェクトを参照することはできません。
さらに、構成がセットアップされると、実行時にロガー、ハンドラー、フィルター、フォーマッターのオブジェクトグラフを任意に変更する説得力のあるケースはありません。 ロガーとハンドラーの詳細度は、レベル(およびロガーの場合は伝播フラグ)を設定するだけで制御できます。 マルチスレッド環境では、オブジェクトグラフを安全な方法で任意に変更することは問題があります。 不可能ではありませんが、実装に追加する複雑さの価値はありません。
したがって、構成dictのincremental
キーが存在し、True
の場合、システムはformatters
およびfilters
エントリを完全に無視し、処理のみを行います。 handlers
エントリのlevel
設定、およびloggers
およびroot
エントリのlevel
およびpropagate
設定。
構成dictで値を使用すると、構成をpickle化されたdictとしてネットワーク経由でソケットリスナーに送信できます。 したがって、長時間実行されるアプリケーションのロギングの詳細度は、アプリケーションを停止して再起動する必要なしに、時間の経過とともに変更できます。
オブジェクト接続
スキーマは、オブジェクトグラフで相互に接続されている一連のロギングオブジェクト(ロガー、ハンドラー、フォーマッター、フィルター)を記述します。 したがって、スキーマはオブジェクト間の接続を表す必要があります。 たとえば、構成が完了すると、特定のロガーが特定のハンドラーをアタッチしたとします。 この説明では、ロガーは2つの接続のソースを表し、ハンドラーは宛先を表すと言えます。 もちろん、構成されたオブジェクトでは、これはハンドラーへの参照を保持するロガーによって表されます。 構成辞書では、これは、各宛先オブジェクトにそれを明確に識別するIDを与え、ソースオブジェクトの構成内のIDを使用して、そのIDを持つソースオブジェクトと宛先オブジェクトの間に接続が存在することを示すことによって行われます。
したがって、たとえば、次のYAMLスニペットについて考えてみます。
formatters:
brief:
# configuration for formatter with id 'brief' goes here
precise:
# configuration for formatter with id 'precise' goes here
handlers:
h1: #This is an id
# configuration of handler with id 'h1' goes here
formatter: brief
h2: #This is another id
# configuration of handler with id 'h2' goes here
formatter: precise
loggers:
foo.bar.baz:
# other configuration for logger 'foo.bar.baz'
handlers: [h1, h2]
(注:YAMLは、辞書の同等のPythonソースフォームよりも少し読みやすいため、ここで使用されています。)
ロガーのIDは、それらのロガーへの参照を取得するためにプログラムで使用されるロガー名です。 foo.bar.baz
。 フォーマッターとフィルターのIDは、任意の文字列値(上記のbrief
、precise
など)にすることができ、構成ディクショナリの処理にのみ意味があり、接続の決定に使用されるという点で一時的です。オブジェクト間であり、構成呼び出しが完了したときにどこにも永続化されません。
上記のスニペットは、foo.bar.baz
という名前のロガーに2つのハンドラーをアタッチする必要があることを示しています。これらのハンドラーは、ハンドラーID h1
およびh2
で記述されます。 h1
のフォーマッターは、ID brief
で記述されたものであり、h2
のフォーマッターは、ID precise
で記述されたものです。
ユーザー定義オブジェクト
スキーマは、ハンドラー、フィルター、およびフォーマッターのユーザー定義オブジェクトをサポートします。 (ロガーはインスタンスごとに異なるタイプである必要はないため、この構成スキーマではユーザー定義のロガークラスはサポートされていません。)
構成するオブジェクトは、構成の詳細を示すディクショナリによって記述されます。 場合によっては、ロギングシステムは、オブジェクトがどのようにインスタンス化されるかをコンテキストから推測できますが、ユーザー定義オブジェクトがインスタンス化される場合、システムはこれを行う方法を知りません。 ユーザー定義オブジェクトのインスタンス化に完全な柔軟性を提供するために、ユーザーは「ファクトリ」を提供する必要があります。これは、構成ディクショナリで呼び出され、インスタンス化されたオブジェクトを返す呼び出し可能オブジェクトです。 これは、特別なキー'()'
の下で利用可能になっている工場への絶対インポートパスによって通知されます。 具体的な例を次に示します。
formatters:
brief:
format: '%(message)s'
default:
format: '%(asctime)s %(levelname)-8s %(name)-15s %(message)s'
datefmt: '%Y-%m-%d %H:%M:%S'
custom:
(): my.package.customFormatterFactory
bar: baz
spam: 99.9
answer: 42
上記のYAMLスニペットは3つのフォーマッターを定義しています。 1つ目はID brief
で、指定されたフォーマット文字列を持つ標準の logging.Formatter インスタンスです。 2番目のIDはdefault
で、フォーマットが長く、時間フォーマットも明示的に定義しているため、 logging.Formatter はこれら2つのフォーマット文字列で初期化されます。 Pythonソース形式で示されているように、brief
およびdefault
フォーマッターには構成サブディクショナリがあります。
{
'format' : '%(message)s'
}
と:
{
'format' : '%(asctime)s %(levelname)-8s %(name)-15s %(message)s',
'datefmt' : '%Y-%m-%d %H:%M:%S'
}
それぞれ、これらのディクショナリには特別なキー'()'
が含まれていないため、インスタンス化はコンテキストから推測されます。その結果、標準の logging.Formatter インスタンスが作成されます。 ID custom
の3番目のフォーマッターの構成サブディクショナリは、次のとおりです。
{
'()' : 'my.package.customFormatterFactory',
'bar' : 'baz',
'spam' : 99.9,
'answer' : 42
}
これには特別なキー'()'
が含まれています。これは、ユーザー定義のインスタンス化が必要であることを意味します。 この場合、指定されたファクトリ呼び出し可能オブジェクトが使用されます。 実際の呼び出し可能オブジェクトである場合は直接使用されます。それ以外の場合は、(例のように)文字列を指定すると、実際の呼び出し可能オブジェクトは通常のインポートメカニズムを使用して検索されます。 呼び出し可能オブジェクトは、構成サブディクショナリ内の残りの項目をキーワード引数として呼び出されます。 上記の例では、IDがcustom
のフォーマッタは、呼び出しによって返されると想定されます。
my.package.customFormatterFactory(bar='baz', spam=99.9, answer=42)
キー'()'
は、有効なキーワードパラメータ名ではないため、特別なキーとして使用されています。したがって、呼び出しで使用されるキーワード引数の名前と衝突しません。 '()'
は、対応する値が呼び出し可能であることを示すニーモニックとしても機能します。
外部オブジェクトへのアクセス
sys.stderr
など、構成が構成の外部のオブジェクトを参照する必要がある場合があります。 構成辞書がPythonコードを使用して構築されている場合、これは簡単ですが、構成がテキストファイルを介して提供されると問題が発生します(例: JSON、YAML)。 テキストファイルでは、sys.stderr
をリテラル文字列'sys.stderr'
と区別する標準的な方法はありません。 この区別を容易にするために、構成システムは文字列値内の特定の特別なプレフィックスを探し、それらを特別に扱います。 たとえば、リテラル文字列'ext://sys.stderr'
が構成の値として指定されている場合、ext://
は削除され、残りの値は通常のインポートメカニズムを使用して処理されます。
このようなプレフィックスの処理は、プロトコル処理と同様の方法で行われます。正規表現^(?P<prefix>[a-z]+)://(?P<suffix>.*)$
に一致するプレフィックスを検索する一般的なメカニズムがあり、prefix
が認識されると[ X219X] はプレフィックスに依存する方法で処理され、処理の結果が文字列値に置き換わります。 プレフィックスが認識されない場合、文字列値はそのままになります。
内部オブジェクトへのアクセス
外部オブジェクトだけでなく、構成内のオブジェクトを参照する必要がある場合もあります。 これは、構成システムが認識していることに対して暗黙的に実行されます。 たとえば、ロガーまたはハンドラーのlevel
の文字列値'DEBUG'
は、値logging.DEBUG
、およびhandlers
、filters
およびformatter
エントリは、オブジェクトIDを取得し、適切な宛先オブジェクトに解決されます。
ただし、 logging モジュールに認識されていないユーザー定義オブジェクトには、より一般的なメカニズムが必要です。 たとえば、 logging.handlers.MemoryHandler について考えてみます。これは、委任先の別のハンドラーであるtarget
引数を取ります。 システムはすでにこのクラスを認識しているため、構成では、指定されたtarget
が関連するターゲットハンドラーのオブジェクトIDである必要があり、システムはIDからハンドラーに解決されます。 ただし、ユーザーがalternate
ハンドラーを持つmy.package.MyHandler
を定義した場合、構成システムはalternate
がハンドラーを参照していることを認識しません。 これに対応するために、一般的な解決システムでは、ユーザーは次のことを指定できます。
handlers:
file:
# configuration of file handler goes here
custom:
(): my.package.MyHandler
alternate: cfg://handlers.file
リテラル文字列'cfg://handlers.file'
は、ext://
プレフィックスが付いた文字列と同様の方法で解決されますが、インポート名前空間ではなく構成自体を調べます。 このメカニズムでは、str.format
が提供するのと同様の方法で、ドットまたはインデックスによるアクセスが可能です。 したがって、次のスニペットが与えられます。
handlers:
email:
class: logging.handlers.SMTPHandler
mailhost: localhost
fromaddr: [email protected]
toaddrs:
- [email protected]
- [email protected]
subject: Houston, we have a problem.
構成では、文字列'cfg://handlers'
はキーhandlers
の辞書に解決され、文字列'cfg://handlers.email
はemail
のキーの辞書に解決されます。 X162X] dictなど。 文字列'cfg://handlers.email.toaddrs[1]
は'dev_team.domain.tld'
に解決され、文字列'cfg://handlers.email.toaddrs[0]'
は値'[email protected]'
に解決されます。 subject
値には、'cfg://handlers.email.subject'
または同等に'cfg://handlers.email[subject]'
のいずれかを使用してアクセスできます。 後者の形式は、キーにスペースまたは英数字以外の文字が含まれている場合にのみ使用する必要があります。 インデックス値が10進数のみで構成されている場合、対応する整数値を使用してアクセスが試行され、必要に応じて文字列値にフォールバックします。
文字列cfg://handlers.myhandler.mykey.123
を指定すると、これはconfig_dict['handlers']['myhandler']['mykey']['123']
に解決されます。 文字列がcfg://handlers.myhandler.mykey[123]
として指定されている場合、システムはconfig_dict['handlers']['myhandler']['mykey'][123]
から値を取得しようとし、失敗した場合はconfig_dict['handlers']['myhandler']['mykey']['123']
にフォールバックします。
インポート解決とカスタムインポーター
インポート解決は、デフォルトで、組み込みの __ import __()関数を使用してインポートを実行します。 これを独自のインポートメカニズムに置き換えることをお勧めします。その場合は、DictConfigurator
またはそのスーパークラスであるBaseConfigurator
クラスのimporter
属性を置き換えることができます。 ただし、記述子を介してクラスから関数にアクセスする方法があるため、注意が必要です。 インポートを行うためにPython呼び出し可能オブジェクトを使用していて、インスタンスレベルではなくクラスレベルで定義する場合は、 staticmethod()でラップする必要があります。 例えば:
from importlib import import_module
from logging.config import BaseConfigurator
BaseConfigurator.importer = staticmethod(import_module)
コンフィギュレーターインスタンスで呼び出し可能なインポートを設定する場合は、 staticmethod()でラップする必要はありません。
構成ファイル形式
fileConfig()が理解できる構成ファイル形式は、 configparser 機能に基づいています。 ファイルには、ファイルで定義されている各タイプのエンティティを名前で識別する[loggers]
、[handlers]
、および[formatters]
というセクションが含まれている必要があります。 そのようなエンティティごとに、そのエンティティがどのように構成されているかを識別する個別のセクションがあります。 したがって、[loggers]
セクションのlog01
という名前のロガーの場合、関連する構成の詳細はセクション[logger_log01]
に保持されます。 同様に、[handlers]
セクションのhand01
と呼ばれるハンドラーは、[handler_hand01]
と呼ばれるセクションに構成が保持され、[formatters]
セクションの構成は、[formatter_form01]
というセクションで指定されます。 ルートロガーの構成は、[logger_root]
というセクションで指定する必要があります。
ノート
fileConfig() APIは dictConfig() APIよりも古く、ロギングの特定の側面をカバーする機能を提供していません。 たとえば、 fileConfig()を使用して、単純な整数レベルを超えるメッセージのフィルタリングを提供する Filter オブジェクトを構成することはできません。 ロギング構成に Filter のインスタンスが必要な場合は、 dictConfig()を使用する必要があります。 構成機能の将来の拡張機能が dictConfig()に追加されることに注意してください。そのため、都合のよいときにこの新しいAPIへの移行を検討する価値があります。
ファイル内のこれらのセクションの例を以下に示します。
[loggers]
keys=root,log02,log03,log04,log05,log06,log07
[handlers]
keys=hand01,hand02,hand03,hand04,hand05,hand06,hand07,hand08,hand09
[formatters]
keys=form01,form02,form03,form04,form05,form06,form07,form08,form09
ルートロガーは、レベルとハンドラーのリストを指定する必要があります。 ルートロガーセクションの例を以下に示します。
[logger_root]
level=NOTSET
handlers=hand01
level
エントリは、DEBUG, INFO, WARNING, ERROR, CRITICAL
またはNOTSET
のいずれかになります。 ルートロガーの場合のみ、NOTSET
はすべてのメッセージがログに記録されることを意味します。 レベル値は、logging
パッケージの名前空間のコンテキストで eval() uatedされます。
handlers
エントリは、ハンドラー名のコンマ区切りのリストであり、[handlers]
セクションに表示する必要があります。 これらの名前は、[handlers]
セクションに表示され、構成ファイルに対応するセクションが含まれている必要があります。
ルートロガー以外のロガーの場合、いくつかの追加情報が必要です。 これを次の例で示します。
[logger_parser]
level=DEBUG
handlers=hand01
propagate=1
qualname=compiler.parser
level
およびhandlers
エントリは、ルートロガーと同様に解釈されます。ただし、非ルートロガーのレベルがNOTSET
として指定されている場合、システムは階層の上位のロガーに問い合わせます。ロガーの有効レベルを決定します。 propagate
エントリは、メッセージがこのロガーからロガー階層の上位のハンドラーに伝播する必要があることを示す場合は1に設定され、メッセージが階層の上位のハンドラーに伝播されないではないことを示す場合は0に設定されます。 qualname
エントリは、ロガーの階層チャネル名です。つまり、アプリケーションがロガーを取得するために使用する名前です。
ハンドラー構成を指定するセクションの例を以下に示します。
[handler_hand01]
class=StreamHandler
level=NOTSET
formatter=form01
args=(sys.stdout,)
class
エントリは、ハンドラーのクラスを示します(logging
パッケージの名前空間の eval()によって決定されます)。 level
はロガーと同様に解釈され、NOTSET
は「すべてをログに記録する」ことを意味すると解釈されます。
formatter
エントリは、このハンドラーのフォーマッターのキー名を示します。 空白の場合、デフォルトのフォーマッター(logging._defaultFormatter
)が使用されます。 名前を指定する場合は、[formatters]
セクションに表示され、構成ファイルに対応するセクションが含まれている必要があります。
args
エントリは、 eval()がlogging
パッケージの名前空間のコンテキストで使用される場合、ハンドラークラスのコンストラクターへの引数のリストです。 一般的なエントリがどのように構築されるかを確認するには、関連するハンドラーのコンストラクター、または以下の例を参照してください。 指定しない場合、デフォルトで()
になります。
オプションのkwargs
エントリは、 eval()がlogging
パッケージの名前空間のコンテキストで使用される場合、ハンドラークラスのコンストラクターに対するキーワード引数dictです。 指定しない場合、デフォルトで{}
になります。
[handler_hand02]
class=FileHandler
level=DEBUG
formatter=form02
args=('python.log', 'w')
[handler_hand03]
class=handlers.SocketHandler
level=INFO
formatter=form03
args=('localhost', handlers.DEFAULT_TCP_LOGGING_PORT)
[handler_hand04]
class=handlers.DatagramHandler
level=WARN
formatter=form04
args=('localhost', handlers.DEFAULT_UDP_LOGGING_PORT)
[handler_hand05]
class=handlers.SysLogHandler
level=ERROR
formatter=form05
args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_USER)
[handler_hand06]
class=handlers.NTEventLogHandler
level=CRITICAL
formatter=form06
args=('Python Application', '', 'Application')
[handler_hand07]
class=handlers.SMTPHandler
level=WARN
formatter=form07
args=('localhost', 'from@abc', ['user1@abc', 'user2@xyz'], 'Logger Subject')
kwargs={'timeout': 10.0}
[handler_hand08]
class=handlers.MemoryHandler
level=NOTSET
formatter=form08
target=
args=(10, ERROR)
[handler_hand09]
class=handlers.HTTPHandler
level=NOTSET
formatter=form09
args=('localhost:9022', '/log', 'GET')
kwargs={'secure': True}
フォーマッタ構成を指定するセクションは、次のように代表されます。
[formatter_form01]
format=F1 %(asctime)s %(levelname)s %(message)s
datefmt=
class=logging.Formatter
format
エントリは全体的なフォーマット文字列であり、datefmt
エントリはstrftime()
互換の日付/時刻フォーマット文字列です。 空の場合、パッケージは、日付形式の文字列'%Y-%m-%d %H:%M:%S'
を指定するのとほぼ同等の何かを置き換えます。 この形式では、ミリ秒も指定されます。ミリ秒は、上記の形式の文字列を使用した結果に、コンマ区切り文字で追加されます。 この形式の時間の例は2003-01-23 00:29:50,411
です。
class
エントリはオプションです。 これは、フォーマッターのクラスの名前を(点線のモジュールおよびクラス名として)示します。このオプションは、 Formatter サブクラスをインスタンス化する場合に役立ちます。 Formatter のサブクラスは、拡張形式または圧縮形式で例外トレースバックを提示できます。