دعنا نتحدث عن التسجيل

هذه المشاركة مستوحاة من موضوع Go Forum الذي أطلقته Nate Finch. يركز هذا المنشور على Go ، لكن إذا تجاوزت هذا ، أعتقد أن الأفكار المقدمة هنا قابلة للتطبيق على نطاق واسع.

لماذا لا يوجد حب؟

لا تحتوي حزمة السجل في Go على مستويات للسجلات ؛ يمكنك إضافة بادئات DEBUG و INFO و WARN و ERROR يدويًا بنفسك. أيضًا ، لا يتمتع نوع المسجل في Go بالقدرة على تمكين أو تعطيل هذه المستويات بشكل منفصل للحزم المحددة. للمقارنة ، دعونا نلقي نظرة على بعض البدائل من مطوري الطرف الثالث.



يحتوي Google glog على مستويات:

• معلومات
• تحذير
• خطأ
• فادح (ينهي البرنامج)

لنلقِ نظرة على مكتبة أخرى ، loggo ، تم تطويرها لـ Juju ، تتوفر مستويات فيها:

• تتبع
• تصحيح
• معلومات
• تحذير
• خطأ
• حرجة

لدى Loggo أيضًا القدرة على ضبط مستوى تفاصيل السجل للحزم المرغوبة بشكل فردي.

فيما يلي مثالان ، تم إنشاؤه بوضوح تحت تأثير المكتبات الأخرى لتسجيل الدخول بلغات أخرى.

في الواقع ، يمكن تتبع أصلهم مرة أخرى إلى syslog (3) ، وربما حتى في وقت سابق. وأعتقد أنهم مخطئون.

أريد أن أتخذ موقفًا مثيرًا للجدل. أعتقد أن جميع مكتبات السجلات سيئة لأنها توفر الكثير من الميزات ؛ مجموعة مذهلة من الميزات التي تذهل المبرمج في الوقت الحالي عندما يحتاج إلى التفكير بوضوح في كيفية التواصل مع القارئ من المستقبل ، مع من سيشاهد هذه المجلات.

أزعم أن حزم السجل الناجحة تتطلب ميزات أقل بكثير ، وبالطبع مستويات أقل.

دعنا نتحدث عن التحذيرات (تحذير)

لنبدأ مع أبسط. لا أحد يحتاج إلى مستوى سجل تحذير (تحذير).

لا أحد يقرأ التحذيرات ، لأنه بالتعريف لم يحدث شيء سيء. ربما حدث خطأ ما في المستقبل ، لكن يبدو أنه شخص آخر ، وليس مشكلتي.

بالإضافة إلى ذلك ، إذا كنت تستخدم نوعا من التسجيل متعدد المستويات ، فلماذا تحتاج إلى ضبط مستوى تحذير؟ يمكنك تعيين المستوى إلى INFO أو خطأ. تعيين مستوى تحذير يعني أنك ربما تبلغ عن أخطاء على مستوى تحذير.

استبعد مستوى التحذير - فهذه رسالة إعلامية أو خطأ.

دعونا نتحدث عن مستوى الخطأ القاتل

يسجل مستوى FATAL فعليًا الرسالة ، ثم يقوم باستدعاء os.Exit (1). من حيث المبدأ ، هذا يعني:

• لا يتم تنفيذ التعبيرات المؤجلة في إجراءات أخرى (goroutines) ؛
• لا يتم مسح المخازن المؤقتة ؛
• لا يتم حذف الملفات والدلائل المؤقتة.

في الجوهر ، log.Fatal أقل مطبعيًا ، لكنه معادل للدلالة على الذعر.

من المقبول عمومًا أن المكتبات يجب ألا تستخدم الذعر 1 ، ولكن إذا كان استدعاء log.Fatal2 له نفس التأثير ، فيجب أيضًا تعطيله.

إن الافتراض بأن مشكلة التنظيف هذه يمكن حلها عن طريق تسجيل معالجات إيقاف التشغيل في المسجل توفر علاقة وثيقة بين المسجل المستخدم وكل مكان تحدث فيه عمليات التنظيف. كما أنه ينتهك الفصل بين المصالح.

لا تسجل الرسائل بمستوى FATAL ، تفضل بإرجاع خطأ إلى المتصل بدلاً من ذلك. إذا وصل الخطأ إلى main.main ، فهذا هو المكان المناسب لإجراء أي تنظيف قبل إغلاق البرنامج.

دعنا نتحدث عن الخطأ (مستوى الخطأ)

ترتبط معالجة الأخطاء والتسجيل ارتباطًا وثيقًا ، لذلك ، للوهلة الأولى ، يجب تبرير تسجيل مستوى الخطأ (ERROR) بسهولة. انا لا اوافق

في Go ، إذا كانت استدعاء دالة أو طريقة تُرجع قيمة خطأ ، فسيكون لديك بالفعل خياران:

• التعامل مع الخطأ.
• إرجاع خطأ إلى المتصل به. يمكنك بشكل جميل التفاف خطأ في تغليف الهدايا (التفاف) ، ولكن هذا ليس مهمًا لهذه المناقشة.

إذا قررت معالجة الخطأ عن طريق كتابته في السجل ، فبالتأكيد ، لم يعد خطأ - لقد قمت بمعالجته. فعل تسجيل الخطأ نفسه هو معالجة الخطأ ؛ لذلك ، لم يعد من المستحسن كتابته إلى السجل كخطأ.

اسمح لي أن أقنعك بهذه الشفرة:

err := somethingHard() if err != nil { log.Error("oops, something was too hard", err) return err // what is this, Java ? } 

يجب ألا تسجل أي شيء على مستوى الخطأ لأنه يجب عليك إما معالجة الخطأ أو تمريره إلى المتصل.

أنت بحاجة إلى أن تفهم بوضوح ، أنا لا أقول أنه لا يجب أن تكتب للسجل أن تغيير الحالة قد حدث:

 if err := planA(); err != nil { log.Infof("could't open the foo file, continuing with plan b: %v", err) planB() } 

ولكن في الواقع ، log.Info و log.Error لها نفس الهدف.

أنا لا أقول "لا تسجل الأخطاء"! بدلاً من ذلك ، أطرح السؤال ، ما هو أصغر واجهة برمجة تطبيقات ممكنة للتسجيل؟ وعندما يتعلق الأمر بالأخطاء ، أعتقد أن الغالبية العظمى من الأشياء المسجلة على مستوى الخطأ تتم ببساطة لأنها مرتبطة بالخطأ. في الواقع ، فهي مفيدة فقط ، لذلك يمكننا إزالة تسجيل مستوى الخطأ (ERROR) من API الخاصة بنا.

ما تبقى؟

لقد استبعدنا تحذير ، وجادلنا بأنه لا ينبغي تسجيل أي شيء على مستوى الخطأ (خطأ) ، وأظهرنا أن تطبيق المستوى الأعلى فقط يجب أن يكون لديه نوع من السلوك. سلوك فادح. ما تبقى؟

أعتقد أن هناك شيئين فقط يجب عليك تسجيل الدخول:

• الأشياء التي يهتم بها المطورون عند قيامهم بتطوير برنامج أو تصحيحه ؛
• الأشياء التي يهتم بها المستخدمون عند استخدام البرنامج.

من الواضح أن هذه هي مستويات التصحيح (DEBUG) والإعلامية (INFO) ، على التوالي.

يجب أن تكتب log.Info هذا السطر إلى إخراج السجل. لا ينبغي تعطيله ، حيث يجب على المستخدم فقط معرفة ما هو مفيد له. في حالة حدوث خطأ لا يمكن معالجته ، يجب أن يظهر في main.main حيث يتم إنهاء البرنامج. الإزعاج البسيط المتمثل في الحاجة إلى إدراج بادئة FATAL قبل رسالة السجل النهائية أو الكتابة مباشرة إلى os.Stderr باستخدام fmt.Fprintf ليس سببًا كافياً لتوسيع الحزمة باستخدام log.Fatal.

log.Debug ، هذا هو مسألة مختلفة تماما. يحتاج المطور أو مهندس الدعم إلى التحكم في البرنامج. أثناء التطوير ، يجب أن تكون تعبيرات debug عديدة دون اللجوء إلى مستوى التتبع أو debug2 (تعرف من أنت). يجب أن تدعم حزمة التسجيل التحكم الدقيق لتمكين أو تعطيل تعبيرات التصحيح ، للحزم المطلوبة في الحزمة ، أو ربما في نطاق أضيق.

الخاتمة

إذا كان استطلاعًا على Twitter ، فسأطلب منك الاختيار بين

• تسجيل هو المهم
• تسجيل الصعب

ولكن الحقيقة هي أن التسجيل على حد سواء. يجب أن يكون حل هذه المشكلة هو التقليل من الانحرافات غير الضرورية وتقليلها بلا رحمة.

ما رايك هل هو باهظ بما فيه الكفاية للعمل ، أم أنها مجرد باهظة؟

ملاحظات

قد تستخدم بعض المكتبات حالة من الذعر / الاسترداد كآلية لتدفق التحكم الداخلي ، لكن الشعار الرئيسي هو أنها يجب ألا تسمح لعمليات تدفق التحكم هذه بالتسرب من حدود الحزمة.

ومن المفارقات أنه على الرغم من أنه لا يحتوي على مستوى إخراج DEBUG ، فإن حزمة تسجيل الدخول القياسية تحتوي على ميزات Fatal و Panic. في هذه الحزمة ، يتجاوز عدد الوظائف التي تؤدي إلى الإنهاء المفاجئ للبرنامج عدد الوظائف التي لا تؤدي إلى ذلك.

عن المؤلف

مؤلف هذا المقال ، ديف تشيني ، مؤلف العديد من الحزم الشائعة لـ Go ، مثل github.com/pkg/errors و github.com/davecheney/httpstat . يمكنك تقييم سلطة المؤلف وتجربته بنفسك.

من المترجم

يشعر الكثير من المطورين بالقلق إزاء التسجيل ، وقد ناقش بعضهم إضافة واجهة Logger إلى مكتبة Go القياسية لتبسيط عملية التسجيل في المكتبات وتحفيز مطوريها بهذه الطريقة. وضع الرجال حتى اقتراحهم وطرحوا الورقة للمناقشة.

بالإضافة إلى انعكاس العرض التقديمي هل نحن بحاجة إلى مسجل جديد وما ينبغي أن يكون؟ من كريس هاينز.

هناك عدة تطبيقات لأفكار go-log من Dave وقليلًا من الموضوع حول مشكلة مستوى الخطأ وحزمة logr أكثر تفصيلًا.