ทำไมระดับ TRACE ถึงมีอยู่และฉันควรใช้เมื่อใดแทนที่จะใช้ DEBUG

ใน Log4J, Slf4J และเฟรมเวิร์กการบันทึกอื่น ๆ อีกสองสามรายการใน Java คุณมีระดับ "developper" สองระดับสำหรับการบันทึก:

• DEBUG
• ติดตาม

ฉันเข้าใจสิ่งที่ DEBUG ทำเพราะคำอธิบายนั้นชัดเจน:

ระดับ DEBUG กำหนดเหตุการณ์ข้อมูลที่ละเอียดซึ่งมีประโยชน์มากที่สุดในการดีบักแอปพลิเคชัน

แต่ระดับ TRACE นั้นไม่เฉพาะเจาะจงมากเกี่ยวกับกรณีการใช้งาน:

ระดับ TRACE กำหนดเหตุการณ์ข้อมูลที่ละเอียดกว่า DEBUG

(ที่มา: log4J JavaDoc )

สิ่งนี้ไม่ได้บอกวิธีการใช้ TRACE ที่น่าสนใจนี้ไม่ได้เป็นระดับความรุนแรงที่กำหนดไว้ในมาตรฐาน syslog Googling สำหรับความแตกต่างระหว่าง TRACE และ DEBUG ดูเหมือนจะกลับมา "ใช้ DEBUG, โอ้และมี TRACE ด้วย" ฉันไม่พบกรณีการใช้งานเฉพาะสำหรับระดับ TRACE สิ่งที่ดีที่สุดที่ฉันสามารถหาได้คือหน้าวิกิเก่านี้กำลังถกกันถึงข้อดีของการมีอยู่

ในฐานะสถาปนิกผู้นี้ได้ยกธงและคำถามมากมายในหัวของฉัน หากผู้พัฒนารายย่อยขอให้ฉันเพิ่ม TRACE ลงในสถาปัตยกรรมของฉันฉันจะทิ้งระเบิดด้วยคำถาม:

• ตัวอย่างของข้อมูลใดบ้างที่ควรบันทึกด้วย TRACE และไม่ใช่ DEBUG
• ฉันต้องแก้ไขปัญหาใดโดยการบันทึกข้อมูลนั้น
• ในตัวอย่างเหล่านั้นคุณสมบัติของข้อมูลที่บันทึกซึ่งแยกแยะได้อย่างชัดเจนระหว่างการบันทึกในระดับ TRACE แทนที่จะเป็นระดับ DEBUG คืออะไร
• ทำไมข้อมูลนั้นต้องผ่านโครงสร้างพื้นฐานบันทึก
  • ประโยชน์ของการเก็บข้อมูลไว้ในสมุดบันทึกไม่ใช่การใช้เพียงSystem.out.printlnใด?
  • เหตุใดจึงดีกว่าที่จะใช้บันทึกสำหรับสิ่งนี้แทนที่จะเป็นดีบักเกอร์
• อะไรคือตัวอย่างที่ยอมรับได้ของการบันทึกในระดับ TRACE
  • อะไรคือผลประโยชน์เฉพาะที่เกิดขึ้นจากการเข้าสู่ระบบที่ระดับ TRACE แทนที่จะเป็น DEBUG ในตัวอย่าง
  • ทำไมสิ่งเหล่านั้นถึงสำคัญ?
  • ในทางกลับกัน: ฉันควรหลีกเลี่ยงปัญหาอะไรบ้างในการเข้าสู่ระบบที่ TRACE แทนที่จะเป็น DEBUG
  • ฉันจะแก้ไขปัญหาเหล่านั้นได้อย่างไร ทำไมการเข้าสู่ระบบในระดับ TRACE จึงดีกว่าโซลูชันอื่น ๆ
• ควรบันทึกคำสั่งบันทึกระดับ TRACE ไว้ในรหัสการผลิตหรือไม่ ทำไม?

แต่เนื่องจากมันมีอยู่ในกรอบงานที่สำคัญที่สุดฉันคิดว่ามันมีประโยชน์สำหรับบางสิ่งบางอย่าง? ดังนั้น ... TRACE สำหรับอะไรและอะไรที่แตกต่างจาก DEBUG

ตัวอย่างของข้อมูลที่ควรบันทึกด้วย TRACE และไม่ใช่ DEBUG คืออะไร

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

โดยทั่วไปแล้วการติดตามจะรวมการดีบักทั้งหมด (เช่นเดียวกับการดีบักที่มีคำเตือนและข้อผิดพลาดทั้งหมด)

ฉันต้องแก้ไขปัญหาใดโดยการบันทึกข้อมูลนั้น

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

ในตัวอย่างเหล่านั้นคุณสมบัติของข้อมูลที่บันทึกซึ่งแยกแยะได้อย่างชัดเจนระหว่างการบันทึกในระดับ TRACE แทนที่จะเป็นระดับ DEBUG คืออะไร

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

การบันทึกระดับการดีบักสามารถเปิดได้เป็นเวลานานโดยไม่ทำให้แอปไม่สามารถใช้งานได้

เหตุใดข้อมูลดังกล่าวจึงต้องผ่านโครงสร้างพื้นฐานบันทึก

มันไม่จำเป็นต้อง เฟรมเวิร์กบางตัวมี tracelogger แยกกัน

โดยปกติแล้วจะสิ้นสุดในบันทึกเนื่องจาก traceloggers และ loggers ปกติมีความต้องการที่คล้ายกันเกี่ยวกับการเขียนไปยังดิสก์ / เครือข่ายการจัดการข้อผิดพลาดการหมุนบันทึก ฯลฯ

เหตุใดจึงดีกว่าที่จะใช้บันทึกสำหรับสิ่งนี้แทนที่จะเป็นดีบักเกอร์

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

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

รับทราบเป็นพิเศษว่า slf4j แนะนำโดยเฉพาะกับการใช้การติดตาม ( http://slf4j.org/faq.html#trace ):

ในระยะสั้นแม้ว่าเราจะยังคงกีดกันการใช้ระดับการติดตามเพราะมีทางเลือกอยู่หรือเพราะในหลาย ๆ กรณีคำขอการติดตามระดับ TRACE นั้นสิ้นเปลืองเนื่องจากผู้คนยังคงขอใช้งานอยู่

โดยส่วนตัวแล้วความคาดหวังของฉันจะเป็นเพียงการติดตามเพื่อบันทึกทุกอย่าง (เช่นแม้กระทั่งสิ่งต่างๆเช่น "ฟังก์ชันป้อน MyFunc พร้อมอาร์กิวเมนต์ A, B, C ในเวลา Y") ข้อเสียของสิ่งนี้คือไม่เพียง แต่จะมีเสียงดังอย่างไม่น่าเชื่อเท่านั้น แต่ยังทำให้เกิดปัญหาพื้นที่ดิสก์ ฉันคาดว่าการบันทึกดังกล่าวจะถูกปิดการใช้งานในระหว่างการดำเนินการตามปกติ ข้อเสียคือสิ่งนี้จะช่วยให้คุณมีระดับของข้อมูลคล้ายกับสิ่งที่คุณจะได้รับเมื่อก้าวผ่านโปรแกรมของคุณในกรณีที่การแนบดีบักเกอร์อาจใช้งานได้น้อยลง

โดยทั่วไปแล้วฉันพบว่าการสืบค้นกลับมักใช้ความพยายามมากกว่าวิธีอื่น

ระดับการดีบักโดยทั่วไปนั้นเป็นไปตามอำเภอใจและอาจแตกต่างกันระหว่างภาษาห้องสมุดและ บริษัท

ที่ถูกกล่าวว่านี่คือวิธีที่ฉันได้เห็นพวกเขาใช้:

TRACE: ใช้สำหรับการแสดงผังโปรแกรมระดับตรรกะ เข้าฟังก์ชั่น? คำสั่ง "ถ้า" เลือกสาขาหลักหรือ "อื่น" หรือไม่ นั่นคือตัวเลือกสำหรับการติดตาม กล่าวอีกนัยหนึ่งการบันทึกการติดตามมักใช้เพื่อระบุ "คุณอยู่ที่นี่" สิ่งนี้มีประโยชน์ในบริบทของคำสั่งการบันทึกอื่น ๆ ที่อาจบันทึกข้อผิดพลาดหรือข้อมูลอื่น ๆ การบันทึกการติดตามสามารถช่วยระบุตำแหน่งของรหัสข้อผิดพลาดหรือเหตุการณ์อื่น ๆ ที่บันทึกในระดับที่แตกต่างกัน

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

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

ประโยชน์ในการแยกบันทึกระดับคือการควบคุมจำนวนเงินที่บันทึก สำหรับแอปพลิเคชันที่ซับซ้อนการบันทึกการติดตามอาจบันทึกข้อมูลจำนวนมหาศาลซึ่งส่วนใหญ่ไม่มีประโยชน์ เป็นการดีที่สุดที่จะบันทึกข้อมูลที่สำคัญ (อาจเป็นข้อมูลเริ่มต้นบางข้อผิดพลาดเท่านั้น) หากไม่มีใครพยายามที่จะทำให้เกิดข้อผิดพลาด นอกจากนี้โดยทั่วไปแล้วจะมีประโยชน์เฉพาะในสภาพแวดล้อมการผลิตที่ดีบั๊กและเครื่องมือในการพัฒนาอื่น ๆ ไม่ปรากฏ

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

ฉันคิดว่าคำตอบที่ยอดเยี่ยมของ Telastynสามารถสรุปได้ด้วยกฎง่ายๆสั้น ๆ ของฉัน:

• DEBUG การบันทึกจะต้องสามารถใช้ในการผลิตได้ (แต่มีแนวโน้มที่จะยังคงปิดอยู่ตามปกติ)
• TRACE การบันทึกจะได้รับอนุญาตให้ใช้งานในการผลิต (นอกเหนือจากช่วงเวลาสั้น / เฉพาะ) เป็นไปไม่ได้

นี่คือกฎง่ายๆของฉัน

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

ข้อสันนิษฐานที่อยู่เบื้องหลังนี้คือทีมที่ต้องการ

• มีชุดการผลิตเป็นข้อมูลระดับล็อกเสมอ
• อาจมีการตั้งค่าการผลิตเพื่อดีบักระดับล็อก
• ไม่เคยมีชุดการผลิตเพื่อติดตามระดับล็อก

ด้วยสมมติฐานดังกล่าวนี่คือวิธีที่คุณในฐานะนักพัฒนาสามารถใช้ระดับการบันทึกได้ ...

ปัญหา # 1) ไม่ทำให้ประสิทธิภาพการผลิตช้าลงมากนัก

debugแก้ปัญหา # 1 ในฐานะนักพัฒนาคุณทำอย่างดีที่สุดเพื่อสมดุลข้อมูลที่คุณอาจต้องการในการผลิตโดยไม่มีเสียงรบกวนมากเกินไปคุณทำให้เครื่องช้าลง คุณกำลังพูดว่า "เป็นความคิดที่ดีที่จะบันทึกสิ่งนี้ในการผลิตอย่างต่อเนื่อง (ถ้าคุณต้องการ)"

ปัญหา # 2) มีข้อมูล verbose ในขณะที่การพัฒนา

traceแก้ปัญหา # 2 คุณไม่ต้องกังวลอย่างแน่นอนว่าจะมีผลกระทบกับเครื่องผลิตอย่างไร แต่คุณต้องการข้อมูลนั้นในขณะที่พัฒนารหัส คุณกำลังพูดว่า "ฉันไม่ได้สัญญาว่าจะเป็นการดีที่จะบันทึกข้อมูลนี้ในการผลิตเสมอ"

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

อะไรคือตัวอย่างที่ยอมรับได้ของการบันทึกในระดับ TRACE

บันทึก ENTRY / EXIT จากเมธอด บันทึกเหล่านี้ช่วยให้คุณติดตามการไหลเวียนของโปรแกรมและมีประโยชน์มากเมื่อ:

1. โปรแกรมหยุดทำงานกะทันหัน - คุณรู้แน่ชัดว่าฟังก์ชั่นใดทำงานขัดข้องโดยดูที่บรรทัดสุดท้ายของบันทึก

2. ฟังก์ชั่นหัวไม้บางอันทำงานล้มเหลวโดยการดูดซับข้อยกเว้น

พวกเขารับประกันระดับการติดตามแยกต่างหากแทนที่จะใช้เพียงแค่ DEBUG เพราะการเปิดใช้งานบันทึก ENTRY / EXIT สำหรับทุกวิธีในฐานรหัสของคุณจะสร้างการบันทึกพิเศษจำนวนมหาศาลที่ไม่สมเหตุสมผลเสมอแม้ในบริบท DEBUG