ความแตกต่างระหว่าง Monitoring และ Observability ในระบบแบบกระจาย

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

ข้อจำกัดคือการตรวจสอบทุกรายการตั้งอยู่บนการคาดการณ์ เมื่อความล้มเหลวเป็นสิ่งที่ไม่มีใครคาดไว้ เช่น บริการปลายทางที่ตอบสนองช้า การลองใหม่ซ้ำจำนวนมาก (Retry Storm) หรือแคชที่ทำงานอยู่ในทางเทคนิคแต่ส่งข้อมูลเก่ากลับมา แดชบอร์ดจะยังเป็นสีเขียวขณะที่ลูกค้าร้องเรียน Monitoring ยังจำเป็น แต่ไม่เพียงพออีกต่อไปเมื่อระบบใหญ่เกินกว่าที่คนคนเดียวจะเข้าใจได้ทั้งหมด

เมื่อย้ายงานทางธุรกิจเดียวกันไปไว้ในบริการนับสิบ โดยมี Message Queue อยู่ตรงกลาง จะมีสามสิ่งที่เปลี่ยนไป ประการแรก คำขอเดียวของผู้ใช้งานเกี่ยวข้องกับหลายโปรเซสบนหลายโฮสต์ ไฟล์ Log ไฟล์เดียวจึงเล่าเรื่องได้ไม่ครบ ประการที่สอง ความล้มเหลวเกิดขึ้นบางส่วน รีเจียนหนึ่ง Tenant หนึ่ง หรือเส้นทางโค้ดหนึ่งทำงานช้า ขณะที่ภาพรวมยังดูปกติ ประการที่สาม ระบบเปลี่ยนแปลงหลายครั้งต่อวัน ค่าฐานของเมื่อวานจึงใช้ไม่ได้อีกต่อไป

Observability คือคุณสมบัติที่ทำให้เข้าใจสถานะภายในของระบบได้จากข้อมูลที่ระบบส่งออกมา โดยไม่ต้องปล่อยโค้ดใหม่เพื่อถามคำถามใหม่ ในทางปฏิบัติหมายถึงการเก็บข้อมูล Telemetry ที่ละเอียดและมี Cardinality สูง (ลูกค้ารายใด Endpoint ใด เวอร์ชันใด รีเจียนใด) และแยกมุมมองได้ตามต้องการ คำถามจึงเปลี่ยนจากระบบทำงานอยู่หรือไม่ ไปเป็นผู้ใช้งานกลุ่มใดพบความล่าช้า ตั้งแต่เมื่อใด และมีอะไรเปลี่ยนไป

เป้าหมายระดับบริการ (SLO) คือเป้าหมายของตัวชี้วัดที่ผู้ใช้งานสัมผัสได้ เช่น 99.9 เปอร์เซ็นต์ของคำขอชำระเงินต้องสำเร็จภายใน 500 มิลลิวินาที วัดในช่วง 30 วัน องค์กรเป็นผู้กำหนดเปอร์เซ็นต์และช่วงเวลา สาระสำคัญคือ SLO อธิบายสิ่งที่ผู้ใช้งานประสบ ไม่ใช่สิ่งที่โฮสต์รายงาน

SLO กำหนด Error Budget ซึ่งคือปริมาณความล้มเหลวที่ยอมรับได้ในช่วงเวลานั้น และนำมาซึ่งรูปแบบการแจ้งเตือนที่ต่างออกไป แทนการเรียกผู้อยู่เวรเมื่อ CPU เกินเส้นที่กำหนด ทีมจะเรียกเมื่อ Budget ถูกใช้เร็วเกินกว่าจะพอถึงสิ้นช่วงเวลา (การแจ้งเตือนตาม Burn Rate) การใช้ที่ช้าจะกลายเป็น Ticket สำหรับวันทำการถัดไป ส่วนการใช้ที่เร็วจะเรียกวิศวกรที่อยู่เวร การเปลี่ยนแปลงเพียงข้อเดียวนี้ขจัดการแจ้งเตือนส่วนใหญ่ที่ไม่ต้องมีใครดำเนินการ

SLO ยังทำให้ฝ่ายวิศวกรรมและฝ่ายธุรกิจมีภาษาร่วมกัน หาก Budget ยังเหลือเพียงพอ ทีมก็ปล่อยงานได้เร็วขึ้น หาก Budget กำลังถูกใช้ไป ทีมก็ลงทุนกับความเสถียร กราฟ CPU ไม่สามารถรองรับการสนทนาเช่นนี้ได้

ความล้มเหลวที่พบบ่อยที่สุดของการมอนิเตอร์คือการแจ้งเตือนที่มากเกินไป ไม่ใช่น้อยเกินไป เมื่อผู้อยู่เวรได้รับการเรียกหลายสิบครั้งต่อสัปดาห์และส่วนใหญ่ไม่ต้องดำเนินการใด ผู้คนจะเลิกอ่าน และการแจ้งเตือนที่สำคัญจริงจะจมหายไป ทุกการแจ้งเตือนควรผ่านเกณฑ์ง่าย ๆ ข้อเดียว คือต้องมีคนลงมือทำอะไรได้ทันที หากไม่ใช่ การแจ้งเตือนนั้นควรอยู่บนแผงแดชบอร์ดหรือในรายงานประจำวัน ไม่ใช่การเรียกผู้อยู่เวร

จัดการชุดการแจ้งเตือนเหมือนโค้ดที่ผ่านการตรวจทาน การแจ้งเตือนแต่ละรายการมีเจ้าของ ลิงก์ไปยังคู่มือปฏิบัติงาน (Runbook) และเหตุผลที่ต้องมีอยู่ การแจ้งเตือนที่เกิดขึ้นโดยไม่มีการดำเนินการใดเป็นเวลาหนึ่งเดือนจะถูกลบหรือลดระดับ วัดผลการหมุนเวียนเวรเองด้วย ได้แก่ จำนวนการเรียกต่อสัปดาห์ จำนวนการเรียกนอกเวลาทำการ และเวลาที่ใช้ในการรับทราบ เวร On-Call ที่ปกติดีสะท้อนระบบที่ปกติดี และเวรที่มีปัญหาคือสัญญาณชัดเจนว่าควรลงทุนที่ใด

ระบบแบบกระจายเพิ่มข้อกำหนดอีกหนึ่งข้อ คือการแจ้งเตือนควรมาพร้อมบริบท การแจ้งเตือนที่เขียนว่า “error rate high on payments-api” คืองานที่ต้องไปค้นคว้าต่อ ส่วนการแจ้งเตือนที่ลิงก์ไปยัง SLO ที่ได้รับผลกระทบ การ Deploy ล่าสุด และ Endpoint ที่ล้มเหลวมากที่สุด คือสิ่งที่ตัดสินใจได้ทันที

ข้อมูล Observability มีต้นทุน และค่าใช้จ่ายมักมาถึงหลังจากที่ความเคยชินก่อตัวแล้ว ปัจจัยหลักมีสองข้อ คือปริมาณ (จำนวนไบต์ของ Log และ Span ต่อคำขอ คูณด้วยปริมาณการใช้งาน) และ Cardinality (จำนวนชุดค่าผสมของ Label ที่แตกต่างกันใน Metric หนึ่ง) Metric ที่ติด Label ด้วย User ID หรือ Request ID จะสร้าง Time Series ใหม่สำหรับทุกค่า และทำให้ที่เก็บ Metric ใดก็รับไม่ไหว

ค่าตั้งต้นที่เหมาะสมช่วยได้มาก ควรเก็บตัวระบุที่มีค่าหลากหลายสูง (High-cardinality) ไว้ใน Trace และ Log แบบมีโครงสร้าง แทนที่จะใส่ไว้ใน Label ของ Metric สุ่มเก็บ Trace โดยเก็บทุกข้อผิดพลาดและทุกคำขอที่ช้า และเก็บคำขอปกติเพียงบางส่วน กำหนดระยะเวลาจัดเก็บตามประเภทสัญญาณ ได้แก่ Metric เก็บหนึ่งปีที่ความละเอียดลดลง Log เก็บเป็นสัปดาห์ Trace เก็บเป็นวัน และมีชั้นจัดเก็บถาวร (Archive) สำหรับข้อมูลที่ต้องเก็บตามข้อกำหนด ทบทวนแหล่งที่สร้าง Log ปริมาณสูงสุดทุกเดือน เพราะคำสั่ง Debug ที่ละเอียดเกินไปเพียงบรรทัดเดียวในเส้นทางที่ถูกเรียกใช้บ่อย อาจเป็นต้นทุนสัดส่วนใหญ่ของค่าใช้จ่ายทั้งหมด

เป้าหมายคือการตอบคำถามถัดไปที่ยังไม่มีใครคาดคิดได้อย่างรวดเร็ว ด้วยต้นทุนที่องค์กรยินดีจ่ายได้อย่างต่อเนื่อง มิใช่การเก็บข้อมูลทุกอย่าง