วิเคราะห์ Log ไฟล์: วิธีใช้และเครื่องมือในการแก้ปัญหาเซิร์ฟเวอร์

Log ไฟล์คืออะไร และทำไมถึงต้องดูแล?

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

เซิร์ฟเวอร์ Apache, Nginx, PHP-FPM, MySQL แต่ละตัวเก็บ Log เป็นของตัวเอง บางทีปัญหาเกิดจากเวบแอปพลิเคชัน บางทีเกิดจากการตั้งค่าเซิร์ฟเวอร์ หรือบางทีคือปัญหาฮาร์ดแวร์ ถ้าเราไม่ดู Log เราจะแก้ปัญหาแบบปู่มาบอก—ลองนี่ลองนั่น ที่สุดก็ยอมแพ้ไปเฉยๆ

โฟลเดอร์ Log สำคัญๆ อยู่ที่ไหนบ้าง?

ส่วนใหญ่ใน Linux (เซิร์ฟเวอร์สาธารณะ) Log จะอยู่ใน /var/log/ นี่คือห้องเก็บเอกสารใหญ่ๆ ของระบบ

• /var/log/apache2/ — Log ของ Apache Web Server (access_log, error_log)
• /var/log/nginx/ — Log ของ Nginx Web Server
• /var/log/mysql/ — Log ของ MySQL Database
• /var/log/php-fpm.log — Log ของ PHP ถ้าใช้ FastCGI
• /var/log/syslog — Log ระบบทั่วไป
• /var/log/auth.log — Log การเข้าสู่ระบบและความปลอดภัย

ถ้าใช้ cPanel หรือ Plesk ตำแหน่งอาจต่างหน่อย แต่คิดแนวเดียวกัน เวบไซต์แต่ละตัวก็มี Log เป็นของตัวเองอยู่ใน folder ของเวบไซต์นั้น

ฉันสตาร์ทด้วยการดู Log ตัวไหนก่อนดี?

ถ้าเวบไซต์แสดง Error 500 หรือขึ้นหน้าขาว อันดับแรกให้ไปดู error log ของเวบไซต์นั้นสำหรับ ส่วนใหญ่จะอยู่ในโฟลเดอร์ public_html หรือ www ของเวบไซต์ ชื่ออาจเป็น error_log หรือ error.log

ถ้าไม่มี Log เวบไซต์ อย่างไรก็ลองดู error_log ของ Apache ที่ /var/log/apache2/error_log โดยตามหาข้อผิดพลาดที่เกี่ยวข้องกับโดเมนหรือ IP ของเวบไซต์นั้น

อีกวิธีที่เร็วมาก คือการดู Log ล่าสุด ไปเลย โดยใช้คำสั่ง:

tail -f /path/to/error_log

สั่งนี้จะแสดงข้อมูล 10 บรรทัดสุดท้าย และ "-f" ตรวจสอบแบบเรียลไทม์ ช่วยเมื่อต้องทำให้เกิดข้อผิดพลาดอีกครั้งเพื่ออ่าน Log

จะอ่านและเข้าใจ Log ได้ยังไง?

ลองดูตัวอย่าง error log ของ Apache:

[Wed Oct 25 14:32:18.492851 2023] [php:error] [pid 12345] [client 192.168.1.1:54321] PHP Fatal error: Uncaught Exception: Database connection failed in /var/www/html/config.php:42

นี่บอกเราว่า:

• วันเวลา — เมื่อไหร่เกิดข้อผิดพลาด
• [php:error] — ข้อผิดพลาดมาจาก PHP
• pid 12345 — ตัวเลขกระบวนการ (Process ID) ที่เกี่ยวข้อง
• [client 192.168.1.1] — ใครมาขอแฟ้ม (IP Address)
• PHP Fatal error — ประเภทข้อผิดพลาด
• Database connection failed — สาเหตุแท้จริง
• /var/www/html/config.php:42 — ไฟล์ไหนบรรทัดไหน

สำหรับ access log (log ที่บันทึกการขอและตอบ):

192.168.1.1 - - [25/Oct/2023:14:32:18 +0700] "GET /index.php HTTP/1.1" 500 1234 "-" "Mozilla/5.0"

ความหมายคร่าวๆ:

• 192.168.1.1 — IP ของผู้ขอ
• GET /index.php HTTP/1.1 — วิธีการ (GET, POST) กับ URL
• 500 — HTTP Status Code (500 = Server Error)
• 1234 — ขนาดไฟล์ที่ตอบกลับ (bytes)

ถ้าเห็น Status Code 404 แสดงว่าไม่หาไฟล์ 403 คือไม่มีสิทธิ์เข้า 200 คือสำเร็จแล้ว (ข้าว)

เครื่องมือหรือคำสั่งไหนใช้ในการวิเคราะห์ Log ได้อย่างมืออาชีพ?

ถ้าโดยมือ tail กับ grep ก็พอใช้แล้ว แต่มีเครื่องมือที่ทำให้ชีวิตง่ายขึ้น:

• tail -f — ดู Log เรียลไทม์
• grep — ค้นหาข้อมูลในไฟล์ ตัวอย่างเช่น grep "error" error_log เพื่อหาบรรทัดที่มีคำว่า "error"
• less — อ่าน Log ไฟล์ขนาดใหญ่โดยไม่ต้องโหลดทั้งหมด
• awk — นำเสนอข้อมูลในรูปแบบที่เข้าใจง่าย
• sed — แก้ไขหรือกรองข้อมูล Log

ตัวอย่างการใช้ grep ที่ประโยชน์:

grep "PHP Fatal" /var/www/html/error_log | tail -20

สั่งนี้จะหา 20 บรรทัดสุดท้ายที่มี "PHP Fatal" ในนั้น ช่วยเวลาต้องหาข้อผิดพลาดเดิมๆ

อีกวิธี คือใช้เครื่องมือ Web UI เช่น Nginx Amplify หรือ GoAccess หรือโดยภาพ ง่ายกว่าหลายเท่า แต่สำหรับเซิร์ฟเวอร์ว่าๆ ไม่มีติดตั้ง ต้องลงเพิ่มเติม

จะรู้ได้ไงว่าปัญหามาจากไหน? Error Code มีความหมายอย่างไร?

HTTP Status Code นั้นสำคัญมากในการเดาสาเหตุ:

• 2xx — สำเร็จ (200 OK, 201 Created)
• 3xx — เปลี่ยนเส้นทาง (301 Moved, 302 Found)
• 4xx — ขอผิด (404 Not Found, 403 Forbidden, 400 Bad Request)
• 5xx — เซิร์ฟเวอร์ผิด (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)

ถ้าเห็น 502 Bad Gateway ส่วนใหญ่คือ PHP-FPM down หรือไม่ตอบสนอง ลองรีสตาร์ท PHP-FPM ก่อน ถ้าเป็น 503 Service Unavailable อาจเป็นเวบเซิร์ฟเวอร์หยุดชั่วคราว หรือ Load สูงเกินไป

สำหรับ 500 Internal Server Error นั่นคือเรื่องสบสัน—อาจเกิดจากอะไรก็ได้ ต้องดู error log เพื่อดูรายละเอียด

ปรับตั้งการบันทึก Log อย่างไรให้เห็นมากพอแต่ไม่ยุ่งเหยิง?

ตั้งค่า Log ให้เหมาะสมเป็นเรื่องศิลป์นิยมเล่นซ้ำไปซ้ำมา ถ้า Log ระดับเล็กเกินไป (เช่น error log อาจจะบัน error จริงๆ แค่ที่สำคัญ) หรือ Log ระดับใหญ่เกินไป (notice, warning ทั้งหมด) จะทำให้ Log ไฟล์บอบแบบจดจำจนเต็มดิสก์

วิธีที่นิยม: ตั้ง Log level เป็น ERROR หรือ WARN สำหรับ production แต่เมื่อเกิดปัญหาเปลี่ยนเป็น DEBUG ชั่วคราวเพื่อดูรายละเอียดทั้งหมด

สำหรับ Apache, ตั้งค่าใน VirtualHost config:

LogLevel warn

สำหรับ PHP, ตั้งใน php.ini:

error_reporting = E_WARNING | E_ERROR

เคล็ดลับเพิ่มเติม: ตั้ง Log rotation ให้แล้ว ไม่ต้องเก็บ Log เดิมซ้ำๆ จนเต็มดิสก์ เซิร์ฟเวอร์สมัยใหม่มี logrotate ทำได้เองแล้ว ตั้งค่าในไฟล์ config ก็พอ

ถ้า Log ไฟล์มีขนาดใหญ่มากและค้นหาช้า ต้องทำไง?

ไฟล์ Log ขนาดหลายร้อย MB จนหลายร้อย GB นั้นเป็นเรื่องปกติของเซิร์ฟเวอร์ที่รับ traffic เยอะ ปัญหาคือการค้นหา grep ก็ช้ากระทั่งเสียเวลา

วิธีแรก: ตัดเฉพาะช่วงวันที่ที่ต้องการดู โดยการ filter ด้วย grep ก่อน นอกจากนี้ยังมี zgrep สำหรับไฟล์ที่ถูก compress เช่น .gz

zgrep "error" /var/log/apache2/error_log.1.gz

วิธีที่สอง: ใช้คำสั่ง awk เพื่อนำเสนอข้อมูล ถ้ามีคำขออื่นๆ ที่นอกเหนือจากช่วงวันที่

วิธีที่สาม: ตั้งค่า Log rotation บ่อยขึ้น ตัวอย่างเช่น rotation ทุก 1 วันแทนที่ 1 เดือน ไฟล์ตัวอักษรเล็กพอ จึงเร็วกว่า

แล้วก็มีเครื่องมือเหล่านี้ช่วยได้:

• splunk — เครื่องมือรายงาน Log มืออาชีพสำหรับองค์กร (มีค่าใช้จ่าย)
• ELK Stack (Elasticsearch, Logstash, Kibana) — เก็บ Log บน cloud เพื่อให้ค้นหาเร็ว
• GoAccess — เครื่องมือวิเคราะห์ access log แบบ dashboard

สำหรับสตาร์ทอัพหรือเซิร์ฟเวอร์ขนาดกลาง GoAccess ก็พอใจใจ ลงสามารถอีกสองคำสั่งเท่านั้น

ตัวอย่างการ Debug ปัญหาจริงๆ ด้วย Log

สมมติว่าเวบไซต์ WordPress ของเราขึ้น Error 500 หลังจากอัพเดท Plugin

ขั้นที่ 1: ตรวจสอบ error_log ของเวบไซต์

tail -50 /var/www/html/wp-content/error_log

พบว่า: "Fatal error: Call to undefined function get_post_meta()" ในไฟล์ Plugin บางตัว

ขั้นที่ 2: ตรวจสอบ error log ของ Apache ด้วย

tail -20 /var/log/apache2/error_log | grep "my-domain.com"

พบว่า PHP-FPM เป็นสาเหตุ แต่ไม่ได้หยุด แค่ error นั่นแหละ

ขั้นที่ 3: ยังไม่พอ ตรวจสอบว่า Plugin ตัวไหน โดยดู error message ชั้นสอง

grep "my-plugin-name" /var/www/html/wp-content/error_log

พบว่า Plugin ตัวที่เพิ่งอัพเดท ไม่เข้ากับเวอร์ชัน WordPress เวอร์ชันปัจจุบัน

ขั้นที่ 4: Deactivate Plugin นั้นหรือ downgrade ไป version ก่อนหน้า ปัญหาเฮงสลาย

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

สรุป: ความสำคัญของการดู Log เป็นประจำ

ถ้ามีเวลา ลองตั้งการตรวจสอบ Log เป็นกิจวัตรประจำวัน—อย่างน้อยถ้ามีข้อผิดพลาดจะจับได้เร็ว เซิร์ฟเวอร์ไม่จำเป็นต้องแพร่ระบาดเป็น Outage เต็มรูปแบบ

อีกอย่างนึง อย่าลืมว่า Log เป็นสมบัติทางกฎหมายด้วย บางทีต้องเก็บไว้ เพื่อการตรวจสอบความปลอดภัย หรือเหตุการณ์ที่ผิดปกติ ถ้าไม่มี Log เวลามีปัญหาความปลอดภัย (เช่น แฮก) เราจะตรวจสอบอดิตไม่ได้เลย

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