ควรใช้ระดับการบันทึกที่ต่างกันเมื่อใด

มีวิธีบันทึกข้อความต่าง ๆ ตามลำดับของการเสียชีวิต:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

ฉันจะตัดสินใจได้อย่างไรว่าจะใช้เมื่อใด

ฮิวริสติกที่ดีในการใช้คืออะไร

โดยทั่วไปฉันสมัครตามอนุสัญญาดังต่อไปนี้:

• ติดตาม - เฉพาะเมื่อฉันจะ "ติดตาม" รหัสและพยายามค้นหาส่วนหนึ่งของฟังก์ชั่นโดยเฉพาะ
• แก้ไขข้อบกพร่อง - ข้อมูลที่เป็นประโยชน์ในการวินิจฉัยกับผู้คนมากกว่าเพียงแค่นักพัฒนา (IT, sysadmins เป็นต้น)
• ข้อมูล - ข้อมูลที่เป็นประโยชน์โดยทั่วไปในการเข้าสู่ระบบ (บริการเริ่ม / หยุดสมมติฐานการกำหนดค่า ฯลฯ ) ข้อมูลฉันต้องการให้มีอยู่เสมอ แต่มักจะไม่สนใจภายใต้สถานการณ์ปกติ นี่คือระดับการกำหนดค่าของฉัน
• คำเตือน - สิ่งใดก็ตามที่อาจทำให้แปลกประหลาดของแอปพลิเคชัน แต่สิ่งที่ฉันจะกู้คืนโดยอัตโนมัติ (เช่นการเปลี่ยนจากเซิร์ฟเวอร์หลักเป็นเซิร์ฟเวอร์สำรองข้อมูลลองดำเนินการใหม่ไม่มีข้อมูลรอง ฯลฯ )
• ข้อผิดพลาด - ข้อผิดพลาดใด ๆ ที่เป็นอันตรายต่อการดำเนินการแต่ไม่ใช่บริการหรือแอปพลิเคชัน (ไม่สามารถเปิดไฟล์ที่ต้องการข้อมูลที่ขาดหายไป ฯลฯ ) ข้อผิดพลาดเหล่านี้จะบังคับให้ผู้ใช้ (ผู้ดูแลระบบหรือผู้ใช้โดยตรง) เหล่านี้มักจะสงวนไว้ (ในแอพของฉัน) สำหรับสตริงการเชื่อมต่อที่ไม่ถูกต้องบริการหายไป ฯลฯ
• ร้ายแรง - ข้อผิดพลาดใด ๆ ที่บังคับให้ปิดบริการหรือแอปพลิเคชันเพื่อป้องกันข้อมูลสูญหาย (หรือการสูญหายของข้อมูลเพิ่มเติม) ฉันขอสงวนสิ่งเหล่านี้เฉพาะสำหรับข้อผิดพลาดที่ร้ายแรงที่สุดและสถานการณ์ที่มีการรับประกันว่าข้อมูลเสียหายหรือสูญหาย

คุณต้องการให้ข้อความทำให้ผู้ดูแลระบบหยุดทำงานกลางดึกหรือไม่?

• ใช่ -> ข้อผิดพลาด
• ไม่ -> เตือน

ฉันคิดว่ามันมีประโยชน์มากกว่าถ้าคิดถึงความรุนแรงจากมุมมองของการดูล็อกไฟล์

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

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

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

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

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

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

นี่คือรายการสิ่งที่ "คนตัดไม้" มี

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : .. ] เหตุการณ์ข้อผิดพลาดที่รุนแรงมากซึ่งอาจทำให้แอปพลิเคชันยกเลิก

   [ v2.0 : .. ] ข้อผิดพลาดร้ายแรงที่จะป้องกันไม่ให้แอปพลิเคชันดำเนินการต่อ

2. ERROR:

   [ v1.2 : .. ] เหตุการณ์ข้อผิดพลาดที่อาจยังอนุญาตให้แอปพลิเคชันทำงานต่อไป

   ข้อผิดพลาด[ v2.0 : .. ] ในแอปพลิเคชันอาจกู้คืนได้

3. WARN:

   [ v1.2 : .. ] สถานการณ์ที่อาจเป็นอันตราย

   [ v2.0 : .. ] เหตุการณ์ที่อาจเป็นไปได้ [ sic ] นำไปสู่ข้อผิดพลาด

4. INFO:

   [ v1.2 : .. ] ข้อความที่ให้ข้อมูลที่เน้นความคืบหน้าของแอปพลิเคชันในระดับหยาบ

   เหตุการณ์[ v2.0 : .. ] เพื่อจุดประสงค์ในการให้ข้อมูล

5. DEBUG:

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

   [ v2.0 : .. ] เหตุการณ์การแก้ไขข้อบกพร่องทั่วไป

6. TRACE:

   [ v1.2 : .. ] DEBUGปลีกย่อยเม็ดเล็กเหตุการณ์ให้ข้อมูลกว่า

   [ v2.0 : .. ] ข้อความการดีบักแบบละเอียดโดยทั่วไปจะจับภาพการไหลผ่านแอปพลิเคชัน

Apache Httpd (ตามปกติ) ชอบไปเกินขนาด: §

1. ฉุกเฉิน :

   กรณีฉุกเฉิน - ระบบใช้ไม่ได้

2. การแจ้งเตือน :

   ต้องดำเนินการทันที [แต่ระบบยังใช้งานได้]

3. crit :

   เงื่อนไขสำคัญ [แต่ไม่จำเป็นต้องดำเนินการทันที]

   • " ซ็อกเก็ต: ไม่สามารถรับซ็อกเก็ตออกจากเด็กได้ "

4. ข้อผิดพลาด :

   เงื่อนไขข้อผิดพลาด [แต่ไม่สำคัญ]

   • " ปลายส่วนหัวของสคริปต์ก่อนกำหนด "

5. เตือน :

   เงื่อนไขการเตือน [ใกล้กับข้อผิดพลาด แต่ไม่ใช่ข้อผิดพลาด]

6. แจ้งให้ทราบล่วงหน้า :

   สภาพปกติ แต่สำคัญ [ เด่น ]

   • " httpd: จับSIGBUSแล้วกำลังพยายามจะถ่ายโอนหลักใน ... "

7. ข้อมูล :

   ให้ข้อมูล [และไม่สามารถสังเกตได้]

   • [" เซิร์ฟเวอร์ทำงานมาแล้ว x ชั่วโมง "]

8. แก้ไขข้อบกพร่อง :

   ข้อความระดับการแก้ปัญหา [คือข้อความที่บันทึกเพื่อการยกเลิกการบล็อก )]

   • "กำลังเปิดไฟล์กำหนดค่า ... "

9. trace1 → trace6 :

   ติดตามข้อความ [คือข้อความที่บันทึกไว้เพื่อการติดตาม ]

   • " พร็อกซี: FTP: การเชื่อมต่อการควบคุมเสร็จสมบูรณ์ "
   • " proxy: CONNECT: ส่งคำขอ CONNECT ไปยัง Remote proxy "
   • " openssl: จับมือ: เริ่มต้น "
   • " อ่านจากกลุ่ม SSL SSL ที่บัฟเฟอร์แล้วโหมด 0, 17 ไบต์ "
   • "การค้นหาแผนที่ล้มเหลว:map=rewritemap key=keyname "
   • "การค้นหาแคชล้มเหลวบังคับให้ค้นหาแผนที่ใหม่ "

10. trace7 → trace8 :

    ติดตามข้อความทิ้งข้อมูลจำนวนมาก

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache คอมมอนส์เข้าสู่ระบบ: §

1. ร้ายแรง :

   ข้อผิดพลาดรุนแรงที่ทำให้เกิดการยกเลิกก่อนกำหนด คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลสถานะ

2. ข้อผิดพลาด :

   ข้อผิดพลาดรันไทม์อื่น ๆ หรือเงื่อนไขที่ไม่คาดคิด คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลสถานะ

3. เตือน :

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

4. ข้อมูล :

   กิจกรรมรันไทม์ที่น่าสนใจ (เริ่มต้น / ปิด) คาดว่าสิ่งเหล่านี้จะสามารถมองเห็นได้ทันทีบนคอนโซลดังนั้นควรระมัดระวังและทำน้อย

5. แก้ไขข้อบกพร่อง :

   ข้อมูลรายละเอียดเกี่ยวกับการไหลผ่านระบบ คาดว่าสิ่งเหล่านี้จะเขียนลงในบันทึกเท่านั้น

6. ร่องรอย :

   ข้อมูลรายละเอียดเพิ่มเติม คาดว่าสิ่งเหล่านี้จะถูกเขียนลงในบันทึกเท่านั้น

Apache Commons-logging "แนวทางปฏิบัติที่ดีที่สุด" สำหรับการใช้งานในองค์กรสร้างความแตกต่างระหว่างการดีบักและข้อมูลตามประเภทของขอบเขตที่ข้าม

ขอบเขตรวมถึง:

• ขอบเขตภายนอก - ข้อยกเว้นที่คาดไว้

• ขอบเขตภายนอก - ข้อยกเว้นที่ไม่คาดคิด

• เขตแดนภายใน

• ขอบเขตภายในที่สำคัญ

(ดูคู่มือการบันทึกข้อมูลทั่วไปสำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้)

หากคุณสามารถกู้คืนจากปัญหาแล้วมันเป็นคำเตือน หากป้องกันการดำเนินการต่อไปแสดงว่าเป็นข้อผิดพลาด

ผมอยากแนะนำให้การใช้ความรุนแรงระดับ DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCYSyslog:
ดูhttp://en.wikipedia.org/wiki/Syslog#Severity_levels

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

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

คำเตือนคุณสามารถกู้คืนจาก ข้อผิดพลาดที่คุณทำไม่ได้ นั่นคือฮิวริสติกของฉัน, คนอื่นอาจมีความคิดอื่น

ตัวอย่างเช่นสมมติว่าคุณป้อน / นำเข้าชื่อ"Angela Müller"ลงในแอปพลิเคชันของคุณ (โปรดสังเกตเครื่องหมายบนเหนือu ) รหัส / ฐานข้อมูลของคุณอาจเป็นภาษาอังกฤษเท่านั้น (แม้ว่าอาจไม่ควรเป็นในวันนี้และอายุ) ดังนั้นจึงสามารถเตือนได้ว่าอักขระ "ผิดปกติ" ทั้งหมดถูกแปลงเป็นอักขระภาษาอังกฤษทั่วไป

ตรงกันข้ามกับการพยายามเขียนข้อมูลนั้นไปยังฐานข้อมูลและรับข้อความเครือข่ายกลับเป็นเวลา 60 วินาที นั่นเป็นข้อผิดพลาดมากกว่าคำเตือน

ดังที่คนอื่น ๆ พูดว่าข้อผิดพลาดเป็นปัญหา คำเตือนเป็นปัญหาที่อาจเกิดขึ้น

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

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

ฉันคิดว่าการแจ้งเตือนระดับ SYSLOG และ ALERT / EMERGENCY นั้นไม่จำเป็นสำหรับการบันทึกระดับแอปพลิเคชัน - ในขณะที่ CRITICAL / ALERT / EMERGENCY อาจเป็นระดับการแจ้งเตือนที่มีประโยชน์สำหรับผู้ให้บริการที่อาจเรียกใช้การกระทำและการแจ้งเตือนต่างๆ FATAL และฉันไม่สามารถแยกแยะความแตกต่างระหว่างการได้รับแจ้งหรือข้อมูลบางอย่างเพียงพอ หากข้อมูลไม่สำคัญก็ไม่ใช่ข้อมูลจริงๆ :)

ฉันชอบการตีความที่ดีที่สุดของ Jay Cincotta - การติดตามการประมวลผลรหัสของคุณเป็นสิ่งที่มีประโยชน์มากในการสนับสนุนด้านเทคนิคและควรสนับสนุนให้วางคำสั่งการติดตามลงในรหัสอย่างเสรีโดยเฉพาะอย่างยิ่งเมื่อใช้ร่วมกับกลไกการกรองแบบไดนามิก อย่างไรก็ตามระดับข้อบกพร่องสำหรับฉันบ่งชี้ว่าเรายังคงอยู่ในกระบวนการหาสิ่งที่เกิดขึ้น - ฉันเห็นผลลัพธ์ระดับ DEBUG เป็นตัวเลือกสำหรับการพัฒนาเท่านั้นไม่ใช่สิ่งที่ควรจะปรากฏในบันทึกการผลิต

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

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

จาก RFC 5424, Syslog Protocol (IETF) - หน้า 10:

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

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

G'day,

ในฐานะที่เป็นข้อสรุปสำหรับคำถามนี้สื่อสารการตีความระดับล็อกของคุณและตรวจสอบให้แน่ใจว่าทุกคนในโครงการสอดคล้องกับการตีความระดับของพวกเขา

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

ให้ตัวอย่างถ้าเป็นไปได้ของระดับการบันทึกที่แตกต่างกัน และสอดคล้องในข้อมูลที่จะเข้าสู่ระบบข้อความ

HTH

ฉันเห็นด้วยกับคนอื่นโดยสิ้นเชิงและคิดว่า GrayWizardx พูดได้ดีที่สุด

สิ่งที่ฉันสามารถเพิ่มได้คือระดับเหล่านี้มักจะตรงกับคำจำกัดความของพจนานุกรมดังนั้นจึงไม่ยากอย่างนั้น หากมีข้อสงสัยให้รักษาเหมือนปริศนา สำหรับโครงการเฉพาะของคุณให้คิดถึงทุกสิ่งที่คุณอาจต้องการบันทึก

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

ตกลงนั่นเป็นสิ่งที่ร้ายแรงถึงขั้นตอนนี้ลองดูที่ข้อผิดพลาด ... ล้างและทำซ้ำ

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

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

นี่คือตัวอย่างบางส่วน:

ร้ายแรง - ไม่สามารถจัดสรรหน่วยความจำฐานข้อมูลและอื่น ๆ - ไม่สามารถดำเนินการต่อได้

ข้อผิดพลาด - ไม่ตอบกลับข้อความยกเลิกธุรกรรมไม่สามารถบันทึกไฟล์ ฯลฯ

คำเตือน - การจัดสรรทรัพยากรถึง X% (พูด 80%) - นั่นคือสัญญาณที่คุณอาจต้องการกำหนดขนาดของคุณใหม่

ข้อมูล - ผู้ใช้เข้า / ออก, การทำธุรกรรมใหม่, crated ไฟล์, ฟิลด์ d / b ใหม่, หรือลบฟิลด์

แก้ไขข้อผิดพลาด - ดัมพ์ของโครงสร้างข้อมูลภายในระดับการติดตามใด ๆ ที่มีชื่อไฟล์ & หมายเลขบรรทัด
ติดตาม - การกระทำสำเร็จ / ล้มเหลวอัปเดต d / b

ข้อผิดพลาดเป็นสิ่งที่ผิดปกติไม่ถูกต้องไม่มีวิธีแก้ไขต้องแก้ไข

คำเตือนเป็นสัญญาณของรูปแบบที่อาจผิด แต่ก็อาจไม่ได้เช่นกัน

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

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

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

ฉันได้สร้างระบบก่อนหน้านั้นใช้สิ่งต่อไปนี้:

1. ข้อผิดพลาด - หมายถึงบางสิ่งผิดปกติอย่างมากและไม่สามารถดำเนินการเธรด / กระบวนการ / ลำดับที่เฉพาะเจาะจงได้ ต้องการการแทรกแซงจากผู้ใช้ / ผู้ดูแลระบบบางคน
2. คำเตือน - มีบางอย่างไม่ถูกต้อง แต่กระบวนการสามารถดำเนินต่อไปเหมือนเมื่อก่อน (เช่นงานหนึ่งในชุด 100 ล้มเหลว แต่ส่วนที่เหลือสามารถประมวลผลได้)

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

Btw ฉันเป็นแฟนตัวยงของการจับทุกอย่างและกรองข้อมูลในภายหลัง

จะเกิดอะไรขึ้นหากคุณจับภาพที่ระดับคำเตือนและต้องการข้อมูล Debug บางส่วนที่เกี่ยวข้องกับคำเตือน แต่ไม่สามารถสร้างคำเตือนได้อีก

จับทุกอย่างและกรองในภายหลัง!

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

จับทุกอย่างและกรองในภายหลัง !!

(btw, การจับทุกอย่างก็ดีเพราะมันช่วยให้คุณพัฒนาเครื่องมือในการทำมากกว่าแสดง debug trace (ฉันวาด Message Sequence Charts จากฉันและฮิสโทแกรมของการใช้หน่วยความจำ) มันช่วยให้คุณมีพื้นฐานสำหรับการเปรียบเทียบ ในอนาคต (เก็บบันทึกทั้งหมดไม่ว่าจะผ่านหรือล้มเหลวและต้องแน่ใจว่าได้รวมหมายเลขบิลด์ไว้ในไฟล์บันทึกแล้ว)

สองเซ็นต์ของฉันเกี่ยวกับFATALและTRACEระดับบันทึกข้อผิดพลาด

ERROR คือเมื่อ FAULT (ข้อยกเว้น) บางอย่างเกิดขึ้น

FATAL เป็นจริงสองเท่าของความผิดพลาด: เมื่อเกิดข้อยกเว้นขณะจัดการข้อยกเว้น

ง่ายต่อการเข้าใจสำหรับบริการเว็บ

1. ขอมา กิจกรรมถูกบันทึกเป็นINFO
2. ระบบตรวจพบพื้นที่ดิสก์เหลือน้อย กิจกรรมถูกบันทึกเป็นWARN
3. มีการเรียกใช้ฟังก์ชันบางอย่างเพื่อจัดการการร้องขอ ในขณะที่การประมวลผลหารด้วยศูนย์เกิดขึ้น กิจกรรมถูกบันทึกเป็นERROR
4. ตัวจัดการข้อยกเว้นของเว็บเซอร์วิสถูกเรียกให้จัดการหารด้วยศูนย์ บริการเว็บ / เฟรมเวิร์กกำลังจะส่งอีเมล แต่ไม่สามารถทำได้เพราะบริการส่งเมลออฟไลน์อยู่ในขณะนี้ ข้อยกเว้นที่สองนี้ไม่สามารถจัดการได้ตามปกติเนื่องจากตัวจัดการข้อยกเว้นของบริการเว็บไม่สามารถประมวลผลข้อยกเว้นได้
5. ตัวจัดการข้อยกเว้นที่แตกต่างกันเรียกว่า กิจกรรมถูกบันทึกเป็นFATAL

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

ดังนั้นโดยทั่วไปในโปรแกรมของคุณคุณจะทำอย่างไรDEBUG, INFOและWARNการเข้าสู่ระบบ และเพียงถ้าคุณกำลังเขียนบางเว็บบริการ / FATALกรอบที่คุณจะใช้ และเมื่อคุณทำการดีบักแอปพลิเคชั่นคุณจะได้รับTRACEการบันทึกจากซอฟต์แวร์ประเภทนี้

ฉันขอแนะนำให้ใช้เพียงสามระดับ

1. Fatal - ซึ่งจะทำลายแอปพลิเคชัน
2. ข้อมูล - ข้อมูล
3. Debug - ข้อมูลที่สำคัญน้อยกว่า