ไอเดีย #69: ระบบรวม log และค้นหา (log viewer เล็ก ๆ)

ตี 2 ระบบลูกค้า error ต้อง SSH เข้าเซิร์ฟเวอร์ทีละเครื่อง แล้ว grep ไฟล์ log ที่ใหญ่หลาย GB ใครเคยเจอคงรู้ว่ามันเหนื่อยแค่ไหน เครื่องมือรวม log ระดับองค์กรใหญ่ก็หนักเกินไปสำหรับทีมสามสี่คนที่มีเซิร์ฟเวอร์ไม่กี่เครื่อง ไอเดียนี้คือ log viewer เล็ก ๆ ที่รับ log จากหลายแอปมารวมไว้ที่เดียว ค้นหาได้เร็ว และเตือนเมื่อ error พุ่ง

ใครจะใช้

• นักพัฒนา — ค้น log ตาม request id, ผู้ใช้, ช่วงเวลา, ระดับความรุนแรง
• ทีม support — ดู error ของลูกค้ารายที่แจ้งปัญหาเข้ามา (เห็นเฉพาะฟิลด์ที่อนุญาต)
• หัวหน้าทีม — ตั้งกฎแจ้งเตือน ดูแนวโน้ม error

ฟีเจอร์ขั้นต่ำ (MVP)

• Ingest API รับ log แบบ JSON เป็น batch ผ่าน HTTP พร้อม API key ต่อแอป
• ตัวส่ง log ง่าย ๆ เช่น log target ของ Yii2/Laravel หรือสคริปต์ tail ไฟล์แล้วส่ง
• หน้าค้นหา: full-text, กรองตาม app, level, ช่วงเวลา และฟิลด์ใน context
• Live tail ดู log ที่เข้ามาแบบเรียลไทม์
• จัดกลุ่ม error ที่ข้อความเหมือนกัน แสดงจำนวนครั้งและครั้งล่าสุด
• กฎแจ้งเตือน เช่น error ของแอป X เกิน N ครั้งใน 5 นาที → แจ้ง LINE หรือแชตของทีม
• นโยบายเก็บ log (retention) ลบอัตโนมัติเมื่อเกินจำนวนวันที่กำหนด

ต่อยอดได้อีก

• บันทึก query ที่ใช้บ่อยเป็น saved search
• กราฟจำนวน log ตามเวลาแยก level
• เชื่อมกับ trace id เพื่อตามหนึ่ง request ข้ามหลาย service
• รับ log ผ่าน syslog สำหรับอุปกรณ์เครือข่าย

โครงข้อมูลตั้งต้น

CREATE TABLE log_entry (
  id BIGSERIAL,
  app_id INT NOT NULL,
  ts TIMESTAMPTZ NOT NULL,
  level VARCHAR(10) NOT NULL,
  message TEXT,
  context JSONB,
  fingerprint CHAR(40)
) PARTITION BY RANGE (ts);

CREATE INDEX ON log_entry USING GIN (context);

ตารางอื่น: app (ชื่อ, api_key_hash, retention_days), error_group (fingerprint, first_seen, last_seen, count), alert_rule, alert_event ถ้าข้อมูลเยอะมากค่อยพิจารณาฐานข้อมูลแบบ columnar ทีหลัง

ระดับความยาก และสิ่งที่จะได้เรียนรู้

ท้าทาย — โจทย์จริงคือปริมาณข้อมูล

• ออกแบบ ingest ที่รับข้อมูลเร็ว ใช้ queue และ bulk insert
• partition ตามวันและ drop partition เก่าแทนการ DELETE
• full-text search และ index บน JSONB
• ทำ live tail ด้วย WebSocket หรือ Server-Sent Events

ข้อควรระวัง

• log มักมีข้อมูลส่วนบุคคลหรือ secret หลุดมา (password, token, เลขบัตร) ควรมีตัวกรอง mask ตั้งแต่ฝั่งส่ง และระวังเรื่อง PDPA
• จำกัดสิทธิ์ว่าใครเห็น log แอปไหนได้ และเก็บ log ว่าใครค้นอะไร
• ถ้า log server ล่ม แอปหลักต้องไม่ล่มตาม ฝั่งส่งควรเป็น async และทิ้งข้อมูลได้เมื่อจำเป็น

ทีมของคุณตอนนี้ดู log กันแบบไหนครับ SSH แล้ว grep หรือมีเครื่องมือแล้ว? และคิดว่า PostgreSQL เพียงพอสำหรับงาน log ขนาดทีมเล็ก หรือควรเริ่มด้วยฐานข้อมูลแบบอื่นตั้งแต่แรก มาถกกันครับ ใครทำแล้วเอามาแชร์ในกระทู้ได้เลย