📡 Obs · Zero→Hero
หน้าแรก/🧭 0 · ปูพื้นฐาน/ปกติเก็บอะไรบ้าง
📖 บทเรียน⏱ ~13 นาที

ปกติเก็บอะไรบ้าง

คำถามยอดฮิตของมือใหม่: "แล้วจริงๆ เขาเก็บอะไรกันบ้าง?" คำตอบคือมองระบบเป็น 4 ชั้น จากล่างขึ้นบน แล้วเก็บ telemetry ให้ครบทุกชั้น ยิ่งชั้นบนยิ่งใกล้ "คุณค่าต่อธุรกิจ" มากขึ้น

┌─────────────────────────────────────────┐
│  4. Business    → รายได้, สมัคร, ตะกร้า   │  ← ผู้บริหารสนใจ
├─────────────────────────────────────────┤
│  3. Application → latency, error, RPS     │  ← สำคัญที่สุดต่อผู้ใช้
├─────────────────────────────────────────┤
│  2. Platform    → container, DB, queue    │  ← ชั้นที่ระบบเรารันอยู่
├─────────────────────────────────────────┤
│  1. Infrastructure → CPU, RAM, disk, net  │  ← ฐานล่างสุด
└─────────────────────────────────────────┘

ชั้น 1: Infrastructure — ฮาร์ดแวร์/เครื่อง

ชั้นล่างสุด คือทรัพยากรของเครื่อง (physical หรือ VM หรือ node ใน k8s) เก็บด้วยเครื่องมือพวก node_exporter (บทที่ 22)

เก็บอะไร ตัวอย่าง metric ดูเพื่ออะไร
CPU usage %, load average เครื่องทำงานหนักไป?
Memory used, available, swap RAM จะหมดไหม? memory leak?
Disk space used %, I/O wait ดิสก์จะเต็มไหม? อ่านเขียนช้า?
Network bytes in/out, errors, drops แบนด์วิดท์ตัน? packet หาย?

Disk เต็ม เป็นสาเหตุอันดับต้นๆ ที่ระบบล่มแบบงงๆ — โดยเฉพาะดิสก์ที่เก็บ log! ตั้ง alert "disk > 85%" ไว้เสมอ

ชั้น 2: Platform — middleware และของที่แอปพึ่งพา

ของที่แอปคุณวางอยู่บนหรือเรียกใช้ — database, cache, message queue, container runtime, k8s

  • Database (PostgreSQL, MySQL): จำนวน connection ที่ใช้/สูงสุด, query ที่ช้า, replication lag, cache hit ratio, lock/deadlock
  • Cache (Redis): hit rate, memory used, eviction, จำนวน connection
  • Message Queue (Kafka, RabbitMQ): consumer lag (คิวค้างแค่ไหน — สำคัญมาก), throughput, queue depth
  • Container (Docker/k8s): CPU/memory ต่อ container, restart count, OOMKilled, จำนวน pod ที่ ready — เก็บด้วย cAdvisor / kube-state-metrics

Consumer lag ของ queue ที่พุ่งขึ้นเรื่อยๆ = consumer ตามงานไม่ทัน เป็นสัญญาณเตือนล่วงหน้าก่อนระบบจะมีปัญหาใหญ่

ชั้น 3: Application — หัวใจของ observability

ชั้นนี้สำคัญที่สุด เพราะมันสะท้อนสิ่งที่ผู้ใช้เจอโดยตรง อิงกับ Four Golden Signals (บทที่ 10) และ RED method (บทที่ 11):

  • Rate / Traffic — request per second, แยกตาม endpoint/method
  • Errors — error rate (%), แยกตาม status code (4xx vs 5xx), exception count
  • Duration / Latency — เวลาตอบสนอง ดูเป็น percentile (p50/p95/p99) ไม่ใช่ค่าเฉลี่ย!
  • Saturation — ทรัพยากรภายในแอปที่ใกล้เต็ม เช่น thread pool, connection pool, event loop lag

นอกจากนี้ก็มี business logic เฉพาะแอป เช่น จำนวน job ที่ค้างใน worker, cache hit ในแอป, retry count

ทำไมต้อง percentile ไม่ใช่ average? ถ้า 99 request ตอบใน 10ms แต่ 1 request ค้าง 5 วินาที ค่าเฉลี่ยจะดูสวย (~60ms) แต่ p99 จะโป่งเป็น 5000ms ทันที ผู้ใช้ที่โดน request ช้าคือคนที่โกรธ — average ซ่อนคนกลุ่มนี้ เราจะเจาะเรื่องนี้ในบท histogram (13)

ชั้น 4: Business — ตัวเลขที่ผู้บริหารสนใจ

ชั้นบนสุด แปลง technical metric เป็น ภาษาธุรกิจ ซึ่งมักเป็นสิ่งที่ทำให้ทีมได้งบมาทำ monitoring 😄

  • จำนวนการสมัครสมาชิกใหม่ต่อชั่วโมง
  • มูลค่าคำสั่งซื้อ (GMV) ต่อนาที
  • จำนวนตะกร้าที่ถูกทิ้ง (cart abandonment)
  • อัตราการชำระเงินสำเร็จ (payment success rate)

พลังของชั้นนี้: มันจับปัญหาที่ metric เทคนิคจับไม่ได้ ตัวอย่างคลาสสิก:

ระบบทุกอย่าง "เขียว" — CPU ปกติ, error rate 0%, latency ดี — แต่ ยอดสั่งซื้อตกเป็นศูนย์ กะทันหัน ปรากฏว่าปุ่ม "ชำระเงิน" ถูก deploy พลาดจนกดไม่ได้ ระบบเลย "แข็งแรงดี" เพราะไม่มีใคร request เข้ามาเลย!

Business metric คือ safety net สุดท้ายที่จับปัญหาแบบนี้ได้

ตารางสรุป: เก็บอะไรในแต่ละชั้น

ชั้น เก็บอะไร (ตัวอย่าง) เก็บด้วย pillar หลัก
Infrastructure CPU, RAM, disk, network node_exporter Metrics
Platform DB connections, queue lag, container restarts cAdvisor, exporters เฉพาะทาง Metrics
Application RPS, error rate, latency p95, saturation instrument ในโค้ด (prom-client) Metrics + Logs + Traces
Business signups, GMV, payment success instrument ในโค้ด / event Metrics + Events

หลักการเลือก: อย่าเก็บทุกอย่าง เก็บสิ่งที่ "actionable"

ก่อนเพิ่ม metric/log ใหม่ ให้ผ่านคำถามนี้:

  1. ถ้าค่านี้ผิดปกติ ฉันจะทำอะไรต่อได้ไหม? (actionable?) — ถ้าเห็นแล้วทำอะไรไม่ได้ ก็ไม่ต้องตั้ง alert กับมัน (อาจเก็บไว้ดู trend ได้)
  2. มันช่วยลด MTTD หรือ MTTR ไหม? (จากบทที่ 00)
  3. cardinality มันบานไหม? (บทที่ 13) — อย่าใส่ user_id เป็น label ของ metric เด็ดขาด

"เก็บไว้ก่อน เผื่อได้ใช้" คือกับดัก มันทำให้ค่าใช้จ่ายพุ่ง, dashboard รก, และหา signal ใน noise ยากขึ้น เก็บเท่าที่ตอบคำถามได้จริง

สรุป

  • มองระบบเป็น 4 ชั้น: Infrastructure → Platform → Application → Business
  • Application layer สำคัญที่สุด เพราะสะท้อนสิ่งที่ผู้ใช้เจอ (RED/Golden Signals)
  • Business layer เป็น safety net จับปัญหาที่ technical metric มองไม่เห็น
  • ดู latency เป็น percentile เสมอ ไม่ใช่ค่าเฉลี่ย
  • เก็บสิ่งที่ actionable เท่านั้น อย่าเก็บทุกอย่าง

จบ Module 0 แล้ว! ต่อไปเข้า Module 1 — แนวคิดหลัก เริ่มจาก Four Golden Signals ที่เราพูดถึงบ่อยๆ