logging.config —ロギング構成—Pythonドキュメント

提供：Dev Guides
< PythonPython/docs/3.8/library/logging.config
移動先:案内、検索

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 としてインスタンス化されます。 ID fileのハンドラーは、キーワード引数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 のサブクラスは、拡張形式または圧縮形式で例外トレースバックを提示できます。

ノート

上記のように eval（）を使用するため、 listen（）を使用してソケットを介して構成を送受信することにより、潜在的なセキュリティリスクが発生します。 リスクは、相互信頼のない複数のユーザーが同じマシンでコードを実行する場合に限定されます。 詳細については、 listen（）のドキュメントを参照してください。


も参照してください

モジュールロギング
ロギングモジュールのAPIリファレンス。
モジュール logging.handlers
ロギングモジュールに含まれている便利なハンドラー。



「https://www.finddevguides.com/index.php?title=Python/docs/3.8/library/logging.config&oldid=99118」から取得
Powered by MediaWiki