ระดับการบันทึก - การย้อนกลับ - กฎของหัวแม่มือเพื่อกำหนดระดับการบันทึก

ฉันใช้logbackในโครงการปัจจุบันของฉัน

มีการบันทึกหกระดับ: ข้อผิดพลาด TRACE DEBUG INFO WARN OFF

ฉันกำลังมองหากฎง่ายๆเพื่อกำหนดระดับการบันทึกสำหรับกิจกรรมทั่วไป ตัวอย่างเช่นหากเธรดถูกล็อคควรตั้งค่าข้อความบันทึกเป็นระดับดีบักหรือระดับข้อมูล หรือหากมีการใช้ซ็อกเก็ตควรระบุรหัสเฉพาะของมันที่ระดับการดีบักหรือระดับการติดตาม

ฉันจะขอบคุณคำตอบด้วยตัวอย่างเพิ่มเติมสำหรับแต่ละระดับการบันทึก

ฉันส่วนใหญ่สร้างระบบขนาดใหญ่ที่มีความพร้อมใช้งานสูงดังนั้นคำตอบของฉันจึงมีอคติต่อการมองจากมุมมองการสนับสนุนการผลิต ที่กล่าวว่าเรากำหนดคร่าว ๆ ดังนี้

• ข้อผิดพลาด : ระบบอยู่ในความทุกข์ลูกค้าอาจได้รับผลกระทบ (หรือเร็ว ๆ นี้) และการแก้ไขอาจต้องมีการแทรกแซงของมนุษย์ "กฎ 2AM" มีผลบังคับใช้ที่นี่ - หากคุณมีการโทรติดต่อคุณต้องการที่จะปลุกตอน 2AM หรือไม่หากเงื่อนไขนี้เกิดขึ้น? ถ้าใช่ให้บันทึกเป็น "ข้อผิดพลาด"

• คำเตือน : มีเหตุการณ์ทางเทคนิคหรือธุรกิจที่ไม่คาดคิดเกิดขึ้นลูกค้าอาจได้รับผลกระทบ แต่อาจไม่จำเป็นต้องมีการแทรกแซงจากมนุษย์ในทันที คนโทรไม่ได้ถูกเรียกในทันที แต่บุคลากรฝ่ายสนับสนุนจะต้องการทบทวนปัญหาเหล่านี้โดยเร็วเพื่อให้เข้าใจว่าผลกระทบคืออะไร โดยทั่วไปปัญหาใด ๆ ที่ต้องติดตาม แต่อาจไม่ต้องการการแทรกแซงทันที

• ข้อมูล : สิ่งที่เราต้องการเห็นในปริมาณสูงในกรณีที่เราจำเป็นต้องวิเคราะห์ปัญหาทางนิติเวช เหตุการณ์วงจรชีวิตของระบบ (ระบบเริ่ม, หยุด) ไปที่นี่ เหตุการณ์รอบ "เซสชัน" (เข้าสู่ระบบออกจากระบบและอื่น ๆ ) ไปที่นี่ เหตุการณ์ขอบเขตที่สำคัญควรได้รับการพิจารณาเช่นกัน (เช่นการเรียกฐานข้อมูลการเรียก API ระยะไกล) ข้อยกเว้นทางธุรกิจทั่วไปสามารถไปที่นี่ได้ (เช่นการเข้าสู่ระบบล้มเหลวเนื่องจากข้อมูลประจำตัวไม่ดี) กิจกรรมอื่น ๆ ที่คุณคิดว่าคุณจะต้องเห็นในการผลิตในปริมาณมากไปที่นี่

• แก้ปัญหา : ทุกอย่างที่ไม่ได้ทำให้ "ข้อมูล" ถูกตัด ... ข้อความใด ๆ ที่เป็นประโยชน์ในการติดตามการไหลผ่านระบบและการแยกปัญหาโดยเฉพาะในช่วงการพัฒนาและขั้นตอนการควบคุมคุณภาพ เราใช้บันทึกระดับ "ดีบั๊ก" สำหรับการเข้า / ออกของวิธีการที่ไม่สำคัญที่สุดและทำเครื่องหมายเหตุการณ์ที่น่าสนใจและจุดตัดสินใจภายในวิธีการ

• การสืบค้นกลับ : เราไม่ได้ใช้สิ่งนี้บ่อยนัก แต่นี่จะเป็นรายละเอียดที่มากและเป็นไปได้มากที่คุณไม่ต้องการเปิดใช้งานแม้ในระหว่างการพัฒนาปกติ ตัวอย่างรวมถึงการทิ้งลำดับชั้นของวัตถุแบบเต็มการบันทึกสถานะบางอย่างในระหว่างการวนซ้ำขนาดใหญ่ทุกครั้ง

หรือมีความสำคัญมากกว่าการเลือกระดับการบันทึกที่ถูกต้องคือการทำให้แน่ใจว่าบันทึกมีความหมายและมีบริบทที่จำเป็น ตัวอย่างเช่นคุณมักจะต้องการรวม ID เธรดในบันทึกเพื่อให้คุณสามารถติดตามเธรดเดี่ยวได้หากจำเป็น คุณอาจต้องการใช้กลไกในการเชื่อมโยงข้อมูลธุรกิจ (เช่น ID ผู้ใช้) กับเธรดเพื่อให้บันทึกได้เช่นกัน ในข้อความบันทึกของคุณคุณจะต้องรวมข้อมูลที่เพียงพอเพื่อให้แน่ใจว่าข้อความสามารถดำเนินการได้ บันทึกเช่น "จับข้อยกเว้น FileNotFound" ไม่เป็นประโยชน์มาก ข้อความที่ดีกว่าคือ "พบข้อยกเว้น FileNotFound ขณะพยายามเปิดไฟล์กำหนดค่า: /usr/local/app/somefile.txt userId = 12344"

นอกจากนี้ยังมีคำแนะนำในการบันทึกที่ดีจำนวนมาก ... ตัวอย่างเช่นนี่เป็นตัวอย่างข้อมูลที่แก้ไขจากJCL (Jakarta Commons Logging) :

• ข้อผิดพลาด - ข้อผิดพลาดรันไทม์อื่น ๆ หรือเงื่อนไขที่ไม่คาดคิด คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลสถานะ
• คำเตือน - การใช้ API ที่เลิกใช้แล้วการใช้ API ไม่ดีข้อผิดพลาด 'เกือบ' สถานการณ์รันไทม์อื่น ๆ ที่ไม่พึงประสงค์หรือไม่คาดคิด แต่ไม่จำเป็นว่า "ผิด" คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลสถานะ
• ข้อมูล - กิจกรรมรันไทม์ที่น่าสนใจ (เริ่มต้น / ปิด) คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลดังนั้นควรระมัดระวังและรักษาให้น้อยที่สุด
• debug - ข้อมูลรายละเอียดเกี่ยวกับการไหลผ่านระบบ คาดว่าสิ่งเหล่านี้จะเขียนลงในบันทึกเท่านั้น
• ติดตาม - ข้อมูลรายละเอียดเพิ่มเติม คาดว่าสิ่งเหล่านี้จะเขียนลงในบันทึกเท่านั้น

แนวทางของฉันฉันคิดว่ามาจากการพัฒนามากกว่ามุมมองการทำงานคือ:

• ข้อผิดพลาดหมายความว่าการดำเนินการของงานบางอย่างอาจไม่เสร็จสมบูรณ์ ไม่สามารถส่งอีเมลได้ไม่สามารถแสดงหน้าเว็บได้ข้อมูลบางอย่างไม่สามารถจัดเก็บลงในฐานข้อมูลได้เช่นนั้น มีบางอย่างผิดพลาดไปอย่างแน่นอน
• คำเตือนหมายถึงสิ่งที่ไม่คาดคิดเกิดขึ้น แต่การดำเนินการนั้นสามารถดำเนินต่อไปได้อาจอยู่ในโหมดที่เสื่อมโทรม ไฟล์การกำหนดค่าขาดหายไป แต่มีการใช้ค่าเริ่มต้นราคาถูกคำนวณเป็นค่าลบดังนั้นจึงถูกบีบให้เหลือศูนย์ ฯลฯ มีบางอย่างไม่ถูกต้อง แต่ยังไม่ได้ผิดอย่างถูกต้อง - คำเตือนมักเป็นสัญญาณว่าจะมี ข้อผิดพลาดเร็ว ๆ นี้
• ข้อมูลหมายถึงสิ่งที่ปกติ แต่สำคัญเกิดขึ้น; ระบบเริ่มทำงานระบบหยุดทำงานการอัพเดทคลังโฆษณารายวัน ฯลฯ ไม่ควรมีฝนตกหนักอย่างต่อเนื่อง
• Debugหมายถึงสิ่งที่ปกติและไม่มีนัยสำคัญเกิดขึ้น ผู้ใช้รายใหม่เข้ามาในไซต์หน้าเว็บถูกแสดงคำสั่งซื้อราคาที่ได้รับการปรับปรุง นี่คือสิ่งที่ไม่รวมอยู่ในข้อมูลเพราะจะมีมากเกินไป
• การติดตามคือสิ่งที่ฉันไม่เคยใช้จริง ๆ

วิธีนี้อาจช่วยได้เป็นอย่างมากเช่นกันในการเข้าใจว่าการร้องขอการบันทึก(จากรหัส) ในระดับหนึ่งจะส่งผลให้ถูกบันทึกจริงหรือไม่เนื่องจากระดับการบันทึกที่มีประสิทธิภาพที่การปรับใช้ถูกกำหนดด้วย ตัดสินใจเลือกระดับที่มีประสิทธิภาพที่คุณต้องการกำหนดค่าการนำไปใช้งานจากคำตอบอื่น ๆ ที่นี่จากนั้นอ้างถึงสิ่งนี้เพื่อดูว่าคำขอบันทึกการทำงานเฉพาะจากรหัสของคุณจะถูกบันทึกไว้หรือไม่ ...

ตัวอย่าง :

• "บรรทัดรหัสการบันทึกที่บันทึกที่ WARN จะได้รับจริงในการปรับใช้ของฉันที่กำหนดค่าด้วยข้อผิดพลาด" ตารางบอกว่าไม่
• "บรรทัดรหัสการบันทึกที่บันทึกที่ WARN จะได้รับจริงในการปรับใช้ของฉันที่กำหนดค่าด้วย DEBUG หรือไม่" ตารางพูดว่าใช่

จากเอกสารการย้อนกลับ :

ในอีกวิธีกราฟิกนี่คือวิธีการทำงานของกฎการเลือก ในตารางต่อไปนี้ส่วนหัวแนวตั้งแสดงระดับของการร้องขอการบันทึกที่กำหนดโดย p ในขณะที่ส่วนหัวแนวนอนแสดงระดับที่มีประสิทธิภาพของตัวบันทึกที่กำหนดโดย q จุดตัดของแถว (คำขอระดับ) และคอลัมน์ (ระดับประสิทธิผล) คือบูลีนที่เกิดจากกฎการเลือกพื้นฐาน

ดังนั้นรหัสบรรทัดที่ร้องขอการบันทึกจะได้รับการบันทึกเท่านั้นหากระดับการบันทึกที่มีประสิทธิภาพของการปรับใช้นั้นน้อยกว่าหรือเท่ากับระดับความรุนแรงที่ร้องขอของโค้ดบรรทัดนั้น

ฉันตอบว่าสิ่งนี้มาจากสถาปัตยกรรมที่อิงองค์ประกอบซึ่งองค์กรอาจใช้องค์ประกอบหลายอย่างที่อาจพึ่งพาซึ่งกันและกัน ในระหว่างความล้มเหลวในการแพร่กระจายระดับการบันทึกควรช่วยในการระบุว่าองค์ประกอบใดบ้างที่ได้รับผลกระทบและสาเหตุใดเป็นสาเหตุ

• ข้อผิดพลาด - องค์ประกอบนี้มีความล้มเหลวและสาเหตุเชื่อว่าเป็นแบบภายใน (ข้อยกเว้นภายใน, ไม่สามารถจัดการได้, ความล้มเหลวของการพึ่งพา encapsulated ... เช่นฐานข้อมูลตัวอย่างส่วนที่เหลือจะได้รับข้อผิดพลาด 4xx จากการพึ่งพา) เอาฉัน (ผู้ดูแลส่วนประกอบนี้) ออกจากเตียง

• คำเตือน - องค์ประกอบนี้มีความล้มเหลวที่เชื่อว่าเกิดจากองค์ประกอบที่ต้องพึ่งพา (ตัวอย่าง REST จะเป็นสถานะ 5xx จากการพึ่งพา) นำผู้ดูแลส่วนประกอบนั้นออกจากเตียง

• INFO - สิ่งอื่นใดที่เราต้องการไปหาผู้ดำเนินการ หากคุณตัดสินใจที่จะบันทึกเส้นทางที่มีความสุขฉันขอแนะนำให้ จำกัด ข้อความบันทึก 1 รายการต่อการดำเนินการที่สำคัญ (เช่นต่อคำขอ HTTP ขาเข้า)

สำหรับข้อความบันทึกทั้งหมดต้องแน่ใจว่าได้บันทึกบริบทที่เป็นประโยชน์ (และจัดลำดับความสำคัญในการทำให้ข้อความที่มนุษย์อ่านได้ / มีประโยชน์แทนที่จะมีรีมของ "รหัสข้อผิดพลาด")

• DEBUG (และด้านล่าง) - ไม่ควรใช้เลย (และไม่แน่นอนในการผลิต) ในการพัฒนาฉันจะแนะนำให้ใช้การรวมกันของ TDD และการแก้จุดบกพร่อง (ที่จำเป็น) ซึ่งตรงข้ามกับรหัสมลพิษที่มีคำสั่งบันทึก ในการผลิตการบันทึกข้อมูล INFO ข้างต้นรวมกับการวัดอื่น ๆ ควรจะเพียงพอ

วิธีที่ดีในการมองเห็นระดับการบันทึกข้อมูลด้านบนคือการจินตนาการชุดของหน้าจอมอนิเตอร์สำหรับแต่ละองค์ประกอบ เมื่อทุกอย่างทำงานได้ดีจะมีสีเขียวหากส่วนประกอบบันทึกคำเตือนจากนั้นจะเป็นสีส้ม (สีเหลือง) หากมีสิ่งใดบันทึกข้อผิดพลาดจากนั้นจะเป็นสีแดง

ในเหตุการณ์ที่เกิดขึ้นคุณควรมีส่วนประกอบหนึ่ง (สาเหตุสาเหตุ) เป็นสีแดงและส่วนประกอบที่ได้รับผลกระทบทั้งหมดควรเป็นสีส้ม / สีเหลืองอำพัน

ไม่แตกต่างกันสำหรับคำตอบอื่น ๆ กรอบงานของฉันเกือบเหมือนกัน:

1. ข้อผิดพลาด: ข้อผิดพลาดเชิงตรรกะที่สำคัญในแอปพลิเคชันเช่นหมดเวลาเชื่อมต่อฐานข้อมูล สิ่งที่เรียกร้องให้แก้ไขข้อบกพร่องในอนาคตอันใกล้
2. เตือน: ปัญหาที่ไม่ทำลาย แต่สิ่งที่ต้องใส่ใจ ไม่พบหน้าที่ต้องการ
3. ข้อมูล: ใช้ในฟังก์ชั่น / วิธีการบรรทัดแรกเพื่อแสดงขั้นตอนที่ได้รับการเรียกหรือขั้นตอนก็โอเคเหมือนแบบสอบถามแทรกทำ
4. log: ข้อมูลลอจิกเช่นผลลัพธ์ของคำสั่ง if
5. debug: เนื้อหาตัวแปรที่เกี่ยวข้องที่จะรับชมอย่างถาวร