ทำไมต้อง Monitoring

ลองนึกภาพว่าคุณขับรถที่ ไม่มีหน้าปัดเลย — ไม่รู้ความเร็ว ไม่รู้น้ำมัน ไม่รู้ว่าเครื่องร้อนไหม คุณจะรู้ว่ารถพังก็ต่อเมื่อมันดับกลางถนนไปแล้ว

ระบบซอฟต์แวร์ที่ไม่มี monitoring ก็เหมือนกันเป๊ะ — คุณจะรู้ว่าระบบล่มก็ต่อเมื่อ ลูกค้าโทรมาด่า ซึ่งตอนนั้นมันสายไปแล้ว

เป้าหมายของ monitoring ไม่ใช่ "เก็บข้อมูลเยอะๆ" แต่คือ ลดเวลาที่ระบบมีปัญหาโดยที่เราไม่รู้ตัว และ ลดเวลาที่ใช้ในการแก้ เมื่อรู้แล้ว

ปัญหาจริงที่ monitoring แก้ให้

ทุกบริษัทที่รันระบบ online เจอคำถาม 4 ข้อนี้ตลอดเวลา:

1. ตอนนี้ระบบปกติดีไหม? — ผู้ใช้เข้าได้จริงหรือเปล่า ช้าไหม error เยอะไหม
2. ถ้าพัง มันพังตรงไหน? — DB? network? โค้ดที่เพิ่ง deploy? service ตัวไหน?
3. ทำไมมันพัง? — root cause คืออะไร
4. มันจะพังอีกเมื่อไหร่? — trend กำลังแย่ลงไหม ต้อง scale เพิ่มก่อนพังได้ไหม

Monitoring คือระบบที่ตอบ 4 คำถามนี้ได้ ก่อน ที่ลูกค้าจะเป็นคนบอกคุณ

ตัวเลขที่ทำให้เรื่องนี้สำคัญ: MTTD และ MTTR

สอง metric ที่วัด "คุณภาพของการดูแลระบบ" โดยตรง:

ตัวย่อ	ชื่อเต็ม	แปลว่า
MTTD	Mean Time To Detect	เฉลี่ยแล้วกว่าจะ รู้ว่า มีปัญหาใช้เวลาเท่าไหร่
MTTR	Mean Time To Recover/Resolve	เฉลี่ยแล้วกว่าจะ แก้เสร็จ ใช้เวลาเท่าไหร่

Downtime = MTTD + MTTR (คร่าวๆ) — และ monitoring คือเครื่องมือหลักที่ทำให้ทั้งสองค่าเล็กลง

• Metrics + Alert ที่ดี → ลด MTTD (รู้เร็ว)
• Logs + Traces ที่ดี → ลด MTTR (หาสาเหตุเจอเร็ว)

เวลาออกแบบระบบ monitoring ให้ถามตัวเองเสมอว่า "สิ่งที่ฉันกำลังเก็บนี้ ช่วยลด MTTD หรือ MTTR ข้อไหน?" ถ้าตอบไม่ได้ทั้งสองข้อ อาจไม่จำเป็นต้องเก็บ

Monitoring vs Observability — ต่างกันยังไง

สองคำนี้คนใช้ปนกันบ่อย แต่ concept ต่างกันจริง:

• Monitoring = การเฝ้าดูสิ่งที่เรา รู้ล่วงหน้าว่าต้องดู เราตั้งคำถามไว้ก่อน แล้วสร้าง dashboard/alert มาตอบคำถามนั้น

  "CPU เกิน 80% ไหม", "error rate เกิน 1% ไหม" — เรารู้ว่าจะถามอะไร

• Observability = ความสามารถของระบบที่ทำให้เรา ถามคำถามใหม่ที่ไม่เคยเตรียมไว้ ได้ โดยไม่ต้อง deploy โค้ดใหม่

  "ทำไม request ของลูกค้า VIP คนนี้ ที่มาจาก region เอเชีย ผ่าน API v2 ถึงช้าเฉพาะช่วงบ่าย?" — คำถามที่เราไม่มีทางเดา dashboard ไว้ล่วงหน้า

พูดง่ายๆ:

Monitoring ตอบคำถามที่คุณ รู้อยู่แล้วว่าจะถาม (known-unknowns) Observability ช่วยคุณตอบคำถามที่ ยังไม่รู้ด้วยซ้ำว่าจะต้องถาม (unknown-unknowns)

ในโลก monolith เดิม monitoring แบบเดิมก็พอ แต่พอเป็น microservices + cloud ที่มี service เป็นสิบเป็นร้อยตัวคุยกัน ปัญหามันซับซ้อนเกินกว่าจะเดา dashboard ล่วงหน้าได้หมด — จึงต้องการ observability

Mindset แบบ SRE: ยอมรับว่าระบบต้องพัง

Google เป็นคนบุกเบิกแนวคิด SRE (Site Reliability Engineering) ซึ่งมี mindset สำคัญที่เปลี่ยนวิธีคิดเรื่อง monitoring:

• ระบบ 100% uptime เป็นเรื่องเพ้อฝัน — และไม่คุ้มด้วย การไล่จาก 99.9% ไป 99.99% แพงขึ้นเป็นสิบเท่า
• เพราะฉะนั้นเราต้อง ยอมรับความล้มเหลวในระดับที่วัดได้ แล้วบริหารมัน (นี่คือที่มาของ SLO/Error Budget ที่จะเรียนในบทหลัง)
• Monitoring คือประสาทสัมผัสของ SRE — ถ้าวัดไม่ได้ ก็ปรับปรุงไม่ได้

ระวังกับดักฝั่งตรงข้าม: เก็บเยอะเกินไป

มือใหม่มักเข้าใจผิดว่า "ยิ่งเก็บเยอะยิ่งดี" แต่ในความเป็นจริง:

การเก็บ metric/log ทุกอย่างโดยไม่คิด นำไปสู่ ค่าใช้จ่ายมหาศาล (storage + ingest), cardinality ระเบิด (บทที่ 13), และที่แย่สุดคือ alert fatigue — คนถูกปลุกบ่อยจน "ชิน" แล้วไม่สนใจ alert ที่สำคัญจริง

Monitoring ที่ดีคือ การเลือกเก็บสิ่งที่มีความหมาย ไม่ใช่การเก็บทุกอย่าง เราจะเรียนกันในบทถัดๆ ไปว่า "สิ่งที่มีความหมาย" หน้าตาเป็นยังไง

สรุป

• Monitoring มีไว้เพื่อ ลด MTTD (รู้เร็ว) และ MTTR (แก้เร็ว) ไม่ใช่เพื่อเก็บข้อมูลเฉยๆ
• Monitoring ตอบคำถามที่เตรียมไว้ · Observability ตอบคำถามที่ไม่เคยเตรียม
• ในโลก microservices เราต้องการ observability ไม่ใช่แค่ dashboard นิ่งๆ
• เป้าหมายคือ เก็บของที่มีความหมาย ไม่ใช่เก็บทุกอย่าง

บทต่อไปเราจะรู้จัก 3 เสาหลัก ที่เป็นวัตถุดิบของ observability ทั้งหมด → Metrics, Logs, Traces