Uptime Kuma: เฝ้าบริการด้วยการตรวจ HTTP, DNS และหน้า Status Page

Uptime Kuma เป็นเครื่องมือโอเพนซอร์สสำหรับตรวจว่าบริการยังตอบสนองหรือไม่ มี monitor แบบ HTTP(S), TCP, DNS และรูปแบบอื่น พร้อมระบบแจ้งเตือนและหน้า Status Page การติดตั้งทำได้เร็ว แต่ monitor ที่ตั้งผิดอาจแสดงสีเขียวทั้งที่ผู้ใช้เข้าเว็บไม่ได้ จึงควรออกแบบสิ่งที่จะวัดก่อนสร้าง dashboard

เลือกจุดตรวจให้ตอบคำถามจริง

สำหรับเว็บ ให้เริ่มด้วย HTTP(S) monitor ของหน้า health endpoint ที่สะท้อนความพร้อมของแอป ไม่ใช่แค่ reverse proxy ตอบ 200; ถ้าหน้าเว็บต้องพึ่งฐานข้อมูล ให้ health endpoint ตรวจ dependency เท่าที่เหมาะสมโดยไม่เปิดข้อมูลภายใน สำหรับ DNS ให้ตรวจชื่อโดเมนสำคัญ ส่วน TCP เหมาะกับตรวจว่าพอร์ตเปิด แต่ไม่ได้พิสูจน์ว่าแอปทำงานครบทุกฟังก์ชัน

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

เริ่มด้วย Docker

README ทางการมี ตัวอย่าง Docker Compose และ Docker command แบบสั้น สำหรับทดลองสามารถใช้ volume ถาวรแมปไป /app/data และพอร์ต 3001 จากนั้นเปิดหน้าเว็บ สร้างบัญชีผู้ดูแล และเพิ่ม monitor ตัวอย่าง 2–3 รายการ หากต้องการให้เข้าผ่าน reverse proxy ให้ตั้ง HTTPS และจำกัดสิทธิ์หน้า admin

หลังเริ่มคอนเทนเนอร์ ตรวจ docker compose ps กับ log แล้วทดสอบหยุดบริการทดลองชั่วคราว ดูว่า monitor เปลี่ยนสถานะตามเวลาที่คาด แจ้งเตือนถูกช่องทาง และกลับเป็นปกติเมื่อเริ่มบริการใหม่ ถ้าตั้ง Status Page ให้เลือกเฉพาะ monitor ที่สื่อสารกับผู้ใช้ได้และตรวจว่าหน้าสาธารณะไม่มีข้อมูลภายในหรือ URL ลับ

ช่องทางแจ้งเตือนและข้อมูล

Kuma รองรับการแจ้งเตือนหลายช่องทาง เช่น อีเมลและระบบแชต ตั้งค่าแล้วต้องกดทดสอบจริง และทดสอบเหตุล่มจำลองอีกครั้ง เพราะปุ่มทดสอบสำเร็จไม่ได้ยืนยันว่ากฎ monitor จะส่งแจ้งเตือนตามที่คาด แยกผู้รับเหตุวิกฤตออกจากเหตุที่รอได้ เพื่อลด alert fatigue

เก็บ /app/data บน volume หรือดิสก์ท้องถิ่นที่สำรองได้ README ระบุว่า NFS ไม่รองรับสำหรับข้อมูลนี้ สำรองก่อนอัปเดต image และทดลองเปิดประวัติ monitor หลัง restore ไม่ควรผูก Kuma เป็นแหล่งข้อมูลสถานะเพียงแหล่งเดียวของระบบที่มี SLA สูง เพราะหากเครื่อง Kuma เองล่มก็จะไม่มีใครแจ้งเหตุ

ระวัง Docker socket

การ monitor คอนเทนเนอร์ผ่าน Docker socket ดูสะดวก แต่ เอกสารโครงการเตือน ว่าการให้คอนเทนเนอร์เข้าถึง /var/run/docker.sock เท่ากับให้สิทธิ์ควบคุม Docker daemon หากถูกเจาะจะกระทบทั้งโฮสต์ เลือกตรวจ HTTP/TCP ของบริการก่อนถ้าพอ และอย่าเปิด Kuma ที่เข้าถึง socket สู่สาธารณะโดยไม่ควบคุม

อ่านเพิ่มเติม: README ทางการ · การติดตั้ง · ข้อควรระวัง Docker monitor