แนวทางปฏิบัติที่ดีที่สุดสำหรับการบันทึกและติดตามใน. NET

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

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

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

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

ตอนนี้บอกว่าฉันต้องการทำการติดตามและการบันทึกโดยใช้คลาส. NET มาตรฐานเท่านั้นซึ่งอยู่ในSystem.Diagnosticsเนมสเปซ ฉันคิดว่าคลาส TraceSource นั้นดีกว่าสำหรับงานมากกว่าคลาส Trace คงเพราะฉันต้องการแยกความแตกต่างระหว่างระดับการติดตามและการใช้คลาส TraceSource ฉันสามารถส่งผ่านพารามิเตอร์แจ้งประเภทเหตุการณ์ในขณะที่ใช้คลาส Trace ที่ฉันต้องใช้Trace.WriteLineIfและตรวจสอบสิ่งที่ชอบSourceSwitch.TraceInformationและSourceSwitch.TraceErrorsและมันก็ไม่ได้มีคุณสมบัติเหมือนหรือTraceVerboseTraceStart

ในใจคุณจะพิจารณาการฝึกฝนที่ดีให้ทำดังนี้:

• ติดตามเหตุการณ์ "เริ่มต้น" เมื่อเริ่มต้นเมธอดซึ่งควรแสดงถึงการดำเนินการเชิงตรรกะเดี่ยวหรือไพพ์ไลน์พร้อมกับการแทนค่าสตริงของค่าพารามิเตอร์ที่ส่งผ่านไปยังเมธอด
• ติดตามเหตุการณ์ "ข้อมูล" เมื่อแทรกรายการลงในฐานข้อมูล
• ติดตามเหตุการณ์ "ข้อมูล" เมื่อรับหนึ่งพา ธ หรืออย่างอื่นในคำสั่ง if / else ที่สำคัญ
• ติดตาม "Critical" หรือ "Error" ใน catch catch ขึ้นอยู่กับว่าเป็นข้อผิดพลาดที่สามารถกู้คืนได้
• ติดตามเหตุการณ์ "หยุด" เมื่อเสร็จสิ้นการดำเนินการของวิธีการ

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

หมายเหตุ:ฉันพบข้อมูลที่ดีที่นี่แล้ว แต่ยังไม่ใช่สิ่งที่ฉันกำลังมองหา: http://msdn.microsoft.com/en-us/magazine/ff714589.aspx

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

ติดตามเหตุการณ์ "เริ่มต้น" เมื่อเริ่มต้นเมธอดซึ่งควรแสดงถึงการดำเนินการทางตรรกะเดียวหรือไปป์ไลน์พร้อมกับการแทนค่าสตริงของค่าพารามิเตอร์ที่ส่งผ่านไปยังเมธอด

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

ในกรณีส่วนใหญ่การดำเนินการทางตรรกะจะเริ่มต้นที่จุดเริ่มต้นของวิธีการจริง มิฉะนั้นคุณควรถามตัวคุณเองว่ารหัสนั้นถูกต้องหรือไม่

พารามิเตอร์การติดตามอาจเป็นแนวคิดที่ไม่ดีเช่นกัน คุณต้องคิดว่าจะติดตามอะไรเป็นกรณี ๆ ไป void Authenticate(string userName, string plainPassword)ยกตัวอย่างเช่นมันไม่ดีจริงๆในการติดตามค่าพารามิเตอร์ของวิธีการ

ติดตามเหตุการณ์ "ข้อมูล" เมื่อแทรกรายการลงในฐานข้อมูล

มันขึ้นอยู่กับ. บางรายการต้องถูกติดตาม แต่ไม่ใช่ทุกรายการ

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

ติดตามเหตุการณ์ "ข้อมูล" เมื่อรับหนึ่งพา ธ หรืออย่างอื่นในคำสั่ง if / else ที่สำคัญ

อีกครั้งมันขึ้นอยู่กับ

ติดตาม "Critical" หรือ "Error" ใน catch catch ขึ้นอยู่กับสภาพอากาศนี่เป็นข้อผิดพลาดที่สามารถกู้คืนได้

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

ติดตามเหตุการณ์ "หยุด" เมื่อเสร็จสิ้นการดำเนินการของวิธีการ

ดูจุดแรก

โปรดอธิบายให้ชัดเจนว่าควรติดตามประเภทกิจกรรม Verbose และ Warning เมื่อใด

ละเอียด:

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

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

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

คิดเกี่ยวกับ verbose เป็นเครื่องมือที่คุณต้องใช้เมื่อคุณไม่มีสิทธิ์เข้าถึงตัวดีบัก

คำเตือน:

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

ตัวอย่าง:

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

• ตัวอย่างที่ 2: หลังจากตรวจสอบข้อผิดพลาดในตัวอย่างแรกคุณพบว่าข้อผิดพลาดเกิดจากข้อเท็จจริงที่ว่าเส้นทางของไฟล์มีความยาวเกิน 259 อักขระ ดังนั้นคุณ refactor PathTooLongExceptionรหัสของคุณที่จะจับ เมื่อครั้งต่อไปผู้ใช้พยายามเปิดไฟล์เดียวกันแอพพลิเคชั่นเวอร์ชั่นใหม่จะแสดงข้อความอธิบายว่าไฟล์ยาวเกินไปและจะต้องย้ายไปที่โฟลเดอร์อื่นเพื่อย่อเส้นทางแบบเต็มเพื่อเปิดไฟล์นี้ใน แอปพลิเคชันนี้ นอกจากนี้คุณยังติดตามข้อความ

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

• ตัวอย่างที่ 4: ไฟล์ที่เปิดแสดงอย่างไม่ถูกต้อง คุณเปิดใช้งานการติดตามverboseที่คุณเห็นจริง ๆ แล้วว่าข้อมูลถูกโหลดจากไฟล์แล้วแยกวิเคราะห์ทีละขั้นตอน

 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics ดีมากเพราะคุณสามารถกำหนดว่าข้อมูลการติดตามใดควรไปที่ใด (ไฟล์, eventlog, ฐานข้อมูล, .... )

น่าเสียดายที่ถ้าคุณต้องการใช้System.Diagnosticsคุณต้องรู้ล่วงหน้า ( ณ เวลาออกแบบ ) ซึ่งควรติดตามการสตรีมใด (ในบทความตัวอย่างเหล่านี้คือ Transfer, Resume, Suspend, ... ) เหล่านี้สามารถกำหนดค่าให้เป็น Disabled, Debuglevel หรือ Errorlevel

ฉันชอบที่จะมีระบบการบันทึกที่ฉันสามารถตัดสินใจที่รันไทม์บนclasslevel / namespacelevelรายละเอียดการบันทึกควรเป็นอย่างไร ยกตัวอย่างเช่นการตรวจแก้จุดบกพร่องทั้งหมดและเหนือจากแต่ไม่MyNamespace.Business.*MyNamespace.Business.Calculations

หากคุณใช้ log4net (หรือ Common.logging) ทุกคลาสจะได้รับตัวบันทึกของตัวเองเพื่อให้คุณสามารถตัดสินใจว่าคลาสใดจะถูกบันทึกในระดับใด

เนื่องจากการดำเนินการฐานข้อมูลอยู่ในคลาสที่แยกต่างหากจึงไม่จำเป็นต้องมีกฎที่แตกต่าง

Trace an "Information" event when inserting an item into the database.

ฉันต้องการมีแนวทางเหล่านี้แทน:

• Tracelevel ควรแสดงเวิร์กโฟลว์พื้นฐาน
• Debuglevel ควรแสดงข้อมูลโดยละเอียดและการประมวลผลภายในเวิร์กโฟลว์รวมถึงการตัดสินใจในแผนงานด้วยเหตุผล (การสร้างไอเท็มใหม่เนื่องจากไม่มีไอเท็มใน DB)
• Infolevel สำหรับการเริ่ม / หยุดบริการและหนึ่งรายการสำหรับทุกการทำงานของเวิร์กโฟลว์ / GUI ที่เริ่มต้น

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

มันจะเพิ่มแนวคิด "เริ่มต้น" และ "หยุด" โดยอัตโนมัติเป็นจุดเริ่มต้นและจุดสิ้นสุดของเรื่องราว

และด้วยระบบแบบอิงกฏคุณสามารถควบคุมสิ่งที่จะทำกับแต่ละเรื่องราว (บริบท) ตามข้อมูลที่มีตัวอย่างเช่นพิมพ์เรื่องราวทั้งหมดที่มีข้อผิดพลาดหรือมาจากผู้ใช้ "admin"

นอกจากนี้ยังมีข้อมูลเพิ่มเติมเกี่ยวกับโพสต์บล็อกนี้