Scikit-learn: Pythonロギングを使用して、長時間実行されているタスクの収束の進行状況とレベルの情報をレポートします

https://github.com/GaelVaroquaux/scikit-learn/tree/progress_loggerでこれに関する作業が開始されました

やらなければならないことは、おそらくかなり機械的な作業です。

新しいグラジエントブースティングモジュールにも作業があります。

私の経験では、ロギングは実際にはそれほど使いやすいものではないので、これについては-1です。

誰かがこれに取り組んでいますか？

デフォルトでSTDOUTに出力するロガーを追加するのはどうですか？ それはかなり単純なはずですよね？

この問題は2011年から発生しているので、修正されるのではないかと思います。 RFECV（https://github.com/scikit-learn/scikit-learn/blob/a24c8b464d094d2c468a16ea9f8bf8d42d949f84/sklearn/feature_selection/rfe.py#L273）でこの問題が発生しました。 進行状況を印刷したかったのですが、デフォルトの詳細印刷ではメッセージが多すぎます。 この機能を実現するためにモンキーパッチsys.stdoutを使用したくなかったので、ロガーをオーバーライドするのがシンプルでクリーンなソリューションになります。

sklearnで実際にログを記録することでメリットが得られる＃8105や＃10973など、sklearnで発行されたものは他にもあります。 全体として、ロギングはsklearnへの素晴らしい追加になると思います。

どういたしまして。 おそらくコールバックシステムはより良いです
ロギング

私は今少し忙しいですが、どんな形でもskleanでのカスタマイズ可能なロギングをサポートしています（ただし、標準のPythonロギングを好みます）。

scikit-learnがロギングの使用を開始したときにverbose=Trueが何を意味するかについて、何か議論がありましたか？ これはdask-mlで少し扱っています： https ：

ライブラリがログ設定を行うことは想定されていないため、適切にログを記録するように「アプリケーション」（スクリプトまたはインタラクティブセッションの場合もあります）を構成するのはユーザーの責任です。 これを常に正しく行うのは簡単ではありません。

https://github.com/dask/dask-ml/pull/528での私の提案は、 verbose=Trueが「一時的にログを構成する」ことを意味することです。 コンテキストマネージャーを使用してログを構成できます。scikit-learnでは、現在の動作に一致するようにINFOレベルのメッセージがstdoutに出力されるようにする必要があります。

一時的に、設定されたハンドラーがそれに固有であることも意味します
推定量または推定量タイプ？

dask / dask-ml＃528での私の提案は、verbose = Trueが「一時的にログを設定する」ことを意味することです。

これはバランスが良いようです。 ロギングモジュールの使用は、それほどユーザーフレンドリーではありません。 もう1つの「ハック」は、デフォルトでinfoを使用することですが、ユーザーがverbose=Trueすると、ログをwarning上げることができます。 これは、警告がデフォルトで表示されるため機能します。

ユーザーがもっと要求したときに特定のメッセージのレベルを変更すると思います
冗長性は、ロギングモジュールの目的とは正反対です。
仕事。 ただし、ローカルハンドラーは、警告から情報、デバッグに変更される可能性があります
詳細が増加するにつれてストリームのレベル

@jnothmanのコメントは私の考えと一致しています。 scikit-learnは常にメッセージを出力し、verboseキーワードはロガーレベルとハンドラーを制御します。

ただし、ローカルハンドラーは、警告から情報、デバッグに変更される可能性があります
詳細が増加するにつれてストリームのレベル

さて、これで行きましょう。 現在、ログレベルはhttps://docs.python.org/3/library/logging.html#logging -levelsです。デフォルトでは、 INFO使用できますが、これはデフォルトでは出力されません。 verbose=1場合、ハンドラーの変更情報->警告、およびデバッグ->情報があります。 verbose>=2を設定すると、情報->警告が表示されますが、デバッグ->警告も表示され、見積もり担当者はverbose>=2を「冗長性が増すにつれて、より多くのデバッグメッセージを送信する」ことを意味すると解釈できます。 この意味は、異なる推定量間で異なる可能性があります。

どう思いますか？

こんにちは、私はこの問題に非常に興味があります。 私はlogging経験があり、コンセンサスと計画に達した場合は、ここで拡張機能を実装するのを手伝いたいと思っています。

ここで言及されているアイデアを要約すると役立つ場合があります。

1. コールバックパターンを使用する
2. verboseに応じて、メッセージのレベルを変更します

    if verbose:
        logger.debug(message)
    else:
        logger.info(message)

1. レベルに変更loggerに応じて、 verbose

    if verbose:
        logger.selLevel("DEBUG")

1. 詳細に応じて、レベルDEBUGハンドラーを追加します

    if verbose:
        verbose_handler = logging.StreamHandler()
        verbose_handler.setLevel("DEBUG")
        logger.addHandler(verbose_handler)

これらのオプションについての私の見解：

オプション1またはオプション4がおそらく最適です。

• オプション1（コールバック）は、最も不可知論的であるという点で優れています（人々は好きなようにログに記録できます）。 ただし、メッセージング/状態キャプチャの観点からは柔軟性が低い可能性があります。 （コールバックは、内部ループの反復ごとに1回または1回だけ呼び出されませんか？）
• オプション2、ここで説明したように、 loggingライブラリを誤用していると思います
• オプション3は機能しますが、 loggingライブラリを使用する目的の一部が無効になると思います。 sklearnがlogging使用する場合、ユーザーはlogging自体を介して冗長性を調整できます（例： import logging; logging.getLogger("sklearn").setLevel("DEBUG") 。
• オプション4はおそらく最も標準的です。 ドキュメントでは、 NullHandler以外のライブラリコードでハンドラーを作成することは_not_と提案されていますが、sklearnにverboseフラグがあることを考えると、ここでは理にかなっていると思います。 この場合、ログ印刷はライブラリの「機能」です。

5番目のオプションは、 verboseフラグを削除し、どこでもlogging使用し、ユーザーがlogging APIを介して冗長性を調整できるようにすることです。 結局のところ、これがlogging設計目的です。

@grisaitisありがとう！ https://github.com/scikit-learn/scikit-learn/issues/17439およびhttps://github.com/scikit-learn/scikit-learn/pull/16925#issuecomment-638956487の最近の関連ディスカッションも参照して

推定量ごとの構成が見つかったので、冗長性の削除をサポートします
イライラする、そして冗長な任意の数値、不十分
文書化されているなど。クラスごとの構成は、
複数のscikit-learnロガー名。

5番目のオプションは、冗長フラグを削除し、あらゆる場所でロギングを使用し、ユーザーがロギングAPIを介して冗長性を調整できるようにすることです。 結局のところ、これがロギングの目的です。

推定量ごとの構成が見つかったので、冗長性の削除をサポートします
イライラする、そして冗長な任意の数値、不十分
文書化された、

verboseを取り除き、ログレベルを使用すると非常に便利だと思います。 私が見る唯一の欠点は、ロギングがわずかに発見されにくくなることです。

また、ロギングが提供することの1つは、文字列だけでなく、各ロギングメッセージに追加情報を添付できることです。 だから、有用なものの全体の口述。 したがって、学習中の損失を報告したい場合は、それを実行して数値を保存できます。 さらに、数値を数値として保存し、それを使用して、 logger.debug("Current loss: %(loss)s", {'loss': loss})ようなユーザーフレンドリーな文字列をフォーマットすることもできます。 私はそれが一般的に非常に有用であると思います、そしてsklearnがそれを同様に公開するならば、それは大好きです。

モジュールまたはエスティメータレベルのロガーを使用するのは今のところ少しやり過ぎだと思います。後で拡張できるような単純なものから始める必要があります。
また、私たちが何をするにしても、ユーザーが現在の動作を合理的に簡単に再現できるようにする必要があります。

ロギングとjoblibはどのように相互作用しますか？ ロギングレベルは保持されません（予想どおり）：

import logging
logger = logging.getLogger('sklearn')
logger.setLevel(2)

def get_level():
    another_logger = logging.getLogger('sklearn')
    return another_logger.level

results = Parallel(n_jobs=2)(
    delayed(get_level)() for _ in range(2)
)
results

`` `
[0、0]

But that's probably not needed, since this works:
```python
import logging
import sys
logger = logging.getLogger('sklearn')
logger.setLevel(1)

handler = logging.StreamHandler(sys.stdout)
logger.addHandler(handler)


def log_some():
    another_logger = logging.getLogger('sklearn')
    another_logger.critical("log something")

results = Parallel(n_jobs=2)(
    delayed(log_some)() for _ in range(2)
)

正直なところ、これがどのように機能するかは完全にはわかりません。

stdoutとstderrの両方がjupyterbtwに表示されません。

私の夢は、現在の動作の概算を1本の線で取得できるだけでなく、代わりにプログレスバーやプロットの収束を簡単に使用できるようにすることです。

re verbose：verboseを非推奨にする方がおそらくクリーンですが、verboseを非推奨にし、推定量レベルのログを記録しないと、ある推定量をログに記録するのが少し難しくなりますが、別の推定量をログに記録するのは少し難しくなります。 ただし、ユーザーにメッセージをフィルタリングしてもらうのは問題ないと思います。

やあみんな、フレンドリーな返信と情報をありがとう。 私は他の問題を読み、いくつかの考えを持っています。

joblibは注意が必要です。 私はいくつかのアイデアがあります。

@amuellerそれは非常に奇妙です。 私はあなたの例を再現しました。 物事はと仕事やるconcurrent.futures.ProcessPoolExecutor私が思う、 joblib用途を...

joblibがlogging状態を無効にしているようです。 joblib専門家は、何が起こっているのかについての考えを持っていますか？

import concurrent.futures
import logging
import os

logger = logging.getLogger("demo🙂")
logger.setLevel("DEBUG")

handler = logging.StreamHandler()
handler.setFormatter(
    logging.Formatter("%(process)d (%(processName)s) %(levelname)s:%(name)s:%(message)s")
)
logger.addHandler(handler)

def get_logger_info(_=None):
    another_logger = logging.getLogger("demo🙂")
    print(os.getpid(), "another_logger:", another_logger, another_logger.handlers)
    another_logger.warning(f"hello from {os.getpid()}")
    return another_logger

if __name__ == "__main__":
    print(get_logger_info())

    print()
    print("concurrent.futures demo...")
    with concurrent.futures.ProcessPoolExecutor(2) as executor:
        results = executor.map(get_logger_info, range(2))
        print(list(results))

    print()
    print("joblib demo (<strong i="17">@amueller</strong>'s example #2)...")
    from joblib import Parallel, delayed
    results = Parallel(n_jobs=2)(delayed(get_logger_info)() for _ in range(2))
    print(results)

どの出力

19817 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19817 (MainProcess) WARNING:demo🙂:hello from 19817
<Logger demo🙂 (DEBUG)>

concurrent.futures demo...
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

joblib demo (<strong i="21">@amueller</strong>'s example #2)...
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

メインプロセスのメインロガーにログメッセージを送信するようにプロセスjoblibspawnsを構成する必要があると思います。 そうすれば、メインプロセスでのみロギングを制御できます。 このようなものまたはこれ。 したがって、ロギングキューのシンクとソースがあり、それらを結び付けることができます。 これをクラスターで使用して、すべてのマシンのすべてのワーカーから中央の場所にすべてのログを送信し、ユーザーのコンピューターに表示します。

@mitar同意します、それが最善の策かもしれないと思います。 （必ずしもネットワークベースのキューではありませんが、プロセス間通信キュー）

私は実際にloggingのQueueHandler / QueueListenerを使用して例をコーディングし、 joblibとconcurrent.futuresテストしています。 ここでフォローアップします。

他の提案も大好きです：

また、ロギングが提供することの1つは、文字列だけでなく、各ロギングメッセージに追加情報を添付できることです。 だから、有用なものの全体の口述。 したがって、学習中の損失を報告したい場合は、それを実行して数値を保存できます。 さらに、数値を数値として保存し、それを使用して、 logger.debug("Current loss: %(loss)s", {'loss': loss})ようなユーザーフレンドリーな文字列をフォーマットすることもできます。 私はそれが一般的に非常に有用であると思います、そしてsklearnがそれを同様に公開するならば、それは大好きです。

extraパラメーターとカスタムHandlerクラスを使用して、ガウス混合モデリングの視覚化を実装しました。 状態を渡したり、状態の処理方法をユーザーに決定させたりするのに非常にうまく機能します。

また、私が上で気づいたjoblibの特異性についても...私はそれをそのまま受け入れ、範囲外にします。 とにかく、キューベースの設計が最も柔軟です。

私が考えることができるQueueHandlerを使用する唯一の制限は、 extra状態（ logger.debug("message", extra={...} ）は、 extra dictがキューに対してシリアル化可能でなければならないということです。 したがって、numpy配列はありません。 ：/他の問題は考えられませんが

私は実際にQueueHandler / QueueListenerを使用して例をコーディングしています。

はい、常にキューハンドラーを使用する必要があります。これは、ソケットブロックを介した送信がいつ行われるかわからず、ログのブロックが原因でモデルの速度が低下したくないためです。

また、 extraを使用する必要もありません。 logger.debug("message %(foo)s", {'foo': 1, 'bar': 2})はうまくいくと思います。

はい、常にキューハンドラーを使用する必要があります。これは、ソケットブロックを介した送信がいつ行われるかわからず、ログのブロックが原因でモデルの速度が低下したくないためです。

joblib場合、 QueueHandler / QueueListenerを実装した場合、プロセスプールにどのような状態を渡す必要がありますか？ queueだけですよね？

また、 extraを使用する必要もありません。 logger.debug("message %(foo)s", {'foo': 1, 'bar': 2})はうまくいくと思います。

はいありがとう。 テキストに変換せずに状態をログに記録することも便利だと思います。 たとえば、 extraにnumpy配列を含め、jupyterノートブックのカスタムロギングハンドラーを使用してリアルタイムのデータ視覚化（ある意味でビジュアルロギング）を実行します。 これはsklearnで非常に優れており、

joblibの場合、QueueHandler / QueueListenerを実装した場合、プロセスプールにどのような状態を渡す必要がありますか？ キューだけですよね？

そう思います。 私はこれをプロセスの境界を越えて使用していませんが、マルチプロセッシングのサポートが文書化されているようです。したがって、joblibでも機能するはずです。 同じプロセス内でQueueHandler / QueueListenerを使用しています。 ロギング書き込みをロギングトランスポートから分離します。 QueueHandler-> QueueListener->中央ログサービスに送信も同様です。 しかし、ドキュメントからは、マルチプロセッシングキューを介して機能するように見えます。

テキストに変換せずに状態をログに記録することも便利だと思います

はい。 私が言っているのは、 extraを使用する必要はなく、dictを直接渡すだけで、メッセージのフォーマットにそのdictのいくつかのアイテムのみを使用するということです（フォーマット文字列で使用されるものが決定されることに注意してください） sklearnライブラリではなく、sklearnライブラリのユーザーが、予期しないものをフォーマットするようにいつでも構成できるため、テキストに正確に変換されるものは実際にはsklearnの制御下にありません）。 extraすべての値は、メッセージのフォーマットにも使用できます。 そのため、 extraがどれほど役立つかわかりません。 しかし、私はそれを使うべきではないと言っているわけでもありません。 左側の文字列のペイロードが何であったか、そして何が余分であるかは、はるかに明確です。 したがって、両方を使用することもできます。 この代替案が知られていることを確認したかっただけです。

@grisaitis参考までに、コミットで名前について言及すると、コミットで何かを行うたびに（届くので、一般的にはお勧めしません;）

アンドレアスごめんなさい！ 😬それは恥ずかしいことです...私はちょうどよく文書化されたコミットをしようとしていました笑。 将来的には避けます。

そのリポジトリで、QueueHandler / QueueListenerコンボを使用してjoblibでログがどのように機能するかを理解しました。 うまく機能しているように見えます。

最初のステップとして、 joblibが使用されるsklearnの一部に、そのアプローチでロギングを実装します。 たぶん、アンサンブルモデルの1つです。 新しいPRを開きます。

joblibの場合、QueueHandler / QueueListenerを実装した場合、

はい、マルチプロセッシングの場合にロギングモジュールとコールバック（https：//のマルチプロセッシングを使用したコールバックの近似例）の両方を使用する場合は、監視スレッド（ここではQueueListener ）を開始/停止する必要があるようです。 github.com/scikit-learn/scikit-learn/pull/16925#issuecomment-656184396）

したがって、上記で「機能」した唯一の理由は、共有リソースであるstdoutに出力され、 printがpython3などでスレッドセーフであるためだと思います。

だから私が上で「うまくいった」ことをした唯一の理由は、それが共有リソースであるstdoutに印刷され、印刷がpython3などでスレッドセーフであるということでしたか？

印刷はスレッドセーフではありません。 それらは同じファイル記述子に出力するだけです。 おそらく長時間実行すると、メッセージがインターリーブしたり、行が混同されたりすることがあります。