Gunicorn: Format tanggal pencatatan kesalahan default Gunicorn bukan standar ISO8601

Format tanggal mengikuti Format Log Umum: https://en.wikipedia.org/wiki/Common_Log_Format

Maaf. Tanggapan saya adalah tentang format log akses. Laporan ini adalah tentang format log kesalahan.

Sepertinya Anda bisa menggunakan %{DATESTAMP} %{ISO8601_TIMEZONE}

untuk 19.x sudah terlambat untuk melakukan perubahan apa pun. Itu akan merusak banyak penggunaan logging. Apakah ini sesuatu yang ingin kami ubah di versi utama berikutnya?

@tilgovi jadi apakah ini sesuatu yang diinginkan?

Banyak sistem yang dikerahkan bergantung pada format saat ini. Saya khawatir ini adalah perubahan yang terlalu besar yang tidak membawa banyak nilai karena aturan selalu dapat ditulis tentangnya dalam sistem seperti simpanan log. Pikiran?

Kemungkinan kompromi bisa berupa peralihan dan penghentian. Anda dapat mulai menghapus format tanggal ganjil (namun sangat sedikit) yang tidak mengikuti standar secara bertahap dan memberi pengguna peralihan ke format baris log tetap. Saya tahu bahwa saya dapat mengesampingkan logger melalui python tetapi karena gunicorn hadir dengan pengaturan bersaing yang dipanggang di dalamnya, itu tidak akan menjadi pilihan favorit saya: DI bukan orang OCD tetapi memasak permintaan grok adalah jenis penyiksaan modern terutama ketika perbedaannya yang Anda perhitungkan adalah satu ruang :D Dan kemudian terserah pengembang untuk mempertahankan kecocokan yang lebih lama dari yang diperlukan jika ada yang berubah. Ini bukan akhir dunia jika harus tetapi kami terus memperbaiki bug bahkan jika orang mengandalkan perangkat lunak buggy... Itulah yang saya pikirkan... tidak yakin apakah pertanyaan itu ditujukan kepada saya...

Kita bisa melihat mengubah default untuk R20.

Format ini sebenarnya cukup umum. RFC 3339 memiliki catatan tentangnya:

CATATAN: ISO 8601 mendefinisikan tanggal dan waktu yang dipisahkan oleh "T". Aplikasi yang menggunakan sintaks ini dapat memilih, demi keterbacaan, untuk menentukan tanggal penuh dan waktu penuh yang dipisahkan oleh (misalnya) karakter spasi.

Log kesalahan juga dicetak pada baris perintah dan harus dibaca oleh manusia dan saya ingin tetap seperti itu. Apakah ada masalah dengan format zona waktu?

Ok jadi itu berarti grok di logstash dimuat dengan pola yang ketat daripada yang lunak. Saya telah bekerja dengan orang-orang standar sebelumnya di BBC/EBU dan saya ingat kata-kata yang mengerikan semacam ini. Untuk keterbacaan "(katakanlah) karakter spasi" Ini tidak dapat diterapkan .... apa karakter itu? Tentu saja Anda dapat mengizinkan karakter apa pun pada saat ini dan itu tidak boleh. Jadi orang-orang di Logstash menerapkan ini dengan cara berikut menjadi T atau spasi

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

Selanjutnya INI BUKAN APA MASALAH ITU. Apa masalahnya adalah sufiks zona waktu yang memiliki spasi yang TIDAK DIIZINKAN oleh standar.

Jadi tidak, sayangnya format ini tidak umum. Format ini tidak ortodoks khusus untuk gunicorn. Saya tahu betapa bodohnya ini terdengar bahwa kami berdebat tentang ruang tetapi ketika datang ke bahasa dan sintaks automotons adalah segalanya.

Itu membantu, @kozmaz87. Terima kasih telah menggali spesifikasinya.

Tetapi karena kita di sini, saya juga ingin menunjukkan format log akses, yang bahkan lebih buruk. Saya bahkan tidak berhasil menemukan dalam kode dari mana pun asalnya... Ini dibangun dari beberapa mekanisme konfigurasi yang tidak jelas. ditugaskan dari tempat lain. Saya tidak memeriksa kode untuk menyelidiki tetapi menghasilkan output ini:

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

Melihat dokumen gunicorn, kami mengetahui bahwa bagian ke-2 dari log ini adalah '-' untuk alasan apa pun ... yang ke-3 seharusnya adalah pengguna, yang juga mengevaluasi ke '-' tidak yakin mengapa dan kemudian datang ini indah format tanggal di mana jam dikawinkan dengan tahun dengan ':' dan tentu saja sufiks zona waktu yang dipisahkan oleh spasi lagi. Tetapi setelah menggali, saya menemukan bahwa ini adalah cara nginx mencatatnya, jadi saya berasumsi dari sinilah zona waktu yang dipisahkan ruang ini berasal dengan mencoba meniru log akses nginx. HAProxy tidak menggunakan ini juga kecuali itu tidak menempatkan akhiran zona waktu ...

Logging itu gila... Seseorang bawakan aku seember air es :)

Format log akses pasti "umum": https://en.wikipedia.org/wiki/Common_Log_Format

Kami menambahkan perujuk dan agen pengguna sampai akhir, meskipun. Lihat bendera --access-logformat : http://docs.gunicorn.org/en/latest/settings.html#access -log-format

Saya menyadari itu. Saya hanya merasa lucu bahwa item ke-2 adalah '-' :D Rasanya siapa pun yang menerapkannya memilikinya dengan ini dan hanya memasukkan '-'

saya akan menyimpan format log saat ini. format umum imo bagus dan saya tidak mengetahui adanya perubahan di server hulu. pikiran? cc @tilgovi

bertemu @tilgovi juga @berkerpeksag

menutup masalah karena tidak akan diperbaiki. Seperti yang dikatakan @tilgovi kami menggunakan [format log umum](
https://en.wikipedia.org/wiki/Common_Log_Format.

Saya pikir kita bisa menjaga ini tetap terbuka. Kami tidak menggunakan format log umum untuk log kesalahan. Format log yang umum adalah format log akses dan kami menggunakannya di sana.

Sebenarnya, tidak apa-apa. Saya baru saja memeriksa ulang dan kami menggunakan string format waktu yang sama untuk keduanya. Itu tampaknya lebih baik bagi saya daripada alternatif apa pun. Saya tidak ingin log akses dan log kesalahan memiliki format tanggal yang berbeda.

Saya memahami masalah ini lebih baik sekarang dan berpikir kami harus membuka kembali.

Berikut contoh output dari Gunicorn dengan pengaturan default:

[2019-01-25 11:44:34 -0800] [22794] [INFO] Memulai gunicorn 19.9.0
[2019-01-25 11:44:34 -0800] [22794] [INFO] Mendengarkan di: http://127.0.0.1 :8000 (22794)
[2019-01-25 11:44:34 -0800] [22794] [INFO] Menggunakan pekerja: sinkronisasi
[2019-01-25 11:44:34 -0800] [22797] [INFO] Boot pekerja dengan 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 " -" "ikal/7.54.0"

Masalahnya bukan tentang mem-parsing format log umum dari log akses, ini tentang mengurai _seluruh baris log_.

Gunicorn mengeluarkan stempel waktu, pid, dan level di awal baris log. Jalur log akses _also_ memiliki pesan dalam format log umum dengan stempel waktunya sendiri.

Perhatikan bagaimana cap waktu tidak dalam format yang sama. Permintaan asli untuk masalah ini adalah agar stempel waktu di awal baris log tidak memiliki spasi _seperti format log umum_.

Itu akan terlihat seperti ini:

[25/Jan/2019:11:44:34 -0800] [22794] [INFO] Memulai gunicorn 19.9.0
[25/Jan/2019:11:44:34 -0800] [22794] [INFO] Mendengarkan di: http://127.0.0.1 :8000 (22794)
[25/Jan/2019:11:44:34 -0800] [22794] [INFO] Menggunakan pekerja: sinkronisasi
[25/Jan/2019:11:44:34 -0800] [22797] [INFO] Boot pekerja dengan 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 "-" "ikal/7.54.0"

Saya pikir jawabannya mungkin tidak, karena format log yang umum tidak internasional (memiliki nama bulan yang pendek).

Namun, kita dapat mengubah stempel waktu di awal setiap baris log menjadi stempel waktu ISO8601.

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

Spasi antara tanggal dan waktu sebenarnya diperbolehkan menggantikan karakter T, tetapi spasi antara waktu dan offset zona tidak diperbolehkan.

Berikut adalah format ISO8601 yang valid yang dapat kami miliki:

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

Bandingkan dengan apa yang kita miliki sekarang:

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

Saya akan sangat khawatir tentang merusak sistem yang digunakan.

penguraian/pemformatan ulang log yang baik dapat dengan mudah ditangani alat seperti logstash, jadi saya tidak yakin itu masalah. Saya akan tetap seperti itu untuk saat ini.

Jika orang menginginkan format yang berbeda untuk log akses, mungkin kami dapat menambahkan pengidentifikasi khusus untuk itu? Dengan begitu kita tidak akan merusak formatnya. Namun, log kesalahan menjadi masalah karena kami tidak menyediakan cara untuk memformatnya. Dalam kasus seperti itu mungkin variabel lingkungan akan melakukannya?

Saya tidak berpikir format log akses harus berubah. Ini adalah format log yang umum sekarang dan kami memiliki pengaturan --access-log-format .

Format log akses hanya memformat _message_ dari log akses yang diteruskan ke handler. Handler kemudian memiliki formatter sendiri.

Pemformat default kami untuk pengendali aliran di stdout dan stderr menempatkan stempel waktu di awal. Itu berarti bahwa dengan konfigurasi default, log akses memiliki _dua_ cap waktu: satu di awal dan satu di pesan.

Mengubah formatter untuk handler memerlukan penggunaan salah satu opsi --logconfig (file atau dict).

Kita harus mempertimbangkan untuk memiliki stempel waktu ISO8601 dalam formatter default.

penguraian/pemformatan ulang log dapat dengan mudah ditangani alat seperti logstash

Ya, tetapi sangat nyaman ketika alat tersebut dapat mengurai stempel waktu dengan pola bawaan sehingga pengguna tidak perlu menulis regexp. Masalah asli dibuka karena grok memiliki pola bawaan untuk cap waktu ISO8601.

@tilgovi Saya tidak ingin merusak kompatibilitas. NGINX juga menawarkan kemungkinan untuk mengatur waktu baik menggunakan format ISO8601 atau Format Log Umum :

$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

Saya akan melakukan hal yang sama karena itu tidak merusak warisan. Btw bukankah seharusnya kita hanya menampilkan baris log akses ke output? Sepertinya kita seharusnya tidak memiliki header pertama dengan PID. Pikiran?

tentang menjadikannya bagian dari formatter default, saya khawatir itu merusak beberapa alat. Bagaimana dengan memiliki variabel lingkungan khusus TIME_ISO8601=true untuk memaksanya?

Saya tidak ingin merusak kompatibilitas.

Saya juga tidak. Saya hanya ingin membuka kembali tiket karena saya pikir kami menutupnya karena alasan yang salah. Kami berdua menjawab seolah-olah masalahnya adalah mengubah dari format log umum. Masalahnya adalah stempel waktu dalam formatter default, bukan format pesan log akses. Saya senang kita bisa mendiskusikannya lebih lanjut, tetapi jawabannya mungkin adalah tetap tidak melakukan apa-apa.

Btw bukankah seharusnya kita hanya menampilkan baris log akses ke output? Sepertinya kita seharusnya tidak memiliki header pertama dengan PID. Pikiran?

Mungkin. Saya tidak yakin.

Bagaimana dengan memiliki variabel lingkungan khusus?

Mungkin baik-baik saja. Pengguna selalu dapat mengontrol log sepenuhnya dengan menggunakan konfigurasi logging lanjutan. Kami mencoba membuat beberapa pengaturan sederhana untuk CLI, seperti --log-level , sehingga pengguna tidak perlu menggunakan file konfigurasi. Mungkin kita bisa menambahkan --log-date-format ? Ia bahkan dapat mengenali string simbolis seperti iso8601 . Setelan ini ditujukan untuk pengguna yang tidak ingin menggunakan --log-config atau log_config_dict .

@tilgovi sementara itu rilis 20.0 adalah waktu yang tepat untuk perubahan format karena kami melanggar kompatibilitas dengan python 2.

Saya pikir yang lebih mengkhawatirkan saya tentang warisan apa pun adalah bahwa ISO8601 sulit diuraikan untuk mata manusia dan banyak orang, termasuk saya, menggunakan konsol sebagai kesempatan untuk mengamati apa yang terjadi.

Saya ingin menyarankan hal-hal berikut:

• [ ] tambahkan opsi -iso8601 yang memaksa log stdout & stderr untuk menggunakan format ini (seperti yang Anda sarankan)
• [ ] di log akses tambahkan opsi dalam format untuk menampilkan waktu di bawah format ini

Sementara kita di sini mungkin kita juga bisa memiliki opsi -utc untuk menggunakan UTC untuk sementara waktu? Pikiran?

Untuk memastikan, ini akan menjadi perbedaan yang diusulkan jika kita baru saja mengubah default:

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"

Saya pikir opsi untuk menggunakan datetime ISO8601 dalam token log akses menarik, tetapi itu terpisah dari apa yang memotivasi masalah ini.

Saya tidak merasa kuat tentang ini, omong-omong. Saya hanya ingin mewakili masalah ini secara akurat.

kita mungkin perlu sedikit memikirkannya. Saya menundanya ke 20,1 untuk memberi tahu kami beberapa kali.

Pengembang yang terhormat,
Saya menghadapi masalah kehilangan permintaan (tidak ada hubungannya dengan Gunicorn). Saya harus dapat memiliki stempel waktu yang tepat termasuk mikrodetik, seperti dalam contoh ini dari salah satu server Apache kami : 2019-10-30 14:27:16.960421 . Ini akan menjadi peningkatan yang keren, thx untuk mempertimbangkannya.

Adakah harapan jika bendera, log-date-format iso8601 , akan tersedia di versi gunicorn berikutnya?