Linux
Linux Log Management Journald Rsyslog
Linux Log Management Journald Rsyslog คืออะไร / ทำไมถึงสำคัญ
น้องๆ เคยสงสัยไหมว่าเวลาเครื่อง Linux เรามีปัญหาเนี่ย เราจะไปดู Log ตรงไหน? แล้ว Log มันสำคัญยังไง? สมัยผมทำร้านเน็ต SiamCafe นะ บอกเลยว่า Log นี่แหละคือพระเอกช่วยชีวิตหลายครั้งเลย เพราะมันบันทึกทุกอย่างที่เกิดขึ้นในระบบ ตั้งแต่ใคร Login เข้ามา, โปรแกรมอะไร crash, ไปจนถึง error ต่างๆ ที่เกิดขึ้น ถ้าเราอ่าน Log เป็น เราก็จะสามารถหาสาเหตุของปัญหาและแก้ไขมันได้ทันท่วงที
ทีนี้ Linux Log Management เนี่ย มันก็คือการจัดการ Log file พวกนี้แหละครับ ให้เป็นระบบ ระเบียบ อ่านง่าย และที่สำคัญคือ เก็บรักษาไว้ได้อย่างปลอดภัย เพราะบางครั้ง Log เหล่านี้ก็เป็นหลักฐานสำคัญในกรณีที่มีปัญหาด้าน Security หรือ Audit ด้วย
ใน Linux เนี่ย เครื่องมือหลักๆ ที่เราใช้จัดการ Log ก็คือ Journald และ Rsyslog ครับ ซึ่งเดี๋ยวเราจะมาเจาะลึกกันว่าแต่ละตัวมันทำงานยังไง และเราจะใช้มันจัดการ Log ของเราให้มีประสิทธิภาพได้อย่างไร
พื้นฐานที่ต้องรู้
Journald คืออะไร?
Journald เนี่ย เป็นระบบ Log ที่ติดมากับ systemd ซึ่งเป็น init system หลักของ Linux หลายๆ Distro ในปัจจุบัน (เช่น Ubuntu, Fedora, CentOS 7 ขึ้นไป) ข้อดีของ Journald คือมันทำงานแบบ Binary ทำให้เก็บ Log ได้อย่างรวดเร็ว และมีประสิทธิภาพ แถมยังสามารถ Query Log ได้ง่ายด้วยคำสั่ง journalctl
สมัยก่อนตอนผมทำร้านเน็ตเนี่ย ยังไม่มี Journald หรอก ใช้แต่ Rsyslog อย่างเดียว แต่พอมี Journald แล้วชีวิตง่ายขึ้นเยอะ เพราะมันเก็บ Log ได้ละเอียดกว่า และค้นหาได้เร็วกว่าเยอะมากๆ
Rsyslog คืออะไร?
Rsyslog เนี่ย เป็นระบบ Log ที่เก่าแก่กว่า Journald มากๆ แต่ก็ยังได้รับความนิยมอยู่ เพราะมันมีความยืดหยุ่นสูง สามารถปรับแต่งได้เยอะ และรองรับการส่ง Log ไปยัง Server อื่นๆ ได้ด้วย Rsyslog ทำงานโดยการอ่าน Log จากไฟล์ต่างๆ (เช่น /var/log/syslog, /var/log/auth.log) แล้วประมวลผลตาม Rule ที่เรากำหนดไว้
Rsyslog เนี่ย เหมือนเป็นครูพักลักจำสมัยผมเรียนเลย คือต้องค่อยๆ ศึกษา Rule ต่างๆ แล้วปรับแต่งให้เข้ากับความต้องการของเรา แต่พอทำเป็นแล้ว มันก็เป็นเครื่องมือที่ทรงพลังมากๆ
ความแตกต่าง Journald vs Rsyslog
Journald และ Rsyslog ต่างก็มีข้อดีข้อเสียของตัวเอง Journald เหมาะสำหรับใช้งานในเครื่องตัวเอง เพราะมันเก็บ Log ได้อย่างรวดเร็ว และค้นหาได้ง่าย แต่ Rsyslog เหมาะสำหรับส่ง Log ไปยัง Server อื่นๆ หรือต้องการปรับแต่ง Rule การจัดการ Log อย่างละเอียด
สมัยนี้หลายๆ ระบบก็ใช้ทั้งสองอย่างควบคู่กันไป Journald เก็บ Log ในเครื่องตัวเอง ส่วน Rsyslog ทำหน้าที่ส่ง Log ไปยัง Centralized Log Server เพื่อเก็บรักษาและวิเคราะห์
วิธีใช้งาน / เริ่มต้นยังไง
เอาล่ะ ทีนี้เรามาดูวิธีการใช้งาน Journald และ Rsyslog กันบ้าง เริ่มจาก Journald ก่อนเลย
ขั้นตอนปฏิบัติจริง
การใช้งาน Journald
คำสั่งหลักในการใช้งาน Journald ก็คือ journalctl ครับ ลองพิมพ์ journalctl ใน Terminal ดู จะเห็น Log ทั้งหมดที่ Journald เก็บไว้
journalctl
ถ้าอยากดู Log เฉพาะช่วงเวลา ก็ใช้ Option --since และ --until ได้ครับ เช่น
journalctl --since "yesterday" --until "now"
หรือถ้าอยากดู Log เฉพาะของ Service ใด Service หนึ่ง ก็ใช้ Option -u ได้ครับ เช่น
journalctl -u nginx
Journald ยังมี Option อื่นๆ อีกมากมาย ลองพิมพ์ man journalctl ใน Terminal เพื่อดูรายละเอียดทั้งหมดได้เลย
น้องๆ ลองเอาไปเล่นดูนะ แล้วจะรู้ว่า Journald เนี่ย มันช่วยให้เรา Debug ปัญหาได้ง่ายขึ้นเยอะเลย
การใช้งาน Rsyslog
Rsyslog เนี่ย Config file หลักๆ จะอยู่ที่ /etc/rsyslog.conf ครับ ในไฟล์นี้ เราจะกำหนด Rule ต่างๆ ว่าจะให้ Rsyslog ทำอะไรกับ Log ที่เข้ามาบ้าง
ตัวอย่าง Rule ง่ายๆ ก็คือการส่ง Log ทั้งหมดไปยังไฟล์ /var/log/all.log
*.* /var/log/all.log
Rule นี้หมายความว่า Log ทุกประเภท (*.*) จะถูกส่งไปยังไฟล์ /var/log/all.log
Rsyslog เนี่ย มี Rule ให้เล่นเยอะมาก น้องๆ สามารถกำหนด Rule ให้ส่ง Log ไปยัง Server อื่นๆ ได้, Filter Log ตาม Severity ได้, หรือแม้แต่ส่ง Log ไปยัง Database ก็ยังได้
ถ้าอยากศึกษา Rsyslog อย่างละเอียด ลองดูที่ SiamCafe Blog นะครับ ผมเคยเขียนบทความเกี่ยวกับ Rsyslog ไว้ละเอียดมากๆ
เปรียบเทียบกับทางเลือกอื่น
นอกจาก Journald และ Rsyslog แล้ว ก็ยังมีเครื่องมือ Log Management อื่นๆ อีก เช่น Syslog-ng, Graylog, ELK Stack (Elasticsearch, Logstash, Kibana) แต่ละตัวก็มีข้อดีข้อเสียแตกต่างกันไป
Syslog-ng เนี่ย คล้ายๆ กับ Rsyslog คือมีความยืดหยุ่นสูง และรองรับการส่ง Log ไปยัง Server อื่นๆ ได้ แต่ Syslog-ng จะมี Feature ที่ Rsyslog ไม่มี เช่น การ Filter Log ด้วย Regular Expression
Graylog และ ELK Stack เนี่ย เป็น Centralized Log Management System ที่มี Feature ครบครัน ตั้งแต่การเก็บ Log, การวิเคราะห์ Log, ไปจนถึงการ Visualize Log แต่ข้อเสียคือต้องใช้ Resource เยอะ และต้อง Setup ค่อนข้างซับซ้อน
สมัยผมทำร้านเน็ต ผมเคยลองใช้ ELK Stack อยู่พักนึง แต่สุดท้ายก็กลับมาใช้ Rsyslog เพราะมันง่ายกว่า และกิน Resource น้อยกว่า
| เครื่องมือ | ข้อดี | ข้อเสีย |
|---|---|---|
| Journald | รวดเร็ว, มีประสิทธิภาพ, Query ง่าย | ไม่เหมาะสำหรับส่ง Log ไปยัง Server อื่นๆ |
| Rsyslog | ยืดหยุ่นสูง, ปรับแต่งได้เยอะ, รองรับการส่ง Log ไปยัง Server อื่นๆ | Config ซับซ้อน |
| Syslog-ng | คล้าย Rsyslog แต่มี Feature เพิ่มเติม | Config ซับซ้อน |
| Graylog / ELK Stack | Feature ครบครัน, Centralized Log Management | ใช้ Resource เยอะ, Setup ซับซ้อน |
เลือกเครื่องมือไหน ก็ขึ้นอยู่กับความต้องการ และ Resource ที่เรามี ถ้าต้องการแค่จัดการ Log ในเครื่องตัวเอง Journald ก็เพียงพอแล้ว แต่ถ้าต้องการ Centralized Log Management หรือต้องการปรับแต่ง Rule การจัดการ Log อย่างละเอียด Rsyslog, Syslog-ng, Graylog, หรือ ELK Stack ก็เป็นทางเลือกที่น่าสนใจ
ลองศึกษาดูนะครับ แล้วเลือกเครื่องมือที่เหมาะกับเราที่สุด และอย่าลืมแวะไปอ่านบทความอื่นๆ ใน SiamCafe Blog ด้วยนะครับ มีบทความ IT ดีๆ อีกเยอะเลย
🎬 วิดีโอแนะนำ
ดูวิดีโอเพิ่มเติมเกี่ยวกับLinux Log Management Journald :
Best Practices / เคล็ดลับจากประสบการณ์
เอาล่ะ มาถึงส่วนที่สำคัญที่สุดแล้ว เคล็ดลับที่ผมสั่งสมมาตลอด 20 กว่าปีในการดูแลระบบ Linux โดยเฉพาะเรื่อง Log Management นี่แหละ สมัยผมทำร้านเน็ต SiamCafe นี่เจอปัญหามาหมดแล้ว เชื่อผมเถอะว่าสิ่งที่ผมกำลังจะบอกต่อไปนี้ มันช่วยคุณประหยัดเวลาไปได้เยอะเลย
1. Standardize Log Format
เรื่องนี้สำคัญมาก! ทำให้รูปแบบ Log เป็นมาตรฐานเดียวกันทั้งระบบ ไม่ว่าจะใช้ Journald หรือ Rsyslog ก็ตาม จะช่วยให้การค้นหาและวิเคราะห์ง่ายขึ้นเยอะ สมัยก่อนผมไม่ได้ทำแบบนี้ เวลาไล่ Bug ที ปวดหัวมาก เพราะแต่ละ Service ก็ Log ไม่เหมือนกัน
# ตัวอย่าง Rsyslog configuration
template(name="MyFormat" type="string" string="%timestamp:::date-rfc3339% %hostname% %programname% %msg%\n")
*.* /var/log/everything.log;MyFormat
ลองดู Code ข้างบน ผมกำหนด Template ชื่อ MyFormat ให้มี Timestamp, Hostname, Programname, และ Message แล้วเอาไปใช้กับทุก Log ที่ส่งไปที่ /var/log/everything.log แบบนี้แหละคือ Standardize
2. Centralized Logging
ถ้ามี Server หลายตัว อย่าเก็บ Log ไว้ในแต่ละ Server เลย รวมศูนย์ Log ไปไว้ที่ Server กลางตัวเดียวดีกว่า จะได้ไม่ต้อง Login เข้าไปดูทีละเครื่อง ตอนเกิดปัญหาอะไรขึ้นมา ทีเดียวจบ!
สมัยร้านเน็ตผม มีเครื่องลูกเป็นสิบๆ เครื่อง ถ้าไม่ได้ทำ Centralized Logging นี่ตายเลย ไล่หา Bug กันทั้งวัน
3. Rotate Logs Regularly
Log file มันโตเร็วมาก! ถ้าไม่ Rotate นี่ HDD เต็มเอาง่ายๆ แล้วระบบก็จะ Error วิธีแก้ก็ง่ายๆ ใช้ Logrotate ไงครับ ตั้งค่าให้มัน Rotate ทุกวัน ทุกอาทิตย์ หรือทุกเดือน ก็ว่ากันไป ตามความเหมาะสม
# ตัวอย่าง /etc/logrotate.d/myapp
/var/log/myapp.log {
daily
rotate 7
missingok
notifempty
compress
delaycompress
}
จาก Code ข้างบน ผมสั่งให้ Logrotate หมุน Log ของ myapp.log ทุกวัน เก็บไว้ 7 วัน แล้วก็ Compress ด้วย
4. Monitor Log Size
ถึงแม้จะ Rotate Log แล้ว ก็ยังต้อง Monitor ขนาดของ Log file อยู่ดี เพราะบางที Application มัน Error แล้ว Log รัวๆ จน HDD เต็มได้เหมือนกัน ผมเคยเจอเคสนี้มาแล้ว ต้องรีบเข้าไปเคลียร์ Log กันจ้าละหวั่น
FAQ คำถามที่พบบ่อย
Journald กับ Rsyslog อันไหนดีกว่ากัน?
อันนี้ตอบยากครับ มันขึ้นอยู่กับความต้องการของคุณมากกว่า ถ้าต้องการความง่ายในการใช้งาน Rsyslog ก็เป็นตัวเลือกที่ดี แต่ถ้าต้องการ Feature ที่ Advanced กว่า Journald ก็ตอบโจทย์กว่า แต่ถ้าให้ผมแนะนำนะ ลองใช้ทั้งคู่ควบคู่กันไปเลย! Journald เก็บ Log ของ Systemd Rsyslog เก็บ Log ของ Application อื่นๆ
ทำไม Log file มันใหญ่จัง?
Log file ใหญ่ได้หลายสาเหตุครับ หนึ่งคือ Application มัน Log เยอะเกินไป สองคือไม่ได้ Rotate Log สามคือตั้งค่า Log Level ไว้ละเอียดเกินไป ลองตรวจสอบดูทีละอย่างนะครับ
จะค้นหา Log ยังไงให้เร็ว?
ถ้าใช้ Rsyslog ก็ลองใช้คำสั่ง grep หรือ awk ดูครับ แต่ถ้าใช้ Journald ก็ใช้คำสั่ง journalctl ซึ่งมี Option ให้ Filter เยอะแยะมากมาย ลองศึกษาดูนะครับ
Log level คืออะไร? มีอะไรบ้าง?
Log level คือระดับความสำคัญของ Log message ครับ มีตั้งแต่ DEBUG, INFO, WARNING, ERROR, ไปจนถึง CRITICAL ปกติเราจะตั้งค่า Log level ไว้ที่ INFO หรือ WARNING เพื่อไม่ให้ Log มันเยอะเกินไป แต่ถ้าต้องการ Debug อะไรบางอย่าง ก็ค่อยปรับเป็น DEBUG เป็นครั้งคราว
สรุป
เรื่อง Log Management นี่เป็นเรื่องที่สำคัญมากในการดูแลระบบ Linux ครับ ถ้าทำดีๆ มันจะช่วยให้คุณแก้ไขปัญหาได้เร็วขึ้นเยอะ แต่ถ้าทำไม่ดี ก็จะกลายเป็นภาระที่ต้องมานั่งปวดหัวอยู่เรื่อยๆ หวังว่าบทความนี้จะเป็นประโยชน์กับทุกคนนะครับ ถ้ามีคำถามอะไรเพิ่มเติม ถามมาได้เลย ยินดีตอบเสมอ iCafeForex ก็เป็นอีกธุรกิจที่ผมทำ ควบคู่ไปกับ SiamCafe Blog นี่แหละครับ
