RED & USE Methods
Golden Signals ดีมาก แต่เวลาลงมือจริงคนมักสับสนว่า "แล้วกับ database ล่ะ? กับ CPU ล่ะ?" จึงมีสองสูตรลัดที่ เจาะจงกว่า ให้เลือกใช้ตามชนิดของสิ่งที่จะวัด:
- RED → สำหรับ service / สิ่งที่รับ request (request-driven)
- USE → สำหรับ resource / ทรัพยากร (เครื่อง, disk, pool)
RED และ USE ไม่ได้ขัดกับ Golden Signals — มันคือ Golden Signals ที่ถูกจัดกลุ่มใหม่ให้ใช้ง่ายขึ้นตามบริบท
RED Method — สำหรับ service
คิดโดย Tom Wilkie (Grafana) ย่อมาจาก 3 อย่างที่ต้องวัดสำหรับทุก service ที่รับ request:
| ตัวอักษร | ชื่อ | คืออะไร |
|---|---|---|
| R | Rate | จำนวน request ต่อวินาที |
| E | Errors | จำนวน (หรือ %) request ที่ fail |
| D | Duration | เวลาที่ใช้ต่อ request (ดู distribution/percentile) |
สังเกตว่ามันคือ 3 ใน 4 ของ Golden Signals (ขาด Saturation) — เพราะ RED โฟกัสที่ "มุมมองจากภายนอกที่ผู้ใช้เห็น" ส่วน saturation เป็นเรื่องภายใน
ทำไม RED เจ๋ง: มันเป็น pattern เดียวกันทุก service — ไม่ว่าจะ auth, payment, search คุณทำ dashboard หน้าตาเหมือนกันเป๊ะ (Rate, Errors, Duration) ทำให้ทีมอ่าน dashboard ของ service ที่ไม่เคยเห็นได้ทันที
# R — Rate: request ต่อวินาที
sum(rate(http_requests_total[5m]))
# E — Errors: อัตรา error
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# D — Duration: p95 latency
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
ตั้ง "RED dashboard template" ไว้อันเดียว แล้ว copy ใช้กับทุก service โดยเปลี่ยนแค่ชื่อ service — นี่คือวิธีที่ทีมใหญ่ๆ scale การ monitor ให้ครอบคลุมร้อย service ได้
USE Method — สำหรับ resource
คิดโดย Brendan Gregg (ปรมาจารย์ performance) ใช้กับ ทรัพยากร ทุกชนิด: CPU, memory, disk, network, connection pool, thread pool
| ตัวอักษร | ชื่อ | คืออะไร | ตัวอย่างกับ CPU |
|---|---|---|---|
| U | Utilization | ใช้งานไปกี่ % ของเวลา/ความจุ | CPU busy 85% |
| S | Saturation | มีงานรอคิว (เกินกว่าที่รับไหว) แค่ไหน | run queue length, load average |
| E | Errors | จำนวน error ของ resource นั้น | CPU throttling, ECC errors |
ความต่างที่คนพลาดบ่อย: Utilization ≠ Saturation
- Utilization = ยุ่งแค่ไหน (0–100%)
- Saturation = มีงานเกินที่ทำไหว จนต้องเข้าคิว (เกิน 100% ได้)
CPU utilization 100% ไม่ได้ แปลว่าแย่เสมอ — อาจแค่ใช้เต็มประสิทธิภาพ แต่ถ้า saturation สูง (มี process รอคิวยาว, load average > จำนวน core) นั่นแหละคือปัญหาจริง เพราะงานเริ่มถูกดีเลย์
ตัวอย่าง USE checklist สำหรับเครื่อง 1 เครื่อง
| Resource | Utilization | Saturation | Errors |
|---|---|---|---|
| CPU | busy % | load average, run queue | throttle count |
| Memory | used % | swap used, page faults | OOM kills |
| Disk | busy % (iostat) | I/O queue depth, await | I/O errors |
| Network | bandwidth % | dropped packets, retransmit | interface errors |
node_exporter (บทที่ 22) ให้ metric ครบสำหรับทำ USE checklist นี้
เลือกยังไงว่าจะใช้ RED หรือ USE
สิ่งที่จะวัด "รับ request เข้ามา" ไหม?
├─ ใช่ (API, service, endpoint) ──→ ใช้ RED
└─ ไม่ (เป็นทรัพยากร: CPU, disk, pool) ──→ ใช้ USE
ในระบบจริงคุณใช้ ทั้งคู่:
- ชั้น Application → RED (แต่ละ service)
- ชั้น Infrastructure/Platform → USE (แต่ละ resource)
พอมี alert เด้ง: RED บอกว่า ผู้ใช้เจอปัญหาอะไร, USE บอกว่า ทรัพยากรตัวไหนเป็นต้นเหตุ
สรุป
- RED (Rate, Errors, Duration) → ทุก service ที่รับ request ทำ dashboard เหมือนกันได้หมด
- USE (Utilization, Saturation, Errors) → ทุก resource
- Utilization ≠ Saturation — saturation (งานรอคิว) คือตัวชี้ปัญหาจริง
- ใช้ RED ที่ชั้น app, USE ที่ชั้น infra — เสริมกัน
บทหน้า เราจะแปลง "ความน่าเชื่อถือ" เป็นตัวเลขที่เอาไปสัญญากับลูกค้าได้ — SLI / SLO / SLA