รูปแบบและรูปแบบต่อต้านการบันทึกแอปพลิเคชันคืออะไร [ปิด]


66

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

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

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

แต่เพื่อที่จะประเมินว่าเรากำลังทำเรื่องเลวร้ายต่อหน้าการบันทึกผมอยากจะรู้ว่า:

  1. มีแนวทางอะไรบ้างถ้ามีเมื่อพูดถึงการบันทึกแอปพลิเคชันโดยเฉพาะแอปพลิเคชันขนาดใหญ่
  2. มีรูปแบบใดที่เราควรทำตามหรือรูปแบบต่อต้านที่เราควรระวัง?
  3. นี่เป็นสิ่งสำคัญในการแก้ไขหรือสามารถแก้ไขได้หรือไฟล์บันทึกทั้งหมดมีขนาดใหญ่และคุณต้องการสคริปต์เพิ่มเติมเพื่อวิเคราะห์

หมายเหตุด้านข้าง: เราใช้ log4j

คำตอบ:


55

บางจุดที่การฝึกฝนของฉันพิสูจน์แล้วว่ามีประโยชน์:

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

  • ทำให้บันทึกง่ายต่อการแยกวิเคราะห์โดยgrepและด้วยตา ติดกับฟิลด์ทั่วไปหลายจุดเริ่มต้นของแต่ละบรรทัด ระบุเวลาความรุนแรงและระบบย่อยในทุกบรรทัด กำหนดข้อความอย่างชัดเจน ทำให้ทุกข้อความบันทึกง่ายต่อการแมปไปยังบรรทัดซอร์สโค้ด

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

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


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

4
+1 ฉันชอบจุดของคุณเกี่ยวกับการใส่รองเท้าของตัวแก้ไขปัญหา ดูเหมือนว่าข้อความสั่งการบันทึกควรมีข้อความที่มีคุณภาพมากขึ้นจากนั้นสิ่งที่เราทำ ...
c_maker

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

2
@SnOrfus: มีหลายวิธีในการจัดเก็บบันทึก แต่สิ่งสำคัญคือต้องมีข้อความบันทึกถึงวินาทีสุดท้ายที่ระบบล่ม - เช่นกล่องดำเครื่องบิน หากคุณใช้การบัฟเฟอร์ใด ๆ ให้ระบุตัวเลือกในการข้าม / ล้างข้อมูลทุกข้อความ
rwong

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

28

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

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

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

off
errors only
basic
detailed
everything

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

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

#define DEBUG_ERROR          1
#define DEBUG_BASIC          2
#define DEBUG_DETAIL         4
#define DEBUG_MSG_BASIC      8
#define DEBUG_MSG_POLL       16
#define DEBUG_MSG_STATUS     32
#define DEBUG_METRICS        64
#define DEBUG_EXCEPTION      128
#define DEBUG_STATE_CHANGE   256
#define DEBUG_DB_READ        512
#define DEBUG_DB_WRITE       1024
#define DEBUG_SQL_TEXT       2048
#define DEBUG_MSG_CONTENTS   4096

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

โดยทั่วไปซอฟต์แวร์จะจัดส่งมาพร้อมกับข้อผิดพลาดพื้นฐาน BASIC, STATE_CHANGE และข้อยกเว้น แต่สามารถเปลี่ยนแปลงได้ในฟิลด์ผ่านกล่องโต้ตอบการดีบัก (หรือการตั้งค่ารีจิสทรี / ini / cfg ซึ่งสิ่งเหล่านี้ได้รับการบันทึก)

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

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


1
+1 โดยทั่วไปคำตอบที่ยอดเยี่ยม แต่โดยเฉพาะอย่างยิ่งสำหรับการใส่รหัสแอปพลิเคชันและข้อมูลรุ่นในไฟล์บันทึกโชคไม่ดีที่พลาดบ่อยครั้งมาก
Binary Worrier

27

ทรัพยากรสาธารณะของฉันชื่นชอบสำหรับแนวทางการเข้าสู่ระบบเป็นApache JCL ปฏิบัติที่ดีที่สุด

แนวปฏิบัติที่ดีที่สุดสำหรับ JCL นั้นแบ่งออกเป็นสองประเภท: ทั่วไปและองค์กร หลักการทั่วไปมีความชัดเจนพอสมควร แนวทางปฏิบัติขององค์กรมีความเกี่ยวข้องมากขึ้นและไม่ชัดเจนว่าทำไมจึงมีความสำคัญ

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

แม้จะมีการกำหนดเป้าหมาย JCL เหล่านี้ดูเหมือนจะกว้างพอที่จะนำไปใช้สำหรับการเข้าสู่ระบบทั่วไป

  • "แนวทาง" ส่วนบุคคลของฉันสำหรับการบันทึกคือในระดับการดีบักฉันพยายามทำให้บันทึกของฉันอ่านเหมือนเรื่องราว - ด้วยตรรกะที่เข้าใจได้และมีรายละเอียดเพียงพอ (แต่ไม่มากเกินไป)

รูปแบบการต่อต้านที่มีชื่อเสียงที่สุดน่าจะเป็น "การกลืนข้อยกเว้น" - เพียงแค่ค้นหาจากเว็บ

สำหรับไฟล์บันทึกขนาดใหญ่ในทางปฏิบัติของฉันส่วนใหญ่เป็นกรณีปกติ และใช่สคริปต์เพิ่มเติมตามที่คุณเรียกพวกเขาและ / หรือเครื่องมือเช่นChainsawก็ดูธรรมดาสำหรับฉันเช่นกัน

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

PS เกี่ยวกับรูปแบบการต่อต้านคนอื่น ๆ ที่นึกถึงคือ "น้ำท่วม" และข้อความที่ไม่เหมาะสม

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

  • ข้อความที่ไม่มีเหตุผลดูเหมือนจะเป็นขยะที่ได้รับความนิยม สิ่งเหล่านี้ดูไม่เป็นอันตรายเมื่ออ่านในซอร์สโค้ด - ฉันเดาว่ามันต้องผ่านความเจ็บปวดของการวิเคราะห์ผลลัพธ์ของ debug ที่ดูเหมือน ...

    step #1
    step #2
    step #3
    

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


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

@ Spike จุดที่ดี! การจัดเก็บในตัวแปรเป็นหนึ่งในเทคนิคส่วนตัวที่ฉันโปรดปรานในการต่อสู้กับน้ำท่วม
ริ้น

1
ฉันส่งออกตัวนับที่แตกต่างกันทั้งหมดไปยังตัวบันทึกเป็นตาราง ASCII ในบันทึกหลังจากวนรอบสิ้นสุดลงเพื่อให้สามารถเปรียบเทียบได้อย่างง่ายดาย ความคิดตารางเป็นแรงบันดาลใจหนึ่งที่ฤดูใบไม้ผลิStopWatch.prettyPrint ()สร้าง นอกเหนือจากนั้นการทำให้ข้อความบันทึกข้อมูลที่อ่านได้และเกี่ยวข้องยังคงเป็น "ศิลปะ" ตามที่ระบุไว้ก่อนหน้าในคำตอบ
Spoike

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

2
@c_maker ประเด็นของคุณเกี่ยวกับการบันทึกการผสมกับตรรกะทางธุรกิจดูเหมือนจะคุ้มค่ากับคำถามเฉพาะ โดยส่วนตัวฉันยังไม่มีความเห็นที่ดีเกี่ยวกับเรื่องเหล่านี้ ในทางทฤษฎีสามารถจินตนาการถึงการปรับปรุงการแยกโดยใช้ AOP และ iirc แม้จะมีการใช้งานจริงสำหรับแนวทางนี้ อย่างไรก็ตามในทางปฏิบัติฉันใช้วิธี "แบบผสม" และจนถึงตอนนี้ฉันก็ไม่มีปัญหาอะไรเลย ซอร์สโค้ดที่รกรุงรังเป็นอันตรายจริง แต่อีกครั้งจนถึงตอนนี้ฉันสามารถทำให้มันอยู่ร่วมกับรหัสการบันทึกได้ค่อนข้าง "สงบสุข" แน่นอนว่าต้องใช้ความพยายามบางอย่าง
ริ้น

11

บันทึกข้อยกเว้นเพียงครั้งเดียว!

หนึ่งในจุดปวดทั่วไปที่ฉันได้สังเกตเห็นคือการบันทึกและ rethrowing ข้อยกเว้น เป็นผลให้ไฟล์บันทึกมีข้อยกเว้นเดียวกันหลายครั้งในหลายระดับสแต็ก


5

ต่อไปนี้เป็นรูปแบบการต่อต้าน: สร้างฟิลด์ "genericvariable" สองโหลในตารางฐานข้อมูลเพื่อติดตามสิ่งที่นึกออกแล้วมี 88 (และเพิ่มขึ้น) ค่า enum ที่แตกต่างกันสำหรับบันทึกประเภทต่างๆ


+1 - ฉันเคยเห็นสิ่งนี้แล้ว "ตารางข้อผิดพลาด" ที่มีคอลัมน์เช่น string1, string2, string3, string4, string5 ซึ่งการรวมคอลัมน์ทั้งหมดจะส่งผลให้เกิดรหัสข้อผิดพลาดที่ไม่ได้อ้างอิงในเอกสารใด ๆ ผลลัพธ์คือการบันทึกที่สับสนและไร้ประโยชน์ หรือที่เรียกว่า "บุคคลที่สามองค์กรแอปที่มีการพัฒนาที่กำหนดเองการแก้จุดบกพร่อง - นรก"
Morgan Herlocker

ในกรณีของฉันมันเป็น "ระบบการบันทึกมือรีดโดยไม่ต้องคิดในสิ่งที่เข้าสู่ระบบจริงที่เกี่ยวข้องกับการใด ๆ"
เวย์น Molina

4

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

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


2

คู่ของบันทึกจากด้านการดำเนินงานของบ้านที่นี่:

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

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


1

จากประสบการณ์ของฉันเองที่ทำงานกับเว็บแอปพลิเคชัน:

(และการพิจารณาที่จัดเก็บข้อมูลราคาถูกมากวันนี้)

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

    • "[ข้อมูล X] [ข้อมูล Y] [ข้อมูล Z] [ฯลฯ ]"

1

นอกเหนือจากสแต็คเทรซให้บันทึกสถานะแอปพลิเคชันปัจจุบันและอินพุต

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

แน่นอนว่ามีข้อมูลมากขึ้นดีกว่าเสมอ แต่อย่างน้อยสองสิ่งนี้เป็นการเริ่มต้นที่ดีสำหรับการล่มที่ง่ายที่สุด


3
"ซอฟต์แวร์ไม่แน่นอน" => ไม่น่าเสียดายเสมอไป คิดว่าข้อบกพร่องที่เกิดขึ้นพร้อมกันเช่น
assylias
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.