Gunicorn: Gunicorn डिफ़ॉल्ट त्रुटि लॉगिंग दिनांक स्वरूप मानक ISO8601 नहीं है

को निर्मित 3 मई 2018 · 34टिप्पणियाँ · स्रोत: benoitc/gunicorn

https://github.com/benoitc/gunicorn/blob/e73ca252f7e1d0286998a0ae4254164291020a0c/gunicorn/glogging.py#L88

इस मुद्दे के लिए प्रेरणा लॉगस्टैश में निम्नलिखित ग्रोक कथन है:

grok { match => { "message" => "\[(?<gunicorn.time>%{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})? %{ISO8601_TIMEZONE})\] \[%{NUMBER:[gunicorn][worker_id]}\] \[%{LOGLEVEL:[gunicorn][level]}\] %{GREEDYDATA:[gunicorn][message]}" } remove_field => "message" }

यदि दिनांक प्रारूप में समय और समय क्षेत्र के बीच कोई स्थान नहीं होता तो निम्नलिखित कथन इसे काट देता:

grok { match => { "message" => "\[%{TIMESTAMP_ISO8601:[gunicorn][time]}\] \[%{NUMBER:[gunicorn][worker_id]}\] \[%{LOGLEVEL:[gunicorn][level]}\] %{GREEDYDATA:[gunicorn][message]}" } remove_field => "message" }

मैं तर्क दूंगा कि एक मानक दिनांक प्रारूप डिफ़ॉल्ट कॉन्फ़िगरेशन के लिए बेहतर अनुकूल होगा। मुझे लगता है कि एक अतिरिक्त जगह जोड़ने से कोई मूल्य नहीं जुड़ता है बल्कि इसके बजाय समस्याएं पैदा होती हैं। या तो पूरे डिफ़ॉल्ट लॉगकॉन्फिग को बदलना होगा, जो अत्यधिक है, या इसे पूरा करने के लिए लॉग पार्सर्स में कस्टम एक्सप्रेशन लिखना है।

Improvement Discussion FeaturLogging

स्रोत

kozmaz87

सबसे उपयोगी टिप्पणी

ठीक है तो इसका मतलब यह है कि लॉगस्टैश में ग्रोक को उदार के बजाय सख्त पैटर्न के साथ प्रीलोड किया जाता है। मैंने पहले बीबीसी/ईबीयू में मानकों के लोगों के साथ काम किया है और मुझे इस तरह के भयानक शब्द याद हैं। पठनीयता के लिए "(कहते हैं) एक अंतरिक्ष चरित्र" यह लागू नहीं है .... वह चरित्र क्या है? बेशक आप इस बिंदु पर किसी भी चरित्र को अनुमति दे सकते हैं और यह ठीक नहीं है। तो लोगस्टैश के लोगों ने इसे टी या स्पेस होने के लिए निम्नलिखित तरीके से लागू किया

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

इसके अलावा यह वह नहीं है जिसके बारे में मुद्दा था। समस्या किस बारे में थी वह समयक्षेत्र प्रत्यय है जिसमें एक स्थान है जिसे मानक अनुमति नहीं देता है।

तो नहीं, दुर्भाग्य से यह प्रारूप आम नहीं है। यह प्रारूप गनिकोर्न के लिए विशिष्ट अपरंपरागत है। मुझे पता है कि यह कितना बेवकूफी भरा लगता है कि हम एक स्थान के बारे में बहस कर रहे हैं, लेकिन जब भाषाओं और ऑटोमोटन सिंटैक्स की बात आती है तो सब कुछ होता है।

kozmaz87 13 अग॰ 2018

👍2

सभी 34 टिप्पणियाँ

दिनांक प्रारूप सामान्य लॉग प्रारूप का अनुसरण करता है: https://en.wikipedia.org/wiki/Common_Log_Format

tilgovi 3 मई 2018

ओह, मेरी माफ़ी। मेरी प्रतिक्रिया एक्सेस लॉग प्रारूप के बारे में है। यह रिपोर्ट त्रुटि लॉग प्रारूप के बारे में है।

tilgovi 3 मई 2018

ऐसा लगता है कि आप %{DATESTAMP} %{ISO8601_TIMEZONE} का उपयोग कर सकते हैं

tilgovi 3 मई 2018

19.x के लिए कोई भी बदलाव करने में बहुत देर हो चुकी है। यह बहुत सारे लॉगिंग उपयोग को तोड़ देगा। क्या यह कुछ ऐसा है जिसे हम अगले प्रमुख संस्करण में बदलना चाहते हैं?

benoitc 26 मई 2018

@tilgovi तो क्या यह कुछ चाहिए था?

बहुत सी परिनियोजित प्रणाली वर्तमान स्वरूप पर निर्भर करती है। मुझे चिंता है कि यह एक बहुत बड़ा परिवर्तन है जो अधिक मूल्य नहीं लाता है क्योंकि सिस्टम जैसे लॉग स्टैश में इसके बारे में नियम हमेशा लिखा जा सकता है। विचार?

benoitc 4 जुल॰ 2018

एक संभावित समझौता एक स्विच और बहिष्करण हो सकता है। आप विषम (हालांकि इतना थोड़ा) दिनांक प्रारूप को चरणबद्ध तरीके से समाप्त करना शुरू कर सकते हैं जो मानकों का पालन नहीं कर रहा है और उपयोगकर्ता को एक निश्चित लॉग लाइन प्रारूप में स्विच प्रदान करता है। मुझे पता है कि मैं अजगर के माध्यम से लकड़हारे को ओवरराइड कर सकता हूं, लेकिन चूंकि गनिकोर्न अपनी प्रतिस्पर्धी सेटिंग्स के साथ आता है, इसलिए यह मेरी पसंदीदा पसंद नहीं होगी: डीआई एक ओसीडी व्यक्ति नहीं है, लेकिन एक ग्रोक क्वेरी खाना बनाना एक आधुनिक प्रकार की यातना है, खासकर जब अंतर आप एक स्थान के लिए लेखांकन कर रहे हैं: डी और फिर यह डेवलपर पर निर्भर है कि आवश्यक मैच से अधिक समय तक कुछ भी बदलना चाहिए। यह दुनिया का अंत नहीं है अगर किसी को करना है, लेकिन हम बग्स को ठीक करते रहते हैं, भले ही लोग बग्गी सॉफ़्टवेयर पर भरोसा करते हैं ... मुझे यही लगता है ... सुनिश्चित नहीं है कि सवाल मुझ पर इंगित किया गया था ...

kozmaz87 16 जुल॰ 2018

हम R20 के लिए डिफ़ॉल्ट को बदलने पर विचार कर सकते हैं।

tilgovi 16 जुल॰ 2018

यह प्रारूप वास्तव में काफी सामान्य है। RFC 3339 में इसके बारे में एक नोट है:

नोट: आईएसओ 8601 दिनांक और समय को "टी" से अलग करके परिभाषित करता है। इस सिंटैक्स का उपयोग करने वाले एप्लिकेशन, पठनीयता के लिए, एक स्पेस कैरेक्टर (जैसे) से अलग एक पूर्ण-तिथि और पूर्णकालिक निर्दिष्ट करने के लिए चुन सकते हैं।

त्रुटि लॉग कमांड लाइन पर भी मुद्रित होता है और इसे मानव द्वारा पढ़ा जाना चाहिए और मैं इसे उसी तरह रखना चाहता हूं। क्या टाइमज़ोन प्रारूप के साथ कोई समस्या है?

benoitc 17 जुल॰ 2018

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

kozmaz87 13 अग॰ 2018

👍2

यह मददगार है, @ kozmaz87। कल्पना में खुदाई के लिए धन्यवाद।

tilgovi 13 अग॰ 2018

लेकिन चूंकि हम यहां हैं, इसलिए मैं एक्सेस लॉग फॉर्मेट की ओर भी इशारा करना चाहूंगा, जो और भी बुरा है। मैंने कोड में किसी भी स्थान को खोजने का प्रबंधन भी नहीं किया जहां से यह आ रहा है ... यह कुछ बहुत ही अस्पष्ट कॉन्फ़िगरेशन तंत्र से बनाया गया है। कहीं और से सौंपा। मैंने जांच करने के लिए कोड चेकआउट नहीं किया लेकिन यह इस आउटपुट का उत्पादन करता है:

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

बंदूकधारी दस्तावेज़ों को देखते हुए हम सीखते हैं कि इस लॉग का दूसरा भाग किसी भी कारण से '-' है ... तीसरा उपयोगकर्ता माना जाता है, जो '-' का मूल्यांकन भी कर रहा है, यह सुनिश्चित नहीं है कि यह प्यारा क्यों और फिर आता है दिनांक प्रारूप जहां घंटे की शादी ':' द्वारा की जाती है और निश्चित रूप से पसंदीदा स्थान ने टाइमज़ोन प्रत्यय को फिर से अलग कर दिया। लेकिन चारों ओर खुदाई करने के बाद मैंने पाया कि इस तरह से nginx इसे लॉग करता है, इसलिए मुझे लगता है कि यह वह जगह है जहाँ से इस स्पेस से अलग टाइमज़ोन चीज़ nginx एक्सेस लॉग की नकल करने की कोशिश कर रही है। HAProxy इसका भी उपयोग करता है सिवाय इसके कि यह टाइमज़ोन प्रत्यय नहीं डालता है ...

लॉगिंग पागल है... कोई मेरे लिए बर्फीले पानी की बाल्टी ले आओ :)

kozmaz87 13 अग॰ 2018

एक्सेस लॉग प्रारूप निश्चित रूप से "सामान्य" है: https://en.wikipedia.org/wiki/Common_Log_Format

tilgovi 13 अग॰ 2018

हालांकि, हम अंत में रेफरर और यूजर एजेंट को जोड़ते हैं। --access-logformat ध्वज का संदर्भ लें: http://docs.gunicorn.org/en/latest/settings.html#access -log-format

tilgovi 13 अग॰ 2018

मुझे इसका एहसास है। मुझे यह मजाकिया लगता है कि दूसरा आइटम एक '-' है: डी ऐसा लगता है कि जिसने भी इसे लागू किया था, उसके पास यह था और बस '-' डाल दिया

kozmaz87 13 अग॰ 2018

मैं वर्तमान लॉग प्रारूप रखूंगा। आईएमओ सामान्य प्रारूप अच्छा है और मुझे सर्वर अपस्ट्रीम में किसी भी बदलाव के बारे में पता नहीं है। विचार? सीसी @tilgovi

benoitc 11 जन॰ 2019

बंप @tilgovi भी @berkerpeksag

benoitc 24 जन॰ 2019

समस्या को बंद करने से ठीक नहीं होगा। जैसा कि @tilgovi ने कहा है, हम [सामान्य लॉग प्रारूप] का उपयोग कर रहे हैं।
https://en.wikipedia.org/wiki/Common_Log_Format।

benoitc 24 जन॰ 2019

👍1

मुझे लगता है कि हम इसे खुला रख सकते हैं। हम त्रुटि लॉग के लिए सामान्य लॉग प्रारूप का उपयोग नहीं कर रहे हैं। सामान्य लॉग प्रारूप एक एक्सेस लॉग प्रारूप है और हम इसे वहां उपयोग करते हैं।

tilgovi 24 जन॰ 2019

दरअसल, कोई बात नहीं। मैंने अभी-अभी दोबारा जांच की है और हम दोनों के लिए समान समय प्रारूप स्ट्रिंग का उपयोग करते हैं। यह मुझे किसी भी विकल्प से बेहतर लगता है। मैं नहीं चाहता कि एक्सेस लॉग और त्रुटि लॉग में अलग-अलग दिनांक प्रारूप हों।

tilgovi 24 जन॰ 2019

मैं अब इस मुद्दे को बेहतर ढंग से समझता हूं और सोचता हूं कि हमें इसे फिर से खोलना चाहिए।

यहाँ डिफ़ॉल्ट सेटिंग्स के साथ Gunicorn से उदाहरण आउटपुट दिया गया है:

[2019-01-25 11:44:34 0800] [22794] [जानकारी] 19.9.0
[2019-01-25 11:44:34 0800] [22794] [सूचना] यहां सुन रहे हैं: http://127.0.0.1:8000 (22794)
[2019-01-25 11:44:34 0800] [22794] [सूचना] कार्यकर्ता का उपयोग करना: सिंक
[2019-01-25 11:44:34 0800] [22797] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 22797
[2019-01-25 11:44:36 0800] [22797] [सूचना] 127.0.0.1 - - [25/जनवरी/2019:11:44:36 0800] "प्राप्त/एचटीटीपी/1.1" 200 14 " -" "कर्ल/7.54.0"

मुद्दा एक्सेस लॉग के सामान्य लॉग प्रारूप को पार्स करने के बारे में नहीं है, यह _entire लॉग लाइन_ को पार्स करने के बारे में है।

लॉग लाइन की शुरुआत में Gunicorn एक टाइमस्टैम्प, pid और स्तर को आउटपुट करता है। एक्सेस लॉग लाइन _also_ में अपने टाइमस्टैम्प के साथ सामान्य लॉग प्रारूप में एक संदेश होता है।

ध्यान दें कि टाइमस्टैम्प एक ही प्रारूप में कैसे नहीं हैं। इस मुद्दे के लिए मूल अनुरोध था कि लॉग लाइन की शुरुआत में टाइमस्टैम्प में कोई स्थान नहीं है _just सामान्य लॉग प्रारूप की तरह।

यह इस तरह दिखेगा:

[25/जनवरी/2019:11:44:34 0800] [22794] [जानकारी] 19.9.0
[25/जनवरी/2019:11:44:34 0800] [22794] [सूचना] यहां सुन रहे हैं: http://127.0.0.1:8000 (22794)
[25/जनवरी/2019:11:44:34 0800] [22794] [सूचना] कार्यकर्ता का उपयोग करना: सिंक
[25/जनवरी/2019:11:44:34 0800] [22797] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 22797
[25/जनवरी/2019:11:44:36 0800] [22797] [सूचना] 127.0.0.1 - - [25/जनवरी/2019:11:44:36 0800] "प्राप्त/एचटीटीपी/1.1" 200 14 "-" "कर्ल/7.54.0"

tilgovi 25 जन॰ 2019

मुझे लगता है कि उत्तर शायद नहीं है, क्योंकि सामान्य लॉग प्रारूप उतना अंतरराष्ट्रीय नहीं है (इसका एक छोटा महीना नाम है)।

हालाँकि, हम प्रत्येक लॉग लाइन की शुरुआत में टाइमस्टैम्प को 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

हालांकि, मैं तैनात सिस्टम को तोड़ने के बारे में बहुत चिंता करता हूं।

tilgovi 25 जन॰ 2019

अच्छी तरह से पार्सिंग/रीफॉर्मेटिंग लॉग आसानी से लॉगस्टैश जैसे टूल को संभाला जा सकता है, इसलिए मुझे यकीन नहीं है कि यह एक मुद्दा है। मैं इसे अभी के लिए ऐसे ही रखूंगा।

अगर लोग एक्सेस लॉग के लिए एक अलग प्रारूप चाहते हैं तो शायद हम इसके लिए एक विशिष्ट पहचानकर्ता जोड़ सकते हैं? इस तरह हम प्रारूप को नहीं तोड़ेंगे। हालाँकि, त्रुटि लॉग एक समस्या है क्योंकि हम उन्हें प्रारूपित करने का कोई तरीका प्रदान नहीं करते हैं। ऐसे मामले में शायद एक पर्यावरण चर ऐसा करेगा?

benoitc 25 जन॰ 2019

मुझे नहीं लगता कि एक्सेस लॉग प्रारूप बदलना चाहिए। यह अभी सामान्य लॉग प्रारूप है और हमारे पास --access-log-format सेटिंग है।

एक्सेस लॉग प्रारूप केवल एक्सेस लॉग के _message_ को प्रारूपित करता है जो हैंडलर को पास हो जाता है। हैंडलर का अपना फॉर्मेटर होता है।

Stdout और stderr पर स्ट्रीम हैंडलर के लिए हमारा डिफ़ॉल्ट फॉर्मेटर शुरुआत में टाइमस्टैम्प लगाता है। इसका मतलब है कि डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ एक्सेस लॉग में _two_ टाइमस्टैम्प हैं: एक शुरुआत में और एक संदेश में।

हैंडलर के लिए फ़ॉर्मेटर बदलने के लिए --logconfig विकल्पों में से किसी एक का उपयोग करने की आवश्यकता होती है (फ़ाइल या निर्देश)।

हमें डिफ़ॉल्ट फॉर्मेटर में ISO8601 टाइमस्टैम्प रखने पर विचार करना चाहिए।

tilgovi 25 जन॰ 2019

पार्सिंग/रीफॉर्मेटिंग लॉग आसानी से लॉगस्टैश जैसे टूल को नियंत्रित किया जा सकता है

हां, लेकिन यह बहुत सुविधाजनक है जब वे उपकरण टाइमस्टैम्प को अंतर्निर्मित पैटर्न के साथ पार्स कर सकते हैं ताकि उपयोगकर्ता को रेगेक्सपी लिखने की आवश्यकता न हो। मूल मुद्दा खोला गया था क्योंकि ग्रोक में ISO8601 टाइमस्टैम्प के लिए एक अंतर्निहित पैटर्न है।

tilgovi 25 जन॰ 2019

@tilgovi मैं अनुकूलता को तोड़ना नहीं चाहता। इसके अलावा एनजीआईएनएक्स आईएसओ 8601 प्रारूप या सामान्य लॉग प्रारूप का उपयोग करके समय निर्धारित करने की संभावना प्रदान करता है:

$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

मैं भी ऐसा ही करूंगा क्योंकि यह विरासत को नहीं तोड़ता। बीटीडब्ल्यू क्या हमें आउटपुट में एक्सेस लॉग लाइन प्रदर्शित नहीं करनी चाहिए? ऐसा लगता है कि हमारे पास पीआईडी के साथ पहला हेडर नहीं होना चाहिए। विचार?

benoitc 25 जन॰ 2019

इसे डिफ़ॉल्ट फॉर्मेटर का हिस्सा बनाने के बारे में मुझे चिंता है कि यह कुछ टूल को तोड़ देता है। कस्टम परिवेश चर TIME_ISO8601=true को बाध्य करने के लिए उसके पास होने के बारे में क्या?

benoitc 25 जन॰ 2019

मैं अनुकूलता को तोड़ना नहीं चाहता।

मैं भी नहीं। मैं केवल टिकट को फिर से खोलना चाहता था क्योंकि मुझे लगता है कि हमने इसे गलत कारण से बंद कर दिया। हम दोनों ने जवाब दिया जैसे कि मुद्दा सामान्य लॉग प्रारूप से बदलना था। समस्या डिफ़ॉल्ट फ़ॉर्मेटर में टाइमस्टैम्प है, न कि एक्सेस लॉग संदेश का प्रारूप। मुझे खुशी है कि हम इस पर और चर्चा कर सकते हैं, लेकिन इसका उत्तर शायद अभी भी कुछ नहीं करना है।

बीटीडब्ल्यू क्या हमें आउटपुट में एक्सेस लॉग लाइन प्रदर्शित नहीं करनी चाहिए? ऐसा लगता है कि हमारे पास पीआईडी के साथ पहला हेडर नहीं होना चाहिए। विचार?

संभव। मुझे यकीन नहीं है।

कस्टम परिवेश चर रखने के बारे में क्या?

शायद ठीक है। उपयोगकर्ता हमेशा उन्नत लॉगिंग कॉन्फ़िगरेशन का उपयोग करके लॉग को पूरी तरह से नियंत्रित कर सकता है। हम सीएलआई के लिए कुछ सेटिंग्स को सरल बनाने की कोशिश करते हैं, जैसे --log-level , ताकि उपयोगकर्ताओं को कॉन्फ़िगरेशन फ़ाइलों का उपयोग न करना पड़े। शायद हम --log-date-format जोड़ सकते हैं? यह iso8601 जैसे प्रतीकात्मक तारों को भी पहचान सकता है। यह सेटिंग उन उपयोगकर्ताओं के लिए होगी जो --log-config या log_config_dict का उपयोग नहीं करना चाहते हैं।

tilgovi 25 जन॰ 2019

👍1

@tilgovi इस बीच 20.0 रिलीज प्रारूप में बदलाव के लिए एक अच्छा समय है क्योंकि हम अजगर 2 के साथ संगतता को तोड़ रहे हैं।

मुझे लगता है कि किसी भी विरासत के बारे में मुझे और अधिक चिंता यह है कि आईएसओ 8601 मानव आंखों के लिए विश्लेषण करना मुश्किल है और मेरे सहित बहुत से लोग कंसोल का उपयोग यह देखने के अवसर के रूप में कर रहे हैं कि क्या हो रहा है।

मैं निम्नलिखित सुझाव देना चाहूंगा:

[ ] एक विकल्प जोड़ें -iso8601 जो इस प्रारूप का उपयोग करने के लिए stdout और stderr लॉग को बाध्य करता है (जैसे आप सुझाव दे रहे हैं)
[ ] एक्सेस लॉग में इस प्रारूप के तहत समय प्रदर्शित करने के लिए प्रारूप में एक विकल्प जोड़ें

जब हम यहां हैं तो शायद हमारे पास उस समय के लिए UTC का उपयोग करने के लिए -utc विकल्प भी हो सकता है? विचार?

benoitc 26 जन॰ 2019

बस यह सुनिश्चित करने के लिए, यह प्रस्तावित अंतर होगा यदि हमने अभी डिफ़ॉल्ट को बदल दिया है:

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"

tilgovi 28 जन॰ 2019

मुझे लगता है कि एक्सेस लॉग टोकन में ISO8601 डेटाटाइम का उपयोग करने का एक विकल्प दिलचस्प है, लेकिन यह इस मुद्दे से प्रेरित होने से अलग है।

tilgovi 28 जन॰ 2019

वैसे, मैं इसके बारे में दृढ़ता से महसूस नहीं करता। मैं केवल इस मुद्दे का सटीक रूप से प्रतिनिधित्व करना चाहता हूं।

tilgovi 28 जन॰ 2019

हमें शायद इसके बारे में थोड़ा और सोचने की जरूरत है। मैं इसे 20.1 पर स्थगित कर रहा हूं ताकि हमें कुछ समय दिया जा सके।

benoitc 27 सित॰ 2019

प्रिय डेवेल्स,
मुझे अनुरोध हानि समस्या का सामना करना पड़ रहा है (इसका Gunicorn से कोई लेना-देना नहीं है)। मुझे माइक्रोसेकंड सहित सटीक टाइमस्टैम्प प्राप्त करने में सक्षम होना चाहिए, जैसा कि इस उदाहरण में हमारे अपाचे सर्वरों में से एक से है: 2019-10-30 14:27:16.960421 । यह एक अच्छा वृद्धि होगी, इस पर विचार करने के लिए thx।

cbueche 30 अक्तू॰ 2019

👍1

कोई उम्मीद है अगर झंडा, log-date-format iso8601 , गनिकोर्न के अगले छंद में उपलब्ध होगा?

ianhundere 7 जुल॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Gunicorn: Gunicorn डिफ़ॉल्ट त्रुटि लॉगिंग दिनांक स्वरूप मानक ISO8601 नहीं है

सबसे उपयोगी टिप्पणी

सभी 34 टिप्पणियाँ

संबंधित मुद्दों