สวัสดีทุกคน ชุมชน JavaRush! วันนี้เราจะพูดถึงการบันทึก Java:
- นี่คืออะไร ทำไมถึงเป็นเช่นนั้น ใช้ในกรณีไหนดีกว่ากัน กรณีไหนไม่ใช้?
- การใช้งานการบันทึกใน Java ที่แตกต่างกันมีอะไรบ้าง และเราควรทำอย่างไรกับความหลากหลายนี้
ระดับการบันทึก เรามาคุยกันว่า appender คืออะไรและจะกำหนดค่าอย่างไรให้ถูกต้อง
- การบันทึกโหนดและวิธีกำหนดค่าอย่างถูกต้องเพื่อให้ทุกอย่างทำงานในแบบที่เราต้องการ
เนื้อหานี้มีไว้สำหรับผู้ชมจำนวนมาก จะชัดเจนทั้งกับคนที่เพิ่งทำความคุ้นเคยกับ Java และสำหรับผู้ที่ทำงานอยู่แล้ว แต่คิดแค่กับ
logger.info(“log something”);
Let's Go!
เหตุใดจึงต้องมีการบันทึก?
มาดูกรณีจริงที่การบันทึกจะช่วยแก้ปัญหาได้ นี่คือตัวอย่างจากงานของฉัน มีจุดใช้งานที่บูรณาการกับบริการอื่นๆ ฉันใช้การบันทึกจุดเหล่านี้
เป็น "ข้อแก้ตัว" : หากการบูรณาการใช้งานไม่ได้ ก็จะง่ายต่อการทราบว่าปัญหาเกิดขึ้นจากด้านใด ขอแนะนำให้บันทึกข้อมูลสำคัญที่บันทึกไว้ในฐานข้อมูลด้วย เช่น การสร้างผู้ใช้ที่เป็นผู้ดูแลระบบ นี่คือสิ่งที่ดีที่จะบันทึก
เครื่องมือบันทึก Java
![การบันทึก: อะไร อย่างไร ที่ไหน และด้วยอะไร? - 2]()
โซลูชันที่รู้จักกันดีสำหรับการบันทึกใน Java ได้แก่ :
- log4j
- ก.ค. - java.util.logging
- JCL - การบันทึกข้อมูลทั่วไปของจาการ์ตา
- ย้อนกลับ
- SLF4J - ซุ้มการบันทึกอย่างง่ายสำหรับ java
ลองมาดูแต่ละรายการโดยย่อและในส่วนที่ใช้งานจริงของเนื้อหาเราจะใช้การเชื่อมต่อSlf4j - log4j เป็นพื้นฐาน . ตอนนี้อาจดูแปลก แต่ไม่ต้องกังวล: ในตอนท้ายของบทความทุกอย่างจะชัดเจน |
System.err.println
เริ่มแรกแน่นอนว่ามี
System.err.println (บันทึกเอาต์พุตไปยังคอนโซล) ยังคงใช้เพื่อรับบันทึกอย่างรวดเร็วในระหว่างการดีบัก แน่นอนว่าไม่จำเป็นต้องพูดถึงการตั้งค่าใดๆ ที่นี่ ดังนั้นเรามาจำไว้และเดินหน้าต่อไปกันดีกว่า
ล็อก4เจ
นี่เป็นโซลูชันที่ครบครันซึ่งสร้างขึ้นจากความต้องการของนักพัฒนา มันกลายเป็นเครื่องมือที่น่าสนใจมากที่จะใช้ เนื่องจากสถานการณ์ต่างๆ มากมาย โซลูชันนี้ไม่เคยรวมอยู่ใน JDK ซึ่งทำให้ทั้งชุมชนไม่พอใจอย่างมาก log4j มีตัวเลือกการกำหนดค่าเพื่อให้สามารถเปิดการบันทึกในแพ็คเกจ
com.example.type
และปิดในแพ็คเกจย่อย
com.example.type.generic
ได้ ทำให้สามารถแยกสิ่งที่จำเป็นต้องบันทึกออกจากสิ่งที่ไม่จำเป็นได้อย่างรวดเร็ว สิ่งสำคัญที่ควรทราบคือ
log4j มีสองเวอร์ชัน: 1.2.x และ 2.x.x ซึ่งเข้ากันไม่ได้ log4j เพิ่มแนวคิดเช่น
appenderนั่นคือเครื่องมือที่ใช้บันทึกบันทึกและเค้าโครง - การจัดรูปแบบบันทึก วิธีนี้ช่วยให้คุณบันทึกเฉพาะสิ่งที่คุณต้องการและวิธีที่คุณต้องการเท่านั้น เราจะพูดถึงเพิ่มเติมเกี่ยวกับ appender ในภายหลัง
ก.ค. - java.util.logging
ข้อดีที่สำคัญประการหนึ่งคือโซลูชัน - JUL รวมอยู่ใน JDK (ชุดพัฒนา Java) น่าเสียดายที่ในระหว่างการพัฒนา ไม่ใช่ log4j ยอดนิยมที่ถือเป็นพื้นฐาน แต่เป็นโซลูชันจาก IBM ซึ่งมีอิทธิพลต่อการพัฒนา จริงๆ ตอนนี้มี JUL แต่ไม่มีใครใช้เลย จาก "พอใช้ได้": ใน JUL ระดับการบันทึกจะแตกต่างจากที่อยู่ใน Logback, Log4j, Slf4j และสิ่งนี้ทำให้ความเข้าใจระหว่างกันแย่ลง การสร้างคนตัดไม้มีความคล้ายคลึงไม่มากก็น้อย ในการดำเนินการนี้ คุณจะต้องนำเข้า:
java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());
ชื่อคลาสจะถูกส่งผ่านโดยเฉพาะเพื่อให้ทราบว่าการบันทึกมาจากไหน ตั้งแต่ Java 8 ก็สามารถผ่าน
Supplier<String>
. สิ่งนี้ช่วยในการนับและสร้างสตริงเฉพาะในช่วงเวลาที่จำเป็นจริงๆ เท่านั้น ไม่ใช่ทุกครั้งเหมือนเมื่อก่อน เฉพาะเมื่อมีการเปิดตัว Java 8 เท่านั้นที่นักพัฒนาสามารถแก้ไขปัญหาสำคัญได้หลังจากนั้น JUL ก็สามารถใช้งานได้จริง กล่าวคือวิธีการที่มีอาร์กิวเมนต์
Supplier<String> msgSupplier
ดังแสดงด้านล่าง:
public void info(Supplier<String> msgSupplier) {
log(Level.INFO, msgSupplier);
}
JCL - การบันทึกข้อมูลทั่วไปของจาการ์ตา
เนื่องจากความจริงที่ว่าไม่มีมาตรฐานอุตสาหกรรมในการบันทึกมาเป็นเวลานาน และมีช่วงเวลาที่ผู้คนจำนวนมากสร้างตัวบันทึกแบบกำหนดเองของตนเอง พวกเขาจึงตัดสินใจเปิดตัว JCL ซึ่งเป็น wrapper ทั่วไปที่จะใช้กับผู้อื่น ทำไม เมื่อมีการเพิ่มการขึ้นต่อกันบางอย่างเข้ากับโปรเจ็กต์ พวกเขาสามารถใช้ตัวบันทึกที่แตกต่างจากตัวบันทึกในโปรเจ็กต์ได้ ด้วยเหตุนี้ พวกมันจึงถูกเพิ่มเข้าไปในโปรเจ็กต์แบบชั่วคราว ซึ่งสร้างปัญหาที่แท้จริงเมื่อพยายามรวมทุกอย่างเข้าด้วยกัน น่าเสียดายที่ Wrapper มีฟังก์ชันการทำงานที่แย่มาก และไม่ได้แนะนำส่วนเพิ่มเติมใดๆ คงจะสะดวกถ้าทุกคนใช้ JCL ในการทำงาน แต่ในความเป็นจริงมันไม่ได้ผลเช่นนั้น ดังนั้นการใช้ JCL จึงไม่ใช่ความคิดที่ดีในขณะนี้
ย้อนกลับ
เส้นทางของโอเพ่นซอร์สนั้นยุ่งยากแค่ไหน... Logback เขียนโดยนักพัฒนาคนเดียวกันกับ log4j เพื่อสร้างผู้สืบทอด แนวคิดนี้เหมือนกับ log4j ความแตกต่างก็คือใน logback:
- ปรับปรุงประสิทธิภาพ
- เพิ่มการรองรับเนทิฟสำหรับ slf4j;
- ตัวเลือกการกรองได้รับการขยายแล้ว
ตามค่าเริ่มต้น การล็อกแบ็คไม่จำเป็นต้องมีการตั้งค่าใดๆ และบันทึกบันทึกทั้งหมดตั้งแต่ระดับ DEBUG ขึ้นไป หากจำเป็นต้องมีการกำหนดค่า ก็สามารถทำได้ผ่านการกำหนดค่า xml:
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>app.log</file>
<encoder>
<pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern>
</encoder>
</appender>
<logger name="org.hibernate.SQL" level="DEBUG" />
<logger name="org.hibernate.type.descriptor.sql" level="TRACE" />
<root level="info">
<appender-ref ref="FILE" />
</root>
</configuration>
SLF4J - ซุ้มการบันทึกอย่างง่ายสำหรับ java
ประมาณปี 2549 หนึ่งในผู้ก่อตั้ง log4j ออกจากโครงการและสร้าง slf4j - Simple Logging Facade สำหรับ Java ซึ่งเป็น wrapper รอบ log4j, JUL, common-loggins และ logback อย่างที่คุณเห็น ความคืบหน้าถึงจุดที่พวกเขาสร้าง wrapper ไว้ด้านบนของ wrapper... ยิ่งไปกว่านั้นมันยังแบ่งออกเป็นสองส่วน: API ที่ใช้ในแอปพลิเคชัน และการใช้งานซึ่งเพิ่มเป็น การอ้างอิงแยกกันสำหรับการบันทึกแต่ละประเภท ตัวอย่างเช่น,
slf4j-log4j12.jar
,
slf4j-jdk14.jar
. การเชื่อมต่อการใช้งานที่ถูกต้องก็เพียงพอแล้ว: โครงการทั้งหมดจะใช้งานได้ Slf4j รองรับคุณสมบัติใหม่ทั้งหมด เช่น การจัดรูปแบบสตริงสำหรับการบันทึก ก่อนหน้านี้มีปัญหาเช่นนี้ สมมติว่ามีรายการบันทึก:
log.debug("User " + user + " connected from " + request.getRemoteAddr());
user
มีการแปลงโดยนัย ในออบเจ็กต์
user.toString()
เนื่องจากการต่อสตริง และต้องใช้เวลา ซึ่งทำให้ระบบช้าลง และทุกอย่างก็โอเคถ้าเราดีบักแอปพลิเคชัน ปัญหาเริ่มต้นขึ้นหากระดับการบันทึกสำหรับคลาสนี้เป็น INFO และสูงกว่า นั่นคือไม่ควรเขียนบันทึกนี้ลง และไม่ควรทำการต่อสายอักขระด้วย ตามทฤษฎีแล้ว สิ่งนี้ควรได้รับการตัดสินใจโดยไลบรารีการตัดไม้เอง ยิ่งไปกว่านั้น นี่กลายเป็นปัญหาที่ใหญ่ที่สุดของ log4j เวอร์ชันแรก พวกเขาไม่ได้นำเสนอวิธีแก้ปัญหาตามปกติ แต่แนะนำให้ทำเช่นนี้:
if (log.isDebugEnabled()) {
log.debug("User " + user + " connected from " + request.getRemoteAddr());
}
นั่นคือแทนที่จะเขียนบรรทัดบันทึกบรรทัดเดียว พวกเขาแนะนำให้เขียน 3(!) การบันทึกควรลดการเปลี่ยนแปลงโค้ดให้เหลือน้อยที่สุด และบรรทัดสามบรรทัดขัดแย้งกับแนวทางทั่วไปอย่างชัดเจน slf4j ไม่มีปัญหาความเข้ากันได้กับ JDK และ API ดังนั้นจึงมีวิธีแก้ปัญหาที่สวยงามทันที:
log.debug("User {} connected from {}", user, request.getRemoteAddr());
โดยที่
{}
แสดงถึงการแทรกข้อโต้แย้งที่ถูกส่งผ่านในวิธีการ นั่นคืออันแรก
{}
สอดคล้องกับ
user
อันที่สอง
{}
-
request.getRemoteAddr()
. ด้วยเหตุนี้ เฉพาะในกรณีที่ระดับการบันทึกอนุญาตให้มีการบันทึกได้ ข้อความนี้จึงสามารถต่อกันเป็นข้อความเดียวได้ หลังจากนั้น SJF4J ก็ได้รับความนิยมอย่างรวดเร็วและเป็นทางออกที่ดีที่สุดในปัจจุบัน
slf4j-log4j12
ดังนั้น เราจะพิจารณาการ บันทึก โดยใช้ตัวอย่างของบันเดิล
สิ่งที่ต้องมีการเข้าสู่ระบบ
แน่นอนว่าคุณไม่ควรบันทึกทุกอย่าง บางครั้งสิ่งนี้ก็ไม่จำเป็นและเป็นอันตรายด้วยซ้ำ ตัวอย่างเช่น หากคุณให้คำมั่นสัญญากับข้อมูลส่วนบุคคลของใครบางคนและได้รับการเปิดเผย จะเกิดปัญหาที่แท้จริงขึ้น โดยเฉพาะอย่างยิ่งในโครงการที่มุ่งเน้นไปทางตะวันตก แต่มีบางสิ่งที่
จำเป็นต้องบันทึก :
- เริ่มต้น/สิ้นสุดแอปพลิเคชัน เราจำเป็นต้องรู้ว่าแอปพลิเคชันเปิดตัวจริงตามที่เราคาดหวังและสิ้นสุดตามที่คาดไว้
- คำถามเพื่อความปลอดภัย ที่นี่ เป็นการดีที่จะบันทึกความพยายามในการเดารหัสผ่าน บันทึกการเข้าสู่ระบบของผู้ใช้ที่สำคัญ ฯลฯ
- แอปพลิเค ชันบางสถานะ ตัวอย่างเช่น การเปลี่ยนจากสถานะหนึ่งไปอีกสถานะหนึ่งในกระบวนการทางธุรกิจ
- ข้อมูล บางอย่างสำหรับการดีบักโดยมีระดับการบันทึกที่เหมาะสม
- สคริปต์ SQL บางตัว มีกรณีจริงเมื่อจำเป็น ขอย้ำอีกครั้งว่าด้วยการปรับระดับอย่างเชี่ยวชาญ ก็สามารถบรรลุผลลัพธ์ที่ยอดเยี่ยมได้
- เธรดที่ดำเนินการ (เธรด)สามารถบันทึกได้ในกรณีที่ตรวจสอบการทำงานที่ถูกต้อง
ข้อผิดพลาดในการบันทึกยอดนิยม
มีความแตกต่างมากมาย แต่นี่เป็นข้อผิดพลาดทั่วไปบางประการ:
- การบันทึกส่วนเกิน คุณไม่ควรบันทึกทุกขั้นตอนที่อาจมีความสำคัญในทางทฤษฎี มีกฎอยู่ว่า: บันทึกสามารถโหลดประสิทธิภาพได้ไม่เกิน 10% มิฉะนั้นจะเกิดปัญหาด้านประสิทธิภาพ
- การบันทึกข้อมูลทั้งหมดไว้ในไฟล์เดียว ซึ่งจะทำให้การอ่าน/การเขียนเป็นเรื่องยากมากในบางจุด ไม่ต้องพูดถึงว่ามีการจำกัดขนาดไฟล์ในบางระบบ
- การใช้ระดับการบันทึกที่ไม่ถูกต้อง แต่ละระดับการบันทึกมีขอบเขตที่ชัดเจนและควรได้รับการเคารพ หากขอบเขตไม่ชัดเจนคุณสามารถตกลงได้ว่าจะใช้ระดับใด
ระดับการบันทึก
|
|
|
x: มองเห็นได้ |
|
|
|
|
ร้ายแรง |
ข้อผิดพลาด |
เตือน |
ข้อมูล |
ดีบัก |
ติดตาม |
ทั้งหมด |
ปิด |
|
|
|
|
|
|
|
ร้ายแรง |
x |
|
|
|
|
|
|
ข้อผิดพลาด |
x |
x |
|
|
|
|
|
เตือน |
x |
x |
x |
|
|
|
|
ข้อมูล |
x |
x |
x |
x |
|
|
|
ดีบัก |
x |
x |
x |
x |
x |
|
|
ติดตาม |
x |
x |
x |
x |
x |
x |
|
ทั้งหมด |
x |
x |
x |
x |
x |
x |
x |
ระดับการบันทึกคืออะไร? เพื่อจัดอันดับบันทึก จำเป็นต้องให้ชื่อและความแตกต่างบางประการ เพื่อจุดประสงค์นี้ จึงมีการแนะนำระดับการบันทึก ระดับถูกตั้งค่าไว้ในแอปพลิเคชัน หากรายการอยู่ในระดับต่ำกว่าระดับที่กำหนด รายการนั้นจะไม่ถูกป้อนลงในบันทึก ตัวอย่างเช่น เรามีบันทึกที่ใช้ในการดีบักแอปพลิเคชัน ในงานการผลิตปกติ (เมื่อใช้แอปพลิเคชันตามวัตถุประสงค์) ไม่จำเป็นต้องใช้บันทึกดังกล่าว ดังนั้นระดับการบันทึกจะสูงกว่าการดีบัก มาดูระดับโดยใช้ log4j เป็นตัวอย่าง โซลูชันอื่นๆ ยกเว้น JUL ให้ใช้ระดับเดียวกัน ต่อไปนี้อยู่ในลำดับที่ลดลง:
- ปิด:ไม่มีการเขียนบันทึก ทั้งหมดจะถูกละเว้น
- FATAL:ข้อผิดพลาดหลังจากนั้นแอปพลิเคชันจะไม่สามารถทำงานได้อีกต่อไปและจะหยุดทำงาน ตัวอย่างเช่น JVM ข้อผิดพลาดหน่วยความจำไม่เพียงพอ
- ข้อผิดพลาด:อัตราข้อผิดพลาดเมื่อมีปัญหาที่ต้องแก้ไข ข้อผิดพลาดไม่ได้หยุดแอปพลิเคชันโดยรวม แบบสอบถามอื่นๆ อาจทำงานได้อย่างถูกต้อง
- คำเตือน:ระบุบันทึกที่มีคำเตือน เกิดการกระทำที่ไม่คาดคิด แม้ว่าระบบจะต่อต้านและดำเนินการตามคำขอให้เสร็จสิ้นก็ตาม
- INFO:บันทึกที่บันทึกการกระทำที่สำคัญในแอปพลิเคชัน สิ่งเหล่านี้ไม่ใช่ข้อผิดพลาด สิ่งเหล่านี้ไม่ใช่คำเตือน แต่เป็นการดำเนินการที่คาดหวังของระบบ
- DEBUG:บันทึกที่จำเป็นสำหรับการดีบักแอปพลิเคชัน เพื่อให้แน่ใจว่าระบบทำสิ่งที่คาดหวังไว้อย่างแน่นอน หรือเพื่ออธิบายการกระทำของระบบ: “method1 เริ่มทำงานแล้ว”;
- TRACE:บันทึกที่มีลำดับความสำคัญต่ำกว่าสำหรับการดีบัก โดยมีระดับการบันทึกต่ำที่สุด
- ALL:ระดับที่บันทึกทั้งหมดจากระบบจะถูกบันทึก
ปรากฎว่าหากเปิดใช้งานระดับการบันทึก INFO ในบางตำแหน่งในแอปพลิเคชัน ทุกระดับจะถูกบันทึกโดยเริ่มจาก INFO ไปจนถึง FATAL หากระดับการบันทึกเป็น FATAL เฉพาะบันทึกที่มีระดับนี้เท่านั้นที่จะถูกบันทึก
การบันทึกและส่งบันทึก: ภาคผนวก
เราจะพิจารณากระบวนการนี้โดยใช้ log4j เป็นตัวอย่าง: กระบวนการนี้ให้โอกาสมากมายสำหรับการบันทึก/ส่งบันทึก:
- สำหรับการเขียนลงไฟล์ - โซลูชันDailyRollingFileAppender ;
- เพื่อรับข้อมูลลงในคอนโซลแอปพลิเคชัน - ConsoleAppender ;
- เพื่อเขียนบันทึกลงฐานข้อมูล - JDBCAppender ;
- ควบคุมการส่งข้อมูลผ่าน TCP/IP - TelnetAppender ;
- เพื่อให้แน่ใจว่า การบันทึกไม่ส่งผลต่อประสิทธิภาพ - AsyncAppender
มีการใช้งานอื่นๆ อีกหลายรายการ: สามารถดูรายการทั้งหมดได้ที่
นี่ อย่างไรก็ตาม หากไม่มี appender ที่จำเป็น ก็ไม่ใช่ปัญหา คุณสามารถเขียน appender ของคุณเองได้โดยใช้
Appender interface ซึ่งเพิ่งยอมรับ log4j
โหนดการบันทึก
สำหรับการสาธิต เราจะใช้อินเทอร์เฟซ slf4j และการใช้งานจาก log4j การสร้างตัวบันทึกนั้นง่ายมาก: คุณต้องเขียนสิ่งต่อไปนี้ในคลาสที่ชื่อ
MainDemo
ซึ่งจะทำการบันทึก:
org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MainDemo.class);
สิ่งนี้จะสร้างคนตัดไม้ให้เรา หากต้องการสร้างรายการบันทึก คุณสามารถใช้วิธีการต่างๆ มากมายเพื่อระบุระดับรายการที่จะทำ ตัวอย่างเช่น:
logger.trace("Method 1 started with argument={}", argument);
logger.debug("Database updated with script = {}", script);
logger.info("Application has started on port = {}", port);
logger.warn("Log4j didn't find log4j.properties. Please, provide them");
logger.error("Connection refused to host = {}", host);
แม้ว่าเราจะผ่านคลาส แต่สุดท้ายมันก็เป็นชื่อเต็มของคลาสพร้อมแพ็คเกจที่เขียนไว้ การทำเช่นนี้เพื่อให้คุณสามารถแบ่งการเข้าสู่ระบบออกเป็นโหนด และกำหนดค่าระดับการบันทึกและผู้ผนวกสำหรับแต่ละโหนด ตัวอย่างเช่น ชื่อของคลาส:
com.github.romankh3.logginglecture.MainDemo
- มีการสร้างคนตัดไม้ในนั้น และนี่คือวิธีที่สามารถแบ่งออกเป็นโหนดการบันทึกได้ โหนดหลักคือ
RootLogger ที่เป็น โมฆะ นี่คือโหนดที่ได้รับบันทึกทั้งหมดของแอปพลิเคชันทั้งหมด ส่วนที่เหลือสามารถอธิบายได้ดังที่แสดงด้านล่าง:
![การบันทึก: อะไร อย่างไร ที่ไหน และด้วยอะไร? - 4]()
ผู้ผนวกกำหนดค่างานของตนโดยเฉพาะบนโหนดการบันทึก
ตอนนี้ เมื่อใช้ log4j.propertiesเป็นตัวอย่างเราจะมาดูวิธีการกำหนดค่า
การกำหนดค่าทีละขั้นตอนของ Log4j.properties
ตอนนี้เราจะตั้งค่าทุกอย่างทีละขั้นตอนและดูว่าสามารถทำอะไรได้บ้าง:
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
บรรทัดนี้บอกว่าเรากำลังลงทะเบียน CONSOLE appender ที่ใช้งาน org.apache.log4j.ConsoleAppender ภาคผนวกนี้เขียนข้อมูลไปยังคอนโซล ต่อไป มาลงทะเบียน appender อื่นที่จะเขียนลงในไฟล์:
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
สิ่งสำคัญคือต้องทราบว่าผู้ผนวกจะยังคงต้องได้รับการกำหนดค่า เมื่อเราลงทะเบียน appender แล้ว เราก็สามารถกำหนดระดับของการบันทึกที่จะอยู่ในโหนด และ appender ใดที่จะใช้
log4j.rootLogger=ดีบัก, คอนโซล, ไฟล์
- log4j.rootLogger หมายความว่าเราจะกำหนดค่าโหนดหลักซึ่งมีบันทึกทั้งหมด
- หลังจากเครื่องหมายเท่ากับ คำแรกจะระบุว่าบันทึกจะถูกบันทึกในระดับใดและสูงกว่า (ในกรณีของเรานี่คือ DEBUG)
- จากนั้นหลังจากเครื่องหมายจุลภาค ภาคผนวกทั้งหมดที่จะใช้จะถูกระบุ
ในการกำหนดค่าโหนดการบันทึกเฉพาะ คุณต้องใช้รายการต่อไปนี้:
log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE
โดยที่
log4j.logger.
มันถูกใช้เพื่อกำหนดค่าโหนดเฉพาะ ในกรณีของเราคือ
com.github.romankh3.logginglecture.
และตอนนี้เรามาพูดถึงการตั้งค่าส่วนต่อท้าย CONSOLE:
# CONSOLE appender customisation
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%-5p] : %c:%L : %m%n
ที่นี่เราจะเห็นว่าเราสามารถกำหนดระดับที่ appender จะดำเนินการได้ สถานการณ์จริง: โหนดการบันทึกได้รับข้อความที่มีระดับข้อมูลและส่งต่อไปยังผู้ผนวกที่ได้รับมอบหมาย แต่ผู้ผนวกที่มีระดับการเตือนและสูงกว่านั้นยอมรับบันทึกนี้ แต่ไม่ได้ทำอะไรเลย ถัดไป คุณต้องตัดสินใจว่าจะใส่เทมเพลตใดในข้อความ ฉันใช้ PatternLayout ในตัวอย่าง แต่มีวิธีแก้ปัญหามากมาย พวกเขาจะไม่ถูกเปิดเผยในบทความนี้ ตัวอย่างการตั้งค่า appender FILE:
# File appender customisation
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=./target/logging/logging.log
log4j.appender.FILE.MaxFileSize=1MB
log4j.appender.FILE.threshold=DEBUG
log4j.appender.FILE.MaxBackupIndex=2
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[ %-5p] - %c:%L - %m%n
ที่นี่คุณสามารถกำหนดค่าไฟล์ที่จะเขียนบันทึกได้ ดังที่เห็นได้จาก
log4j.appender.FILE.File=./target/logging/logging.log
การบันทึกไปที่ไฟล์
logging.log
. เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับขนาดไฟล์ คุณสามารถตั้งค่าสูงสุดได้: ในกรณีนี้คือ 1MB MaxBackupIndex - บอกจำนวนไฟล์ดังกล่าว หากสร้างเกินจำนวนนี้ ไฟล์แรกจะถูกลบ หากต้องการดูตัวอย่างจริงที่มีการกำหนดค่าการบันทึก คุณสามารถไปที่
พื้นที่เก็บข้อมูลแบบเปิดบน GitHub
มารวมผลลัพธ์กัน
ลองทำทุกอย่างที่อธิบายเกี่ยวกับตัวคุณเอง:
- สร้างโครงการของคุณเองคล้ายกับโครงการในตัวอย่างด้านบน
- หากคุณมีความรู้เกี่ยวกับการใช้ Maven เราจะใช้มัน แต่ถ้าไม่มี นี่คือลิงก์ไปยังบทความที่อธิบายวิธีเชื่อมต่อไลบรารี
มาสรุปกัน
- เราได้พูดคุยกันว่ามีโซลูชันใดบ้างใน Java
- ไลบรารีการบันทึกที่รู้จักเกือบทั้งหมดถูกเขียนภายใต้การควบคุมของบุคคลเดียว :D
- เราเรียนรู้ว่าสิ่งใดที่ต้องบันทึกและสิ่งใดไม่ควร
- เราหาระดับการบันทึกได้
- เราคุ้นเคยกับโหนดการบันทึก
- เราดูว่า appender คืออะไรและมีไว้เพื่ออะไร
- เรากำหนดค่าไฟล์ log4j.proterties ทีละขั้นตอน
วัสดุเพิ่มเติม
- JavaRush: การบันทึก ผ่อนคลายลูกบอลสเตกเทรซ
- JavaRush: การบรรยาย Logger
- Habr: การบันทึก Java สวัสดีชาวโลก
- Habr: Java การบันทึก: เรื่องราวของฝันร้าย
- Youtube: หลักสูตร Golovach การบันทึก ส่วนที่ 1ส่วนที่2 ส่วนที่ 3ส่วนที่ 4
- Log4j: ภาคผนวก
- Log4j: เค้าโครง
ดูบทความอื่น ๆ ของฉันด้วย:
GO TO FULL VERSION