Observability — มองเห็นสิ่งที่เกิดในคลัสเตอร์
logs, events, metrics และเครื่องมือที่ใช้จริง
พื้นฐานที่ควรรู้: เมื่อมีปัญหาเกิดขึ้นในระบบ เราต้องการข้อมูลเพื่อหาสาเหตุ "ความสามารถในการสังเกตเห็น" (Observability) เป็นหลักการสำคัญที่บอกว่าเราควรเก็บข้อมูล Logs (บันทึกเหตุการณ์), Metrics (ตัวเลขสถิติ) และ Traces (เส้นทางการทำงาน) ให้พร้อมเสมอ
รันระบบโดยไม่มี observability เหมือนขับรถหลับตา · logs = เสียงเครื่องยนต์, metrics = หน้าปัดวัดความเร็ว/น้ำมัน, events = ไฟเตือนบนแผงหน้าปัด
สามเสาหลักที่ต้องดูเป็น
- Logs —
kubectl logs <pod>(เติม-fตามสด,--previousดู log ก่อน crash) - Events —
kubectl get eventsหรือท้ายkubectl describeบอกว่า K8s ทำอะไร/ทำไมล้มเหลว (Pending, OOMKilled, ImagePullBackOff) - Metrics —
kubectl top pods/nodes(ต้องมี metrics-server) ดู CPU/RAM ใช้จริง
สรุป Key Takeaways
- สามเสา: logs (kubectl logs), events (describe/get events), metrics (kubectl top)
- อ่าน Pod STATUS ให้ออก: ImagePullBackOff / CrashLoopBackOff / OOMKilled / Pending
- งานจริงใช้ Prometheus+Grafana, Loki/ELK, OpenTelemetry รวมศูนย์
คำถามที่พบบ่อย
เริ่มต้น observability ใน K8s ควรมีอะไรบ้าง
สามขา: Metrics (Prometheus + Grafana — มาตรฐานโดยพฤตินัย), Logs (รวมศูนย์ด้วย Loki/Fluent Bit — เพราะ log ใน pod หายตาม pod), Traces (เมื่อมี microservices หลายตัว — OpenTelemetry) — เริ่มจาก metrics+logs ก่อน traces ค่อยตามเมื่อระบบซับซ้อนขึ้น
kubectl logs ไม่พอตรงไหน ทำไมต้องมีระบบ log กลาง
สามเหตุผล: pod ถูกลบ/ย้ายเครื่อง log หายทันที, ค้นข้าม pod หลายตัวพร้อมกันไม่ได้, และเก็บย้อนหลังไม่ได้ — ระบบ log กลางเก็บทุกอย่างไว้ค้น/ทำ alert ได้แม้ pod ต้นทางตายไปแล้ว ซึ่งจำเป็นตอนสืบ incident เสมอ