Monitoring กับ Observability ต่างกันอย่างไร: คู่มือเชิงปฏิบัติสำหรับองค์กรในประเทศไทย

คำตอบสั้น ๆ

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

Monitoring ยังจำเป็นอยู่ Observability ต่อยอดจากสิ่งนั้นด้วยการเก็บข้อมูลจากระบบให้ละเอียดขึ้นและเชื่อมโยงเข้าด้วยกัน ทำให้การหาสาเหตุใช้เวลาเป็นนาที แทนการประชุมฉุกเฉินหลายชั่วโมง สำหรับองค์กรส่วนใหญ่ในประเทศไทย คำถามจึงไม่ใช่ว่าจะเลิกใช้ Monitoring หรือไม่ แต่คือจะพัฒนาจากเครื่องมือ Monitoring ที่แยกกันไปสู่มุมมองเดียวที่เชื่อมโยงกันได้อย่างไร โดยไม่ต้องเปลี่ยนทั้งระบบในครั้งเดียว

---

ทำไม Monitoring อย่างเดียวจึงไม่พอ

Monitoring แบบเดิมได้ผลดีเมื่อระบบมีไม่มากและคาดเดาได้ เรารู้ล่วงหน้าว่าอะไรอาจเสีย จึงตั้งการตรวจไว้ แต่ระบบสมัยใหม่ไม่เป็นเช่นนั้น การกระทำเพียงครั้งเดียวของลูกค้าในแอปมือถืออาจผ่าน API gateway ไมโครเซอร์วิสหลายตัว ฐานข้อมูลบนคลาวด์ ผู้ให้บริการชำระเงิน และ ERP ในองค์กร เมื่อระบบช้าลง แดชบอร์ดของทุกทีมอาจเป็นสีเขียวทั้งหมด ขณะที่ลูกค้ายังรออยู่

อาการที่พบบ่อย ได้แก่

• ลูกค้าแจ้งปัญหาก่อนที่ฝ่าย IT จะรู้
• สัญญาณเตือนของโครงสร้างพื้นฐาน log ของแอปพลิเคชัน และตัวเลขทางธุรกิจ อยู่ในเครื่องมือต่างกันและดูแลโดยทีมต่างกัน
• เหตุขัดข้องกลายเป็นการประชุมที่แต่ละทีมพิสูจน์ว่าส่วนของตนไม่มีปัญหา
• การแจ้งเตือนมากจนคนปิดเสียง หรือน้อยจนปัญหาจริงหลุดรอดไป
• ค่าลิขสิทธิ์เครื่องมือ Monitoring ที่คิดตามจำนวนเครื่องหรือ agent เพิ่มขึ้นเร็วกว่าการเติบโตของธุรกิจ

---

สัญญาณสี่ประเภทของ Observability

Observability มาจาก telemetry สี่ประเภทที่เก็บอย่างสม่ำเสมอและเชื่อมโยงกัน

• Metrics ตัวเลขตามเวลา เช่น จำนวนคำขอต่อวินาที อัตราข้อผิดพลาด เวลาตอบสนอง CPU ความยาวคิว จำนวนคำสั่งซื้อต่อนาที เก็บได้ในต้นทุนต่ำและเหมาะกับแดชบอร์ดและการแจ้งเตือน
• Logs บันทึกเหตุการณ์พร้อมเวลา ให้รายละเอียดว่าเกิดอะไรขึ้น แต่เป็นสัญญาณที่เก็บแพงที่สุดหากทำดัชนีทุกคำ
• Traces เส้นทางของคำขอหนึ่งรายการผ่านบริการต่าง ๆ พร้อมเวลาที่ใช้ในแต่ละขั้น Traces คือสิ่งที่เปลี่ยน "แอปช้า" ให้เป็น "การเรียกฐานข้อมูลสินค้าคงคลังใช้เวลา 1.9 วินาที"
• Profiles การวัดอย่างต่อเนื่องว่าฟังก์ชันใดใช้ CPU และหน่วยความจำในระบบจริง เชื่อมเหตุขัดข้องเข้ากับโค้ดที่อยู่เบื้องหลัง

คุณค่าอยู่ที่การเชื่อมโยง จากกราฟที่พุ่งขึ้นบนแดชบอร์ด ทีมควรเปิดดู traces ของนาทีนั้นได้ทันที และจาก trace ที่ช้า ควรไปยัง log ของบริการที่เป็นต้นเหตุได้เลย โดยไม่ต้องคัดลอกรหัสไปมาระหว่างเครื่องมือ

---

มาตรฐานเปิดช่วยให้องค์กรมีทางเลือก

โครงการโอเพนซอร์สสองโครงการของ Cloud Native Computing Foundation ได้กลายเป็นภาษากลางของ telemetry

• OpenTelemetry วิธีติดตั้งเครื่องมือวัด (instrument) ในแอปพลิเคชันและเก็บ metrics, logs และ traces ที่ไม่ผูกกับผู้ขายรายใด ติดตั้งครั้งเดียว แล้วส่งข้อมูลไปที่ใดก็ได้ตามต้องการ
• Prometheus รูปแบบข้อมูลและภาษาคิวรีแบบเปิดสำหรับ metrics ที่เครื่องมือสมัยใหม่ส่วนใหญ่อ่านและส่งข้อมูลได้

การสร้างบนมาตรฐานเหล่านี้ทำให้ telemetry ขององค์กรไม่ถูกผูกกับ agent ของผู้ขายรายเดียว หากเปลี่ยนแพลตฟอร์มในอนาคต สิ่งที่ติดตั้งไว้ในแอปพลิเคชันยังใช้ต่อได้

---

ต้นทุนและการเก็บข้อมูลในประเทศ: สองเรื่องที่ควรตัดสินใจตั้งแต่ต้น

ต้นทุน ค่าใช้จ่ายด้าน Observability มักเพิ่มตามสามปัจจัย คือ จำนวนเครื่องหรือคอนเทนเนอร์ จำนวนชุดข้อมูล metric ที่แตกต่างกัน และปริมาณ log ที่เก็บไว้ นิสัยสามอย่างช่วยคุมต้นทุนได้ ได้แก่ ตัด telemetry ที่ไม่มีใครใช้ ทำดัชนี log ตาม label แทนการทำดัชนีข้อความทั้งหมด และกำหนดระยะเวลาเก็บตามมูลค่าของข้อมูล (เช่น ข้อมูลละเอียดเก็บเป็นสัปดาห์ ข้อมูลสรุปเก็บหนึ่งปี) การใช้รากฐานโอเพนซอร์สยังช่วยเลี่ยงรูปแบบลิขสิทธิ์ที่คิดตามจำนวนเครื่องหรือ agent

การเก็บข้อมูลในประเทศ log และ trace มักมีข้อมูลส่วนบุคคล เช่น ชื่อ เบอร์โทรศัพท์ เลขบัญชี และ IP address จึงอยู่ภายใต้ PDPA ไม่ต่างจากฐานข้อมูลลูกค้า ควรตัดสินใจตั้งแต่ต้นว่า telemetry ใดออกนอกประเทศไทยได้ ปิดบังข้อมูลส่วนบุคคลตั้งแต่ตอนเก็บ และเลือกรูปแบบการติดตั้งให้เหมาะ ได้แก่ บริการคลาวด์แบบบริหารจัดการเพื่อความรวดเร็ว แพลตฟอร์มที่ติดตั้งเองเมื่อ telemetry ต้องอยู่ในสภาพแวดล้อมขององค์กร หรือแบบไฮบริดที่เก็บ log ที่อ่อนไหวไว้ในประเทศและส่ง metrics ขึ้นคลาวด์

---

แผน 90 วันสำหรับเริ่มต้น

1. สัปดาห์ที่ 1–2: สำรวจสิ่งที่มี ทำรายการสิ่งที่ Monitoring อยู่ในปัจจุบัน การแจ้งเตือนใดที่มีคนลงมือแก้จริง และเส้นทางลูกค้า (customer journey) ใดสำคัญที่สุดต่อธุรกิจ ยกเลิกการตรวจที่ไม่มีใครดูมาหนึ่งปี
2. สัปดาห์ที่ 3–4: เลือกสองเส้นทางสำคัญ เช่น การชำระเงินออนไลน์และการซิงก์ POS หน้าร้าน หรือการเปิดบัญชีและการโอนเงิน แล้วกำหนดเป็นตัวเลขว่า "ดี" หมายถึงอะไร ทั้งความพร้อมใช้งานและเวลาตอบสนอง
3. สัปดาห์ที่ 5–8: ติดตั้งและเชื่อมต่อ ติดตั้ง OpenTelemetry ในบริการที่อยู่เบื้องหลังสองเส้นทางนั้น รวม metrics, logs และ traces ไว้ในแพลตฟอร์มเดียว และสร้างแดชบอร์ดหนึ่งชุดต่อหนึ่งเส้นทางที่ทั้งฝ่ายธุรกิจและฝ่าย IT อ่านเข้าใจ
4. สัปดาห์ที่ 9–10: ปรับการแจ้งเตือน แจ้งเตือนตามผลกระทบต่อลูกค้า (อัตราข้อผิดพลาดและเวลาตอบสนองของเส้นทาง) แทนการแจ้งทุก metric ของเซิร์ฟเวอร์ และส่งการแจ้งเตือนไปยังเวรรับผิดชอบที่มีขั้นตอนยกระดับชัดเจน
5. สัปดาห์ที่ 11–12: ใช้ระบบเดิมและระบบใหม่คู่กัน คงเครื่องมือเดิมไว้จนกว่าทีมปฏิบัติการจะยืนยัน แล้วจึงย้ายเส้นทางชุดถัดไป

---

วัดความสำเร็จอย่างไร

• เวลาเฉลี่ยในการตรวจพบ (MTTD) รู้ถึงปัญหาได้เร็วเพียงใด ควรรู้ก่อนลูกค้าแจ้ง
• เวลาเฉลี่ยในการแก้ไข (MTTR) ตั้งแต่ได้รับการแจ้งเตือนจนบริการกลับมาปกติ
• คุณภาพการแจ้งเตือน สัดส่วนการแจ้งเตือนที่นำไปสู่การลงมือแก้ไข การแจ้งเตือนน้อยแต่แม่นดีกว่าการแจ้งเตือนจำนวนมาก
• เหตุขัดข้องที่ลูกค้าพบก่อน จำนวนปัญหาที่ลูกค้าแจ้งก่อนที่ IT จะเห็น ตัวเลขนี้ควรลดลง
• ต้นทุนเครื่องมือต่อบริการที่ดูแล ติดตามไปพร้อมกับการขยายความครอบคลุม

---

TMES ช่วยได้อย่างไร

TMES เป็นพันธมิตรด้านเทคโนโลยีของ Grafana ซึ่งรวม metrics, logs, traces และ profiles ไว้ในพื้นที่ทำงานเดียวบนมาตรฐานเปิด และ Grafana Labs ได้รับการจัดให้เป็นผู้นำ (Leader) ใน 2026 Gartner® Magic Quadrant™ for Observability Platforms TMES จัดหาลิขสิทธิ์ Grafana Cloud หรือ Grafana Enterprise ออกแบบและติดตั้งแพลตฟอร์ม ย้ายระบบจากเครื่องมือ Monitoring เดิมแบบเป็นขั้นตอน และดูแลระบบตลอด 24 ชั่วโมงภายใต้ระดับบริการที่ตกลงกัน ทั้งหมดในสัญญาเดียวกับผู้ให้บริการในประเทศ ภายใต้การกำกับดูแลที่ได้รับการรับรอง ISO/IEC 27001, 27701 และ 20000-1 ดูสถาปัตยกรรมและรูปแบบการติดตั้งแพลตฟอร์ม หรือพูดคุยกับทีม Observability ของเรา เกี่ยวกับสองเส้นทางแรกขององค์กรคุณ