การเข้าสู่ระบบ: ทำไมและอะไร [ปิด]

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

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

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

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

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

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

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

มีการบันทึกเหตุผลสองประการ:

1. การวินิจฉัย
2. การตรวจสอบบัญชี

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

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

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

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

แต่คนที่ Google บอกฉันหนึ่งครั้งว่ากระบวนการเซิร์ฟเวอร์ของพวกเขาไม่ทำการบันทึก แทนพวกเขา 'เครื่องมือ'; นั่นหมายความว่าทุกกระบวนการมี hooks หรือพอร์ต (เขาไม่ได้ระบุกลไก) ที่กระบวนการอื่น ๆ สามารถ latch เพื่อขอพารามิเตอร์และสถิติ เป็นกระบวนการตรวจสอบที่เก็บสิ่งต่าง ๆ มากมายลงในบันทึกข้อดีคือข้อมูลที่พวกเขาได้รับไม่ใช่ "เปิดไฟล์", "เขียนสิ่งนี้", "ดึงข้อมูลนั้น"; พวกเขาได้รับสิ่งต่าง ๆ เช่น "เปิดไฟล์ 45,453 ไฟล์", "ลูกค้าของบริการ X 653 ราย", "ตอบกลับเฉลี่ย 344 มิลลิวินาทีสำหรับแบบสอบถาม Y"

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

ฉันมาจากแอปพลิเคชัน N-Tiered winforms ที่บันทึกทุกอย่าง

มันไม่ได้มีประโยชน์มาก

แน่นอนว่าการบันทึกข้อยกเว้นนั้นยอดเยี่ยม แต่ทำไมบันทึกพวกเขาไปยังเครื่องของลูกค้าเมื่อคุณเพียงแค่ส่งอีเมลข้อยกเว้นไปยังทีม dev?

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

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

การบันทึกมีข้อ จำกัด เพียงการจับข้อมูลข้อผิดพลาดหรือไม่?

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

ตอนแรกฉันไม่รู้ว่าจะมีความสำคัญขนาดไหน แต่เห็นได้ชัดว่ามันมีประโยชน์มากในหลาย ๆ สิ่ง (นอกเหนือจากการดีบั๊ก):

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

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

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

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

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

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

การบันทึกเป็นประโยชน์สำหรับข้อมูลที่คุณไม่สามารถหาได้จากโปรแกรมอื่น:

• จับภาพร่องรอยสแต็ก (คุณมีอันนั้น)
• จับภาพข้อมูลที่กำลังประมวลผลเมื่อแอปพลิเคชันของคุณล้มเหลว โปรดจำไว้ว่าตัวดีบั๊กจะช่วยได้ก็ต่อเมื่อมีข้อผิดพลาดเกิดขึ้นเท่านั้น
• ข้อมูลการทำโปรไฟล์ หากคุณไม่สามารถเรียกใช้ตัวสร้างโปรไฟล์บนสภาพแวดล้อมการผลิตการบันทึกที่ครอบคลุมรวมถึงการประทับเวลาสามารถช่วยให้คุณทราบว่าเวลาไปที่ไหน แม้ว่าการไม่สามารถบอกได้อาจช่วยให้คุณระบุได้ว่ามันอยู่นอกโปรแกรมของคุณ (เช่นการรวบรวมขยะที่เตะเข้า)
• สถิติไม่ถูกคาดหวังเมื่อเขียนโปรแกรม ฉันถูกขอให้จัดทำกราฟพฤติกรรมในช่วงเวลาที่น่าสนใจด้วยเหตุผลอื่น ข้อมูลที่จำเป็นสามารถดึงออกมาจากไฟล์บันทึกด้วยเทคนิค grep + awk + perl ninja

หมายเหตุ: คุณต้องการไฟล์บันทึกอย่างน้อยสองไฟล์

• หนึ่งที่ระดับ DEBUG - ให้ข้อมูลทั้งหมดที่คุณสามารถจินตนาการได้ว่าคุณจะต้องการ (รวมถึง INFO และสูงกว่า) หากนั่นมากเกินไปให้ลองพิจารณาระดับการติดตามเพิ่มเติม
• หนึ่งที่ระดับ INFO - ให้ภาพรวมของระบบ 10,000 เมตร เหตุการณ์สำคัญที่สำคัญไปที่นี่

INFO อันหนึ่งเปิดอยู่เสมอ เปิดใช้งาน DEBUG เมื่อจำเป็น

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

สำหรับไมล์พิเศษให้เรียกใช้ฟังก์ชันทั้งหมดเพิ่มพารามิเตอร์ของตนลงในการติดตามสแต็กใด ๆ ใน Java ด้วย

public void sendEmail(String sender, String recipient) {
try { 
...
} catch (Exception e) {
  throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}

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

ฉันอยากจะแนะนำว่าแอปที่ไม่สำคัญใช้การบันทึกหลายระดับ

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

ในบางกรณีการบันทึกเป็นสิ่งจำเป็นตัวอย่างเช่นในแอปพลิเคชันทางการเงินและโดเมนอื่น ๆ ที่ต้องการบันทึกกิจกรรมเพื่อความปลอดภัยเมตริกการใช้งานและการตรวจสอบ

แน่นอนที่สุดมันขึ้นอยู่กับประเภทของระบบที่คุณกำลังสร้าง

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

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

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

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

อีกจุดหนึ่งจากมุมมองของผู้ดูแลระบบ: คิดถึงการหมุนเวียนบันทึก