Four Golden Signals

ถ้าให้เลือก metric ได้แค่ 4 ตัวสำหรับเฝ้าทุก service ในโลก Google บอกว่าให้เลือก 4 ตัวนี้ — เรียกว่า Four Golden Signals มาจากหนังสือ Google SRE Book

ถ้าคุณจำอะไรจากบทนี้ได้แค่อย่างเดียว ให้จำ 4 คำนี้: Latency, Traffic, Errors, Saturation — มันคือ checklist ที่ใช้ได้กับทุก service ไม่ว่าจะเป็น API, database, หรือ queue

1. Latency — ช้าแค่ไหน

เวลาที่ใช้ตอบสนอง 1 request แต่มีกับดักสำคัญ 2 ข้อ:

กับดัก 1: ต้องแยก latency ของ request ที่สำเร็จ กับที่ fail

• request ที่ error มักตอบ เร็ว (เช่น 500 ทันที) ถ้าเอามารวม ค่า latency จะดูดีหลอกๆ
• หรือบางที error ตอบ ช้า (timeout 30s) ทำให้ค่าพุ่งโดยไม่ใช่ปัญหา performance จริง
• ➜ วัด latency ของ success (2xx) แยกจาก error (5xx)

กับดัก 2: ห้ามใช้ค่าเฉลี่ย ให้ใช้ percentile

• ดู p50, p95, p99 — "95% ของ request เร็วกว่าค่านี้"
• p99 คือประสบการณ์ของลูกค้าที่ โชคร้ายที่สุด ซึ่งมักเป็นคนที่บ่น

100 requests: 99 ตัว = 10ms, 1 ตัว = 3000ms
average = 40ms       ← ดูดี แต่โกหก
p99     = 3000ms     ← ความจริงที่ลูกค้าคนนั้นเจอ

2. Traffic — มีงานเข้ามาแค่ไหน

ปริมาณ demand ที่ระบบรับ วัดเป็นอัตรา เช่น:

• Web/API: requests per second (RPS)
• Streaming: bytes/sec, concurrent connections
• Database: transactions/sec, queries/sec
• Queue: messages/sec

Traffic เป็น บริบท (context) ที่ทำให้ signal อื่นมีความหมาย — error 100 ครั้ง/วิ ตอน traffic 10,000 RPS (0.1%) ต่างจากตอน traffic 200 RPS (50%) มหาศาล

Traffic ยังใช้จับ anomaly ได้: ถ้าจู่ๆ RPS ตกเป็นศูนย์ = อาจมีอะไรขวางไม่ให้ request เข้ามาถึง (เหมือนเคส "ปุ่มชำระเงินพัง" ในบทที่ 02)

3. Errors — พังบ่อยแค่ไหน

อัตราของ request ที่ล้มเหลว ปกติดูเป็น % ของ traffic ทั้งหมด แต่ "fail" มีหลายระดับ:

• Explicit errors — ชัดเจน เช่น HTTP 5xx, exception, RPC error
• Implicit errors — ตอบ 200 แต่เนื้อหาผิด เช่น ส่ง JSON พัง, ราคาผิด (จับยากกว่า ต้อง validate)
• Policy errors — ตอบถูกต้องแต่ช้าเกิน SLA เช่น "ต้องตอบใน 1s แต่ใช้ 5s" ก็นับเป็น fail ตาม policy

แยก 4xx (ความผิดฝั่ง client) ออกจาก 5xx (ความผิดฝั่งเรา) เสมอ — 4xx พุ่งอาจแปลว่ามีคนยิง API ผิด, 5xx พุ่งแปลว่าระบบเรามีปัญหา

4. Saturation — ใกล้เต็มแค่ไหน

ระบบใช้ทรัพยากรไปกี่ % ของที่มี — เป็น signal ที่ "มองไปข้างหน้า" บอกว่าอีกนานแค่ไหนจะพัง:

• CPU ใช้ไป 90% → ใกล้ตัน
• Memory เหลือ 5% → เสี่ยง OOM
• Connection pool ใช้ 95/100 → อีกนิดเดียวจะ reject
• Disk 88% → คำนวณได้ว่าอีกกี่วันจะเต็ม

Saturation คือ signal ที่คนลืมบ่อยที่สุด แต่มันคือตัวที่ให้ early warning — Latency/Errors จะแย่ก็ต่อเมื่อ saturation สูงมากแล้ว ถ้าตั้ง alert ที่ saturation คุณจะรู้ตัว ก่อน ลูกค้าเจอปัญหา

Saturation ที่ดีมักผูกกับ latency: เมื่อระบบเข้าใกล้เต็ม latency มักพุ่งแบบ non-linear (queueing theory)

เอา 4 signals ไปใช้จริง

สำหรับ ทุก service ให้ทำ dashboard 4 กราฟนี้:

Signal	ตัวอย่าง metric	Alert เมื่อ
Latency	http_request_duration p95, p99	p99 > 500ms ต่อเนื่อง 5 นาที
Traffic	http_requests_total rate	ตกผิดปกติ / พุ่งผิดปกติ
Errors	rate(http_requests{status=~"5.."})	error rate > 1%
Saturation	CPU%, pool usage, queue depth	> 80%

ความสัมพันธ์ระหว่าง signals (สำคัญ)

4 signals ไม่ได้อยู่แยกกัน มันเล่าเรื่องร่วมกัน:

Traffic พุ่ง  →  Saturation สูงขึ้น  →  Latency เริ่มช้า  →  Errors เริ่มโผล่ (timeout)

พอเห็น pattern นี้บน dashboard คุณจะ debug ได้ทันทีว่า "ระบบรับโหลดไม่ไหว" ไม่ใช่ "โค้ดมี bug"

สรุป

• 4 Golden Signals = Latency, Traffic, Errors, Saturation ใช้เฝ้าได้ทุก service
• Latency: ดู percentile (p95/p99) แยก success/fail — อย่าใช้ average
• Traffic: บริบทที่ทำให้ signal อื่นมีความหมาย
• Errors: แยก 4xx (client) กับ 5xx (เรา), ระวัง implicit error
• Saturation: signal เตือนล่วงหน้าที่คนลืมบ่อยสุด

บทหน้า เราจะดูอีกสองสูตรที่นิยมพอกัน — RED (สำหรับ service) และ USE (สำหรับ resource)