3 เสาหลักของ Observability

Telemetry (ข้อมูลที่ระบบพ่นออกมาให้เราดู) แบ่งได้เป็น 3 ชนิดหลัก ที่เรียกกันว่า 3 Pillars of Observability:

1. Metrics — ตัวเลขตามเวลา
2. Logs — เหตุการณ์ที่บันทึกเป็นข้อความ
3. Traces — เส้นทางของ request หนึ่งๆ ที่วิ่งข้าม service

แต่ละอย่างเก่งคนละเรื่อง และตอบคำถามคนละแบบ เข้าใจว่าอันไหนใช้ตอนไหน = เข้าใจ observability ไปแล้วครึ่งหนึ่ง

repo ของคุณตอนนี้มีแค่ Logs (ELK) ครบแล้ว หลักสูตรนี้จะเติม Metrics และ Traces ให้ครบทั้งสามเสา

เสาที่ 1: Metrics — "เกิดอะไรขึ้น และมากแค่ไหน"

Metric คือตัวเลขที่วัด ณ เวลาหนึ่ง เก็บเป็นชุดข้อมูลตามเวลา (time series) เช่น:

• จำนวน request ต่อวินาที = 1,240
• CPU usage = 73%
• latency p95 = 250ms

จุดเด่นคือมันเล็กมากและ query เร็วมาก เพราะเป็นแค่ตัวเลข + timestamp + label ไม่กี่ตัว

http_requests_total{method="POST", status="500"}  1247   @ 10:30:00
http_requests_total{method="POST", status="500"}  1251   @ 10:30:15

เก่งเรื่อง: ดูภาพรวม, ทำ dashboard, ตั้ง alert, ดู trend ระยะยาว (เก็บได้เป็นปีเพราะเล็ก) ไม่เก่งเรื่อง: บอก "ทำไม" ไม่ได้ — รู้ว่า error พุ่ง แต่ไม่รู้ว่า request ไหนพังเพราะอะไร

Metrics ตอบว่า "มีบางอย่างผิดปกติ" — มันคือสัญญาณเตือน ไม่ใช่คำอธิบาย

เสาที่ 2: Logs — "รายละเอียดของแต่ละเหตุการณ์"

Log คือบันทึกเหตุการณ์แบบมี timestamp ปกติเป็นข้อความ (ควรเป็น JSON แบบมีโครงสร้าง — บทที่ 30) เช่น:

{
  "timestamp": "2026-08-20T10:30:04Z",
  "level": "error",
  "service": "payment-api",
  "trace_id": "a1b2c3",
  "message": "charge failed: card declined",
  "user_id": "u_889",
  "amount": 1500
}

เก่งเรื่อง: ให้ context ลึก ของแต่ละเหตุการณ์ — ตอบ "ทำไม" ได้ดีที่สุด เมื่อ metric บอกว่ามี error เยอะ เราไปอ่าน log เพื่อดูว่า error จริงๆ พูดว่าอะไร ไม่เก่งเรื่อง: ปริมาณเยอะมากและแพงในการเก็บ, query ช้ากว่า metric, ถ้าไม่มีโครงสร้างที่ดีจะหาอะไรไม่เจอ

นี่คือเสาที่ ELK stack ใน repo คุณจัดการอยู่ — Elasticsearch เก็บและค้น, Kibana ดู, Filebeat/Logstash รวบรวม

เสาที่ 3: Traces — "request นี้เดินทางผ่านอะไรบ้าง"

ในโลก microservices, 1 request จากผู้ใช้อาจวิ่งผ่าน 10 service gateway → auth → order → payment → inventory → ... ถ้าช้า คุณจะรู้ได้ยังไงว่าช้าที่ตัวไหน?

Trace คือการตามรอย request หนึ่งๆ ตลอดเส้นทาง โดยแตกเป็น span ย่อยๆ แต่ละ span คือหนึ่งงาน (เช่น "query DB", "call payment API") พร้อมเวลาเริ่ม-จบ

Trace: สั่งซื้อสินค้า (รวม 820ms)
├─ gateway            [ 5ms ]
├─ auth-service       [ 12ms ]
├─ order-service      [ 40ms ]
│   └─ postgres query [ 30ms ]
└─ payment-service    [ 760ms ] ⚠️ ตัวนี้แหละที่ช้า!
    └─ external bank API [ 740ms ]

พอเห็นแบบนี้ทันทีว่าปัญหาอยู่ที่ external bank API ไม่ใช่โค้ดเรา

เก่งเรื่อง: หา bottleneck ในระบบกระจาย, เข้าใจ dependency ระหว่าง service, debug latency ไม่เก่งเรื่อง: เก็บทุก request แพงมาก (เลยต้อง sampling), setup ยากสุดในสามเสา

เทียบให้เห็นภาพ

	Metrics	Logs	Traces
ตอบคำถาม	เกิดอะไร มากแค่ไหน	ทำไม (รายละเอียด)	ช้า/พังที่ service ไหน
รูปแบบ	ตัวเลข + เวลา	ข้อความ/JSON + เวลา	span เชื่อมกันเป็น tree
ขนาด/ต้นทุน	เล็กสุด ถูกสุด	ใหญ่ แพง	ใหญ่ (ใช้ sampling)
ความเร็ว query	เร็วมาก	ปานกลาง	ปานกลาง
เก็บได้นาน	เป็นปี	สัปดาห์–เดือน	วัน–สัปดาห์
เครื่องมือยอดนิยม	Prometheus, Grafana	ELK, Loki	Jaeger, Tempo

ทั้งสามทำงานร่วมกัน — flow การ debug จริง

พลังจริงของ observability เกิดตอนใช้ ทั้งสามเสาร่วมกัน ลองดู flow ตอนเกิดปัญหาจริง:

1. 📈 Metric ยิง alert: "error rate ของ checkout พุ่งเป็น 8%" → รู้ว่ามีปัญหา (ลด MTTD)
2. 📈 เปิด dashboard ดู: error เริ่มพุ่งตอน 10:30 ตรงกับที่เพิ่ง deploy พอดี → เดาทิศทาง
3. 🔬 เปิด trace ของ request ที่ fail: เห็นว่า span payment → bank-api timeout → รู้ว่าเป็นที่ service ไหน
4. 🪵 เปิด log ของ payment ช่วงนั้น: เห็นข้อความ connection pool exhausted → รู้ว่าทำไม (ลด MTTR)
5. ✅ แก้: เพิ่มขนาด connection pool → error กลับเป็นปกติใน dashboard

จำ flow นี้ไว้: Metrics บอกว่ามีปัญหา → Traces บอกว่าอยู่ตรงไหน → Logs บอกว่าทำไม นี่คือหัวใจของการใช้ 3 pillars ให้เป็น

แล้ว "เสาที่ 4" ล่ะ?

หลังๆ วงการเริ่มพูดถึง telemetry ชนิดอื่นเพิ่ม แต่ยังถือเป็นส่วนเสริม:

• Events — เหตุการณ์สำคัญแบบเจาะจง (deploy, config change, scaling) ที่เอามาทับบนกราฟเพื่อดู correlation
• Profiles (Continuous Profiling) — วัดว่าโค้ดใช้ CPU/memory ตรงฟังก์ชันไหน ระดับ line-by-line
• RUM (Real User Monitoring) — วัดประสบการณ์จริงจากฝั่ง browser ของผู้ใช้

รู้ไว้พอ ตอนนี้โฟกัส 3 เสาหลักก่อน

สรุป

• Metrics = ตัวเลขตามเวลา ราคาถูก ใช้ตรวจจับและตั้ง alert (รู้ว่า มี ปัญหา)
• Logs = รายละเอียดเหตุการณ์ ใช้หาสาเหตุ (รู้ว่า ทำไม)
• Traces = เส้นทาง request ข้าม service ใช้หา bottleneck (รู้ว่า ตรงไหน)
• ใช้ร่วมกันตาม flow: Metric → Trace → Log

บทหน้า เราจะเจาะว่าในแต่ละชั้นของระบบ (เครื่อง, แพลตฟอร์ม, แอป, ธุรกิจ) เรา เก็บอะไรบ้างจริงๆ