Gunicorn: Gunicornのデフォルトのエラーログの日付形式は標準のISO8601ではありません

日付形式は、共通ログ形式に従います：https： //en.wikipedia.org/wiki/Common_Log_Format

ああ、お詫びします。 私の回答は、アクセスログの形式に関するものです。 このレポートは、エラーログ形式に関するものです。

%{DATESTAMP} %{ISO8601_TIMEZONE}を使用できるようです

19.xの場合、変更を加えるには遅すぎます。 これにより、多くのロギングの使用が中断されます。 これは次のメジャーバージョンで変更したいものですか？

@tilgoviだから、これは何か欲しいですか？

デプロイされたシステムの多くは、現在の形式に依存しています。 システムのようにログスタッシュにルールを常に書き込むことができるため、あまりにも大きな変更であり、あまり価値がないのではないかと心配しています。 考え？

考えられる妥協案は、切り替えと非推奨である可能性があります。 標準に準拠していない奇数の（ただしわずかに）日付形式を段階的に廃止し、ユーザーに固定ログ行形式への切り替えを提供することができます。 私はPythonを介してロガーをオーバーライドできることを知っていますが、gunicornには競合する設定が組み込まれているため、私のお気に入りの選択肢ではありません：DIはOCDの人ではありませんが、grokクエリを作成することは、特に違いがある場合に現代的なタイプの拷問ですあなたが説明しているのは1つのスペースです：Dそして、何かが変わった場合に必要以上に長く一致するように維持するのは開発者次第です。 必要なのは世界の終わりではありませんが、バグのあるソフトウェアに依存している場合でも、バグを修正し続けます...それが私が思うことです...質問が私に向けられたかどうかはわかりません...

R20のデフォルトを変更することを検討できます。

この形式は実際にはかなり一般的です。 RFC 3339には、それに関する注記があります。

注：ISO 8601は、「T」で区切られた日付と時刻を定義します。 この構文を使用するアプリケーションは、読みやすくするために、（たとえば）スペース文字で区切られたフルデートとフルタイムを指定することを選択できます。

エラーログもコマンドラインに出力されるので、人間が読む必要があります。そのように保持したいと思います。 タイムゾーン形式に問題はありますか？

これは、logstashのgrokに、寛大なパターンではなく、厳密なパターンがプリロードされていることを意味します。 私は以前BBC / EBUで標準の人々と仕事をしたことがあり、この種のひどい言葉遣いを覚えています。 読みやすさのために「（たとえば）スペース文字」これは実装できません....その文字は何ですか？ もちろん、この時点で任意のキャラクターを許可することができますが、それはOKではありません。 したがって、Logstashの担当者は、これをTまたはスペースのいずれかに次のように実装しました。

TIMESTAMP_ISO8601 %{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})?%{ISO8601_TIMEZONE}?

さらに、これは問題が何であったかではありません。 問題は、標準で許可されていないスペースを持つタイムゾーンサフィックスです。

したがって、残念ながら、この形式は一般的ではありません。 このフォーマットは、gunicornに固有の非正統的な形式です。 スペースについて議論しているのはこれがいかに愚かであるかを私は知っていますが、言語とオートモトンの構文に関してはすべてです。

それは役に立ちます、@ kozmaz87。 仕様を掘り下げてくれてありがとう。

しかし、私たちはここにいるので、さらに悪いアクセスログ形式も指摘したいと思います。 私はそれがどこから来ているのかをコードで見つけることさえできませんでした...それはかなりあいまいな構成メカニズムから構築されています。 他の場所から割り当てられました。 調査するコードをチェックアウトしませんでしたが、次の出力が生成されます。

127.0.0.1 - - [13/Aug/2018:15:03:26 +0000] "GET /debug/sms HTTP/1.1" 400 74 "-" "python-requests/2.18.4"

gunicornのドキュメントを見ると、このログの2番目の部分は何らかの理由で「-」であることがわかります... 3番目はユーザーであると想定されており、これも「-」と評価されています。時間と年が「：」で結合されている日付形式。もちろん、お気に入りのスペースで区切られたタイムゾーンのサフィックスもあります。 しかし、調べてみると、これがnginxがログに記録する方法であることがわかったので、nginxアクセスログを模倣しようとすることで、このスペースで区切られたタイムゾーンが発生していると思います。 HAProxyは、タイムゾーンサフィックスを付けないことを除いて、これも使用します...

ロギングはクレイジーです...誰かが私に氷のような水のバケツを持ってきます:)

アクセスログの形式は間違いなく「一般的」です： https ：//en.wikipedia.org/wiki/Common_Log_Format

ただし、最後にリファラーとユーザーエージェントを追加します。 --access-logformatフラグを参照してください： http ：//docs.gunicorn.org/en/latest/settings.html#access -log-format

私はそれを理解しています。 2番目のアイテムが「-」であるのは面白いと思います：D実装した人は誰でもこれを持っていて、「-」を入れたような気がします

現在のログ形式を保持します。 imoの一般的な形式は適切であり、アップストリームのサーバーの変更については認識していません。 考え？ cc @tilgovi

バンプ@tilgoviまた@berkerpeksag

修正されないので問題を閉じます。 @tilgoviで述べたように、[共通ログ形式]（
https://en.wikipedia.org/wiki/Common_Log_Format。

これを開いたままにしておくことができると思います。 エラーログには一般的なログ形式を使用していません。 一般的なログ形式はアクセスログ形式であり、そこで使用します。

実際、気にしないでください。 ちょうど今ダブルチェックしましたが、両方に同じ時間フォーマット文字列を使用しています。 それは私には他のどの方法よりも良いようです。 アクセスログとエラーログの日付形式を変えたくありません。

私は今この問題をよりよく理解しており、再開すべきだと思います。

デフォルト設定でのGunicornからの出力例は次のとおりです。

[2019-01-25 11:44:34 -0800] [22794] [INFO] gunicorn19.9.0を開始しています
[2019-01-25 11:44:34 -0800] [22794] [INFO]リスニング： http ：//127.0.0.1：8000（22794）
[2019-01-25 11:44:34 -0800] [22794] [情報]ワーカーの使用：同期
[2019-01-25 11:44:34 -0800] [22797] [INFO] pidを使用した起動ワーカー：22797
[2019-01-25 11:44:36 -0800] [22797] [INFO] 127.0.0.1 --- [25 / Jan / 2019：11：44：36 -0800] "GET / HTTP / 1.1" 200 14 " -"" curl / 7.54.0 "

問題は、アクセスログの一般的なログ形式を解析することではなく、_ログ行全体_を解析することです。

Gunicornは、ログ行の先頭にタイムスタンプ、pid、およびレベルを出力します。 アクセスログ行には、独自のタイムスタンプを持つ共通のログ形式のメッセージがあります。

タイムスタンプが同じ形式ではないことに注意してください。 この問題の元々の要求は、ログ行の先頭のタイムスタンプに、_一般的なログ形式のように_スペースを入れないことでした。

これは次のようになります。

[25 / Jan / 2019：11：44：34 -0800] [22794] [INFO] gunicorn19.9.0を開始しています
[25 / Jan / 2019：11：44：34 -0800] [22794] [INFO]リスニング： http ：//127.0.0.1：8000（22794）
[25 / Jan / 2019：11：44：34 -0800] [22794] [情報]ワーカーの使用：同期
[25 / Jan / 2019：11：44：34 -0800] [22797] [INFO] pidでワーカーを起動しています：22797
[25 / Jan / 2019：11：44：36 -0800] [22797] [INFO] 127.0.0.1 --- [25 / Jan / 2019：11：44：36 -0800] "GET / HTTP / 1.1" 200 14 "-" "curl / 7.54.0"

一般的なログ形式は国際的ではないため（月の名前が短いため）、答えはおそらくそうではないと思います。

ただし、各ログ行の先頭のタイムスタンプをISO8601タイムスタンプに変更することはできます。

https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations

T文字の代わりに日付と時刻の間のスペースは実際には許可されますが、時刻とゾーンオフセットの間のスペースは許可されません。

有効なISO8601形式は次のとおりです。

• [2019-01-25T11:44:34-0800]
• [2019-01-25 11:44:34-0800]

私たちが今持っているものと比較してください：

[2019-01-25 11:44:34 -0800]
                    ^ there is a space here

ただし、デプロイされたシステムを壊すことについては非常に心配します。

ログの解析/再フォーマットはlogstashなどのツールで簡単に処理できるため、問題があるかどうかはわかりません。 今のところそのままにしておきます。

アクセスログに別の形式が必要な場合は、特定の識別子を追加できますか？ そうすれば、フォーマットを壊すことはありません。 ただし、エラーログはフォーマットする方法を提供していないため、問題になります。 そのような場合、おそらく環境変数がそれを行うでしょうか？

アクセスログの形式は変更しないと思います。 これは現在一般的なログ形式であり、 --access-log-format設定があります。

アクセスログ形式は、ハンドラーに渡されるアクセスログの_メッセージ_のみをフォーマットします。 その場合、ハンドラーには独自のフォーマッターがあります。

stdoutとstderrのストリームハンドラーのデフォルトのフォーマッターは、先頭にタイムスタンプを付けます。 つまり、デフォルトの構成では、アクセスログに_two_タイムスタンプがあります。1つは先頭に、もう1つはメッセージにあります。

ハンドラーのフォーマッターを変更するには、 --logconfigオプション（fileまたはdict）のいずれかを使用する必要があります。

デフォルトのフォーマッタにISO8601タイムスタンプを含めることを検討する必要があります。

ログの解析/再フォーマットは、logstashなどのツールで簡単に処理できます

はい。ただし、これらのツールが組み込みパターンでタイムスタンプを解析できる場合は非常に便利なので、ユーザーは正規表現を記述する必要がありません。 grokにはISO8601タイムスタンプのパターンが組み込まれているため、元の問題が発生しました。

@tilgovi互換性を壊したくない。 また、NGINXは、ISO8601形式または共通ログ形式のいずれかを使用して時刻を設定する可能性を提供します。

$time_iso8601
local time in the ISO 8601 standard format
$time_local
local time in the Common Log Format

https://nginx.org/en/docs/http/ngx_http_log_module.html

それは遺産を壊さないので、私は同じことをします。 ところで、出力にアクセスログ行を表示するだけではいけませんか？ PIDを持つ最初のヘッダーを持つべきではないようです。 考え？

それをデフォルトのフォーマッターの一部にすることについて、私はそれがいくつかのツールを壊してしまうのではないかと心配しています。 カスタム環境変数TIME_ISO8601=trueを強制的に使用するのはどうですか？

互換性を壊したくない。

私もしません。 間違った理由でチケットを閉じたと思うので、チケットを再開したかっただけです。 問題は一般的なログ形式から変更することであるかのように、私たちは両方とも応答しました。 問題は、アクセスログメッセージの形式ではなく、デフォルトのフォーマッタのタイムスタンプです。 もっと話し合うことができてうれしいですが、答えはまだ何もしないことかもしれません。

ところで、出力にアクセスログ行を表示するだけではいけませんか？ PIDを持つ最初のヘッダーを持つべきではないようです。 考え？

可能。 わからない。

カスタム環境変数を持つのはどうですか

多分大丈夫。 ユーザーは、高度なログ設定を使用して、いつでもログを完全に制御できます。 --log-levelのように、CLIのいくつかの設定を単純にするように努めているため、ユーザーは構成ファイルを使用する必要がありません。 たぶん--log-date-formatを追加できますか？ iso8601のような記号文字列を認識することもできます。 この設定は、 --log-configまたはlog_config_dictを使用したくないユーザー向けです。

それまでの間、 @ tilgoviは、Python 2との互換性を壊しているため、フォーマットを変更するのに適した時期です。

レガシーについて私がもっと心配しているのは、ISO8601が人間の目で解析するのが難しく、私を含む多くの人々が何が起こっているかを観察する機会としてコンソールを使用していることだと思います。

私は次のことを提案したいと思います：

• [] stdoutおよびstderrログにこの形式を使用するように強制するオプション-iso8601を追加します（あなたが提案しているように）
• []アクセスログに、この形式で時刻を表示する形式のオプションを追加します

ここにいる間、UTCをその時間に使用するための-utcオプションを使用することもできますか？ 考え？

念のため、デフォルトを変更した場合、これが提案された差分になります。

diff --git a/gunicorn/glogging.py b/gunicorn/glogging.py
index 56cc5bd..0735e58 100644
--- a/gunicorn/glogging.py
+++ b/gunicorn/glogging.py
@@ -80,7 +80,7 @@ CONFIG_DEFAULTS = dict(
         formatters={
             "generic": {
                 "format": "%(asctime)s [%(process)d] [%(levelname)s] %(message)s",
-                "datefmt": "[%Y-%m-%d %H:%M:%S %z]",
+                "datefmt": "[%Y-%m-%d %H:%M:%S%z]",
                 "class": "logging.Formatter"
             }
         }
@@ -175,7 +175,7 @@ class Logger(object):
     loglevel = logging.INFO

     error_fmt = r"%(asctime)s [%(process)d] [%(levelname)s] %(message)s"
-    datefmt = r"[%Y-%m-%d %H:%M:%S %z]"
+    datefmt = r"[%Y-%m-%d %H:%M:%S%z]"

     access_fmt = "%(message)s"
     syslog_fmt = "[%(process)d] %(message)s"

アクセスログトークンでISO8601日時を使用するオプションは興味深いと思いますが、それはこの問題の動機とは別のものです。

ちなみに、これについては強く感じません。 😄問題を正確に表現したいだけです。

おそらくそれについてもう少し考える必要があります。 時々、20.1に延期します。

親愛なる開発者、
私はリクエストロスの問題に直面しています（Gunicornとは何の関係もありません）。 この例のように、Apacheサーバーの1つである2019-10-30 14:27:16.960421のように、マイクロ秒を含む正確なタイムスタンプを取得できる必要があります。 それはクールな拡張であり、それを検討するためのthxです。

フラグlog-date-format iso8601がgunicornの次のバージョンで利用可能になるとしたら、何か希望はありますか？