บทที่ 0 — Observability Mindset

สารบัญ | บทถัดไป →

🗺️ บทนี้ยาว — กระโดดได้: §1 monitoring vs observability · §3 3 pillars · §6 OTel · §10 SRE concepts · §13 golden signals · §17 glossary · §18 tool landscape

เลือกเส้นทางอ่านตามระดับและบริบท

📖 ศัพท์ในตารางด้านล่าง (มือใหม่ดูได้): on-call = เจ้าหน้าที่เวรรับ alert (รวมถึงกลางดึก) · Prometheus = tool เก็บ metric ยอดนิยม · microservices = service เล็ก ๆ หลายตัว · SLO = เป้าหมายความน่าเชื่อถือของ service · Loki / ES (Elasticsearch) = tool เก็บ log

คุณคือใคร	เส้นทางแนะนำ
Basic dev — เพิ่ง deploy app ครั้งแรก ยังไม่เคย on-call (เวรรับ alert)	0 → 1 (logging basics) → 4 (dashboard) → 7 (incident) — 4 บทนี้พอเริ่ม
Backend dev ใช้ Prometheus อยู่บ้าง	0 → 1 → 2 → 4 → 5
เริ่มทำ microservices	0 → 1 → 2 → 3 (tracing) → 4 → 5
SRE/Platform — ต้องตั้ง SLO + alert ครบ	0 → 1 → 2 → 5 → 6 (SLO) → 7
Log volume สูง — ตัดสินใจ Loki vs ES	0 → 1 → 8 (Loki) + 9 (ES) เทียบ

💡 บทที่ basic-friendly ที่สุด = บท 4 (Dashboard) + บท 7 (Incident) · ส่วนบท 2 (Prometheus) + บท 3 (Tracing) + บท 6 (SLO) มี section ที่ "🟡 ขั้นสูง — ข้ามได้" — basic อ่านส่วน concept ผ่าน skip ส่วน implementation ที่ลึกได้

1. Monitoring vs Observability

หลายคนใช้สับสน — แต่จริง ๆ ไม่เหมือนกัน:

Monitoring:
- "ระบบทำงานอยู่ไหม?"
- ดู metric ที่กำหนดไว้ล่วงหน้า
- ตอบ "known unknowns" (รู้ว่าจะถาม — ปัญหาที่ "เรารู้ล่วงหน้าว่าจะต้องถาม" เช่น CPU เกินไหม)
- เหมาะกับ system simple

Observability:
- "ทำไมระบบเป็นแบบนี้?"
- มี data รวยพอที่จะถามคำถามใหม่
- ตอบ "unknown unknowns" (ไม่รู้ว่าจะถาม — ปัญหาที่ "เราไม่เคยรู้มาก่อนว่าจะเกิด" — คิดคำถามไว้ล่วงหน้าไม่ได้)
- จำเป็นใน distributed system (ระบบกระจายตัว)

ตัวอย่าง:

Monitoring: 
   "CPU 80% — alert!"
   
Observability:
   "ทำไม latency p99 ตอน 14:30 พุ่ง?    (p99 = ค่าที่ 99% ของ request เร็วกว่านี้ — วัดประสบการณ์ของ worst-case user)
    → query 1 endpoint จาก 1 user agent + 1 country
    → ดู trace → DB query บนสาขา code ที่ใช้แค่ ใน feature flag X
    → feature ใหม่ที่เปิดกับ 5% users มีปัญหา"

→ Monitoring = subset ของ Observability

2. ทำไม Observability สำคัญในยุคนี้

ระบบสมัยใหม่ ซับซ้อนกว่าเดิมหลายเท่า:

ยุค Monolith (เก่า):
- 1 app บน 1 server
- bug = ดู log → fix
- monitoring แบบเก่าก็พอ

ยุค Microservices + Cloud (ใหม่):
- 50+ services
- Auto-scaling pods มาแล้วก็ไป  (pod = container 1 หน่วยใน K8s, auto-scale = เพิ่ม/ลดอัตโนมัติ)
- Multiple regions  (หลายภูมิภาคของ cloud)
- Async + event-driven  (ทำงานแบบไม่รอตอบ ผ่าน event)
- Third-party dependency เยอะ  (ระบบของบริษัทอื่นที่เราเรียกใช้)
- ทุก request ผ่าน 10+ hops  (hop = จุดผ่าน — request ผ่าน service กี่ตัว)

→ bug เกิดที่ไหน? 
→ "ดู log" คงไม่พอ
→ ต้องมี observability ที่ correlate (เชื่อมโยง — โยง log/metric/trace ของ request เดียวเข้าด้วยกัน) ได้

3. 3 Pillars of Observability

→ ใช้ทั้ง 3 รวมกัน = ดู bug ได้ครอบคลุม

+ Pillar ที่ 4 (สมัยใหม่): Profiling

Continuous profiling — flame graph ของ CPU/memory
   (flame graph = กราฟรูปเปลวไฟ — แสดงว่า function ไหนกิน CPU/memory มากสุด อ่านจากล่างขึ้นบน)
- "function ไหนใช้ CPU มากสุด?"
- "memory leak ที่ไหน?"

Tools: Pyroscope (ไพ-โร-สโคป), Parca (พาร์-ก้า), Grafana Cloud Profiling (กราฟ-ฟา-น่า)

4. ลำดับการ Debug ใน Production

เวลาเกิดปัญหาใน production ควรไล่ debug แบบ "top-down" — เริ่มจาก metric (มองภาพรวมว่าผิดปกติตรงไหน) แล้วซูมเข้าไปดู log/trace เฉพาะช่วงนั้น สุดท้ายค่อยดู profile ถ้ายังไม่เจอ การไล่ตามลำดับนี้เร็วกว่ากระโดดเข้า log มั่ว ๆ ตั้งแต่แรก:

Issue เกิด → คุณทำอะไรก่อน?

1. ดู Dashboard (metric)
   - มี anomaly ไหม?
   - error rate เพิ่ม? latency พุ่ง?
   
2. ดู Logs (เฉพาะช่วงเวลานั้น)
   - มี error message อะไร?
   - pattern ที่แปลก?
   
3. ดู Traces (สำหรับ slow / error request)
   - request นี้ผ่าน service ไหนบ้าง?
   - span ไหนช้า?
   
4. ดู Profile (ถ้ายังหาไม่เจอ)
   - CPU spent ที่ function ไหน?
   - memory allocation pattern?

→ Top-down: metrics (zoom out) → logs/traces (zoom in)

5. Telemetry — ข้อมูลที่ต้องเก็บ

Telemetry คือข้อมูลทั้งหมดที่ระบบส่งออกมาให้เราเฝ้าดู — ไม่ได้มาจาก app อย่างเดียว แต่รวมถึง infrastructure (CPU/memory), user (RUM), และ external (synthetic monitoring) ทั้งหมดส่งไปรวมที่ platform กลางเพื่อ correlate กันได้:

จาก app:
- Log
- Metric
- Trace
- Profile

จาก infrastructure:
- CPU, memory, disk, network
- Container stats
- Network flow

จาก user:
- **Real User Monitoring (RUM)** — เก็บ telemetry จาก browser ของ user จริง (ใช้ Navigation Timing API + library อย่าง `web-vitals`) ต่างจาก synthetic monitoring ที่เป็น probe ยิงจาก server ภายนอก · RUM เห็น experience ของ user หลากหลายอุปกรณ์/เครือข่ายจริง แต่ noisier (มี noise = ข้อมูลรบกวนเยอะกว่า synthetic ที่ควบคุมได้)
- Page load, JS error
- User journey

จาก external:
- Synthetic monitoring (ping จากภายนอก)
- Status page
- Bug report

ทั้งหมดส่งไป central platform เพื่อ correlate

6. OpenTelemetry — Standard

OpenTelemetry (OTel) คือมาตรฐานกลางที่แก้ปัญหา vendor lock-in — เดิม logs/metrics/traces ใช้ format ต่างกันและผูกกับ vendor พอเปลี่ยน vendor ต้อง rewrite agent ใหม่ OTel ให้ spec + SDK + collector ชุดเดียวที่ export ไป backend ไหนก็ได้:

ก่อน OTel:
- Logs ใช้ format X
- Metrics ใช้ format Y
- Traces ใช้ format Z
- Vendor lock-in
- เปลี่ยน vendor = rewrite agent

OpenTelemetry (OTel) — ปี 2026 = de facto standard:
- 1 spec ครอบทั้ง logs/metrics/traces
- 1 agent (OTel Collector)
- 1 SDK ต่อภาษา
- Export ไปไหนก็ได้ (vendor-agnostic)

OTLP = OpenTelemetry Protocol: รูปแบบ/โปรโตคอลกลางที่ OTel ใช้ส่ง telemetry

→ Vendor-agnostic = เปลี่ยน backend ง่าย

7. Concept: High-Cardinality + Wide Events

"cardinality" คือจำนวนค่าที่ไม่ซ้ำกันของ field หนึ่ง — field ที่ค่าไม่ซ้ำเยอะมาก (user ID, request ID) ทำให้ metric ของ Prometheus ระเบิด แต่กลับเก็บใน log/trace ได้สบาย เข้าใจจุดนี้ช่วยให้เลือกว่าข้อมูลไหนควรเป็น metric label และไหนควรเป็น log:

Cardinality

Cardinality = number of unique value

Low cardinality (ค่าซ้ำกันเยอะ — เปรียบเหมือนคอลัมน์ "ชื่อจังหวัด" ในตาราง ~77 ค่า):
- HTTP method (GET, POST, PUT, ...) — ~5-10
- Status code (200, 404, 500, ...) — ~30
- Region (us-east, eu-west, ...) — ~5-10

High cardinality (ค่าไม่ค่อยซ้ำ — เปรียบเหมือน "เลขบัตรประชาชน" ~70M ค่า):
- User ID — millions
- Request ID — billions
- Trace ID — billions

Why It Matters

Metric (Prometheus):
- ทุก unique combination = 1 series
- เก็บ user_id เป็น label → millions series = explosion (จำนวน series ระเบิด)
- Prometheus จะ OOM

(OOM = Out Of Memory: หน่วยความจำเต็ม โปรเซสถูกระบบ kill)

Log / Trace:
- High cardinality OK (1 line per event)
- Search by user_id หรือ trace_id ได้

→ Metric: low cardinality tags → Log / Trace: capture high cardinality detail

8. Sampling

ไม่สามารถเก็บทุก telemetry ได้ใน scale → ต้อง sample:

Logs:    DEBUG = ปิดใน prod (ถ้าเปิดเฉพาะ class ก็ 100%), INFO = 100% หรือ tail-sample เมื่อ volume สูง
         WARN/ERROR = 100% เสมอ
Traces:  1-10% in production (head-based)
         + 100% สำหรับ error / slow trace (tail-based)
         ⚠️ ใช้ parent-based sampler ที่ทุก service เพื่อไม่ให้ trace ขาดข้าม service (ดูบท 3 §9)
Metrics: aggregate ที่ source → keep 100%

💡 หัวข้อนี้เกี่ยวกับ tracing — ถ้ายังไม่เข้าใจ trace/span ข้ามไปก่อนแล้วกลับมาอ่านหลังบทที่ 3

📖 head-based vs tail-based sampling (โผล่ครั้งแรกในเล่ม):
head-based = ตัดสินใจ sample ตอน request เริ่ม (ที่ "หัว" ของ trace) — เร็ว, decision local, แต่ยังไม่รู้ว่า trace นี้จะ error หรือ slow มั้ย ดังนั้นถ้าตั้ง 1% อาจพลาด error trace
tail-based = collector รอจนทุก span ของ trace มาครบก่อนตัดสินใจ (ที่ "หาง") — ช้ากว่า + ใช้ memory ที่ collector เยอะ แต่ keep error/slow trace ได้ครบ
Pattern ที่นิยมในปี 2026: head-based ที่ 1-10% + tail-based 100% สำหรับ error/slow (ผ่าน OTel Collector tail_sampling processor)

ทำไมต้อง sample?

Storage cost
Network bandwidth
Query performance

9. Cost ของ Observability

Common breakdown (สัดส่วนคร่าว ๆ — ไม่ใช่ universal):
- Logs:    largest portion (มัก dominate เพราะ verbose + retention)
- Metrics: รองลงมา (ขึ้นกับ cardinality)
- Traces:  ปานกลาง (sampling ช่วยลดได้มาก)
- Profiles: น้อยสุด

⚠️ เรื่องสัดส่วน "5-15% ของ infra": ตัวเลขนี้เป็นค่าประมาณที่เห็นใน blog/talk หลายแหล่ง แต่ในความเป็นจริง observability cost ของแต่ละบริษัทแตกต่างกันมาก — บางบริษัทที่ log verbose + retention ยาว observability cost อาจขึ้นถึง 30-40% ของ infra · บางบริษัทที่ disciplined sampling อาจอยู่ใต้ 3%
ต้องการ source — ตรวจครั้งสุดท้าย 2026-06 · ถ้าต้องใช้ตัวเลข defend งบ ใช้ benchmark ของบริษัทตัวเอง (ดู vendor invoice + ปริมาณ ingest จริง) ไม่ใช่ค่าจาก blog

ใช้เกินงบเพราะ:

Log verbose ทุก request body
Metric high cardinality
Trace 100% sampling
เก็บนาน (1 year vs 7 days)
Vendor: Datadog charge per host + custom metric

วิธีลด cost:

Self-host (Loki, Prometheus, Tempo) — ไม่ต้องจ่ายค่า license แต่ต้องลงทุนเวลา engineer ดูแลเอง

💰 OPEX vs CAPEX (จำสั้น ๆ): OPEX = ค่าใช้จ่ายรายเดือน (เช่น vendor fee, infra, engineer time) · CAPEX = ลงทุนครั้งเดียว (เช่น server ที่ซื้อ) · self-host = ลด vendor fee แต่เพิ่ม engineer time (OPEX)

Sampling
Drop noisy log/metric
Retention tier (hot 7 days, cold 90 days, archive 1 year)

ดูบท Cost ใน DevOps book

10. SRE Concepts ที่เกี่ยวข้อง

SLI — Service Level Indicator

"metric ที่บอกว่า service ดีไหม"

Examples:
- Availability:    (success / total) × 100
- Latency:         p95, p99 of request duration
- Error rate:      errors / total
- Throughput:      req / sec

SLO — Service Level Objective

"เป้าหมายของ SLI"

Examples:
- 99.9% uptime over rolling 30 days
- p95 latency < 200ms
- Error rate < 0.1%

SLA — Service Level Agreement

"สัญญากับ customer — ถ้าไม่ได้ตามนี้ refund / penalty"

SLA < SLO (เป้าภายในเข้มกว่าที่สัญญา)

Error Budget

"100% - SLO = พังได้แค่ไหน"

SLO = 99.9% → error budget = 0.1% = 43 นาที / เดือน

ถ้าใช้ budget หมดเร็ว → freeze feature, focus reliability
ถ้ายังเหลือ budget → ship เร็วได้

→ Data-driven decision: ship vs fix

(ดูบทที่ 6 รายละเอียด)

11. Observability Maturity Model

ทีมต่าง ๆ อยู่คนละระดับของ observability — ตั้งแต่แค่เช็ค up/down (level 1) ไปจนถึง proactive ด้วย ML/chaos engineering (= จงใจ inject failure ใน production เพื่อทดสอบความทนทาน เช่น kill pod, drop network — ตัวอย่างคลาสสิก Netflix Chaos Monkey) ที่ level 5 ส่วนใหญ่ปี 2026 อยู่ level 2-3:

Level 0: ไม่มี monitoring เลย
- แค่ดู error เมื่อ user complain
- ไม่มี dashboard, ไม่มี alert

Level 1: Basic Monitoring
- Up/Down check
- CPU/memory dashboard
- Email alert

Level 2: Structured Telemetry
- Structured logs (JSON)
- Application metrics (Prometheus)
- Centralized log

Level 3: Distributed Tracing
- OpenTelemetry instrumentation
- Trace cross-service
- Trace + log correlation (trace_id)

Level 4: SLO-driven
- Define SLI/SLO
- Error budget
- Alert on SLO burn (not raw metric)

Level 5: Proactive
- Continuous profiling
- Anomaly detection (ML)
- Chaos engineering
- Auto-remediation

→ ความรู้สึกจาก industry: ส่วนใหญ่อยู่ราว Level 2-3 · Top tier (Google, Netflix) = Level 5

⚠️ ตัวเลข snapshot ของ industry ไม่มี survey vendor-neutral ที่ confirm — ต้องการ source — ตรวจครั้งสุดท้าย 2026-06 · ถ้าต้องการตัวเลขจริง ดู CNCF Annual Survey (CNCF = ซี-เอ็น-ซี-เอฟ = Cloud Native Computing Foundation — มูลนิธิดูแลโปรเจกต์ open source เช่น K8s, Prometheus) ปีล่าสุด + Honeycomb State of Observability (รายงานประจำปีของบริษัท Honeycomb เรื่องสถานะ observability) ปีล่าสุด (แต่ definition ของ "level" ในแต่ละ survey ต่างกัน)

12. Anti-Patterns

observability ที่ทำผิดทางกลับสร้างปัญหามากกว่าช่วย — เก็บทุกอย่างจน cost ระเบิด, alert ทุกอย่างจนเกิด alert fatigue, หรือเพิ่ม metric label จน cardinality ระเบิด:

❌ "Log everything" (log ทุกอย่าง — ดูเหมือนปลอดภัยแต่จริง ๆ ทำลายระบบ)

log.info("Entering method " + methodName);
log.info("Variable x = " + x);
log.info("Iteration " + i);

→ 1 TB log/day → cost ระเบิด, signal-to-noise ตก (signal-to-noise = สัญญาณดี/เสียงรบกวน — ของมีค่าจมในกองขยะ ค้นยาก)

❌ "Alert everything" (เตือนทุกอย่าง — สุดท้ายไม่มีใครฟัง)

Alert: CPU > 50%      → fires 100x / day
Alert: Disk > 50%     → fires
Alert: Memory > 50%   → fires
...

→ Alert fatigue → important alert ถูก ignore

❌ "More metric = better" (metric ยิ่งเยอะยิ่งดี — ผิด)

metric_per_user_country_region_browser_device... = millions of series

→ Cardinality explosion → Prometheus crash

❌ "Dashboard for every team request"

50+ dashboard, nobody knows which one

→ Curate — keep 3-5 main dashboard, archive rest

❌ "Vanity metric" (เลขโชว์อวด — ดูเท่ห์แต่ไม่ได้บอกว่า user เจอปัญหาไหม)

"We have 5M log lines per day!"
"99.99999% uptime!"

→ Focus on outcome: did user experience problem?

13. Golden Signals (Google SRE)

📖 Golden Signals = สัญญาณทอง 4 อย่าง — metric พื้นฐานที่ทุก service ต้องมี ตาม Google SRE Book (golden = ทอง = สำคัญที่สุด)

4 metric ที่ทุก service ต้องมี:

1. Latency        — เวลาที่ใช้ตอบ
2. Traffic        — request / sec
3. Errors         — error rate
4. Saturation     — ใกล้ขีดจำกัดแค่ไหน (CPU, memory, connections)

→ Dashboard เริ่มจากนี้ก่อน — แล้วค่อยเพิ่ม specific

14. RED Method (Service)

RED = ชุด metric สำหรับ service ที่รับ request:

Rate — จำนวน request ต่อวินาที (request per second)
Errors — อัตรา error (error rate)
Duration — การกระจายของเวลาตอบสนอง (latency distribution)

Spring Boot endpoints (รายละเอียด PromQL ในบทที่ 2):
- http_server_requests_seconds_count → Rate
- http_server_requests_seconds_count{status=~"5.."} → Errors
- http_server_requests_seconds_bucket → Duration (histogram)

15. USE Method (Resource)

USE = ชุด metric สำหรับทรัพยากร (CPU, disk, network):

Utilization — % ที่ถูกใช้งาน/ไม่ว่าง (% busy)
Saturation — ความยาวคิวงานที่รออยู่ (queue length)
Errors — จำนวน error (error count)

CPU:
- Utilization: % busy
- Saturation: load average
- Errors: thermal events

Disk:
- Utilization: % full + I/O busy
- Saturation: I/O queue length
- Errors: I/O errors

→ RED + USE = ครอบคลุม service + resource

16. กฎทอง

"ถ้าไม่ measure → ไม่รู้ว่ามี problem"

Without observability: 
"Customer complain → check log → maybe find issue"

With observability:
"Alert fired → dashboard show spike → trace → root cause → fix"

"Telemetry ตั้งแต่ start ของ project"

Don't:
- Build feature → deploy → "อ่อ เราต้องการ log แล้ว"

Do:
- Build feature + log + metric + trace → deploy

→ Observability = built-in, ไม่ใช่ retrofit

"Production คือ source of truth" (แหล่งความจริงเดียว — เชื่อ prod เท่านั้น staging/CI ไม่นับ)

- Test pass ใน CI ไม่ได้แปลว่า production OK
- Staging รัน OK ไม่ได้แปลว่า prod OK
- Only prod telemetry tell you what's really happening

17. คำศัพท์ที่จะใช้ในเล่ม

คำ	ความหมาย
Telemetry	data ที่ระบบส่งออกมา (log, metric, trace)
Cardinality	จำนวน unique value ของ dimension
Sampling	เก็บแค่บางส่วน (เพื่อลด volume)
Aggregation	รวบรวม data หลายค่าเป็น 1 (sum, avg, p95)
Series	1 metric ที่มี unique label combo
Bucket	สำหรับ histogram — ช่วงของค่า
Quantile / Percentile	p95 = 95% ของ value น้อยกว่านี้
SLI / SLO / SLA	ดูข้างต้น
Error Budget	100% - SLO
MTTR	Mean Time To Recovery (เวลากู้คืน)
MTBF	Mean Time Between Failures
MTTD	Mean Time To Detect
MTTA	Mean Time To Acknowledge
Toil (อ่าน "ทอยล์")	manual repetitive work (งานซ้ำ ๆ ที่ทำมือ; SRE Book บอก toil = ศัตรู ต้อง automate)
Incident	service degraded (need response)
Postmortem	report หลัง incident
Runbook	step-by-step ตอบ incident
Burn rate	ความเร็วใช้ error budget
OTLP	OpenTelemetry Protocol — โปรโตคอลกลางที่ OTel ใช้ส่ง telemetry (บท 0/3)
OOM	Out Of Memory — หน่วยความจำเต็ม โปรเซสถูก kill
MDC	Mapped Diagnostic Context — ที่เก็บ context ของ log ต่อ thread (บท 1)
PII	Personally Identifiable Information — ข้อมูลส่วนตัวที่ระบุตัวบุคคลได้ (บท 1)
SSN	Social Security Number — เลขประจำตัว (อเมริกา) เทียบได้กับเลขบัตร ปชช.
exemplar	จุดตัวอย่างใน metric ที่แนบ traceId ไว้ — คลิกแล้วกระโดดไป trace (บท 3)
RED	Rate / Errors / Duration — metric ของ service (บท 0/2)
USE	Utilization / Saturation / Errors — metric ของ resource (บท 0/2)
flapping	สถานะที่กระพริบ ขึ้น-ลง-ขึ้น-ลง เร็ว ๆ ทำให้ alert เด้งซ้ำ (บท 2/5)
mltp	ชื่อ repo สาธิตของ Grafana (`intro-to-mltp` — Metrics / Logs / Traces / Profiles) ไม่ใช่ industry term · อ้างเฉพาะใน Checkpoint 0.3

18. Tool Landscape ปี 2026

5 ตัวที่ basic ควรรู้ก่อน (เลือก 1 ตัวพอเริ่ม)

🧭 ไม่รู้จะเริ่มตัวไหน? ใช้ AWS อยู่แล้ว → CloudWatch · อยู่ K8s → Grafana Stack · ยังไม่มี cloud / startup เล็ก → New Relic free tier · งบไม่จำกัด อยากเร็ว → Datadog

Tool	จุดเด่น	ราคา
Grafana Stack (Loki + Mimir + Tempo + Grafana)	open source, self-host, vendor-neutral	free (+ infra cost)
Datadog	all-in-one, setup เร็วสุด	$$$ (price-per-host + per-GB-log + per-million-custom-metric — ดู datadoghq.com/pricing)
New Relic	free tier ใหญ่ (100GB/month)	free → paid
AWS CloudWatch	มาในตัวถ้าอยู่ AWS, integrate ดีกับ AWS service	per-metric / per-log GB
OpenTelemetry Collector + Cloud backend	standard, vendor-agnostic	depends on backend

คำแนะนำ: basic ที่ deploy บน cloud ลอง CloudWatch / New Relic free tier ก่อน → ถ้าจริงจัง ย้ายมา Grafana Stack (self-host) หรือ Datadog (managed)

ตัวเลือกอื่น (appendix — รู้ไว้พอ ไม่ต้องลงทุนเวลาเรียน)

ตัวเดิมที่เหลือ list ไว้เฉย ๆ ให้รู้ว่ามี:

All-in-one (paid): Splunk Observability, Honeycomb (high-cardinality first), Dynatrace (AI-driven)
Open Source Stack: ELK Stack (Elasticsearch + Logstash + Kibana), Prometheus + Jaeger (Tempo replace ดีกว่า)
Cloud Native: GCP Cloud Operations (Stackdriver), Azure Monitor
Specialized: Sentry (error tracking + RUM), PostHog (product analytics + observability), Vector (log/metric pipeline แทน Logstash)
eBPF-based observability (emerging ปี 2026): Pixie, Grafana Beyla, Coroot, Cilium Tetragon, Inspektor Gadget — auto-instrument ที่ kernel level โดยไม่ต้องแก้ app code

19. Roadmap ของ Observability

ถ้าเริ่มจากศูนย์ ควรสร้าง observability เป็นลำดับ ไม่ใช่ทำทุกอย่างพร้อมกัน:

Week 1-2: Foundation

Structured logging
Centralized log (Loki / ELK)
Search log

Week 3-4: Metrics

Prometheus / Datadog metrics
Build basic dashboard (golden signals)
Setup CPU/memory/disk alerts

Week 5-6: Tracing

OpenTelemetry instrumentation
Trace ใน 1 service
Trace cross-service

Month 2-3: SLO + Alerting

Define SLO
SLO-based alert (burn rate)
Runbook ของ alert
Postmortem process

Month 4+: Optimize

Cost optimization
Cardinality cleanup
Profile-driven optimization
Chaos engineering

20. Sample — End-to-End ของ 1 Request

ลองตามดู 1 request จริงตั้งแต่ user คลิกจนได้ผล — แต่ละ hop สร้าง log, เพิ่ม metric, และต่อ trace span โดยมี request_id/trace_id ร้อยเชื่อมทั้งหมดเข้าด้วยกัน:

1. User คลิกปุ่ม
   → React app generate request_id = "req-abc123"
   → Header: X-Request-ID: req-abc123

2. Request hit API Gateway
   → Log: "GET /api/orders req-abc123"
   → Metric: gateway_request_count++   // เพิ่ม counter 1
   → Trace: span "gateway"
   → Forward to backend with trace context   // ส่ง trace context ไป backend ด้วย

3. Backend service receive
   → MDC.put("requestId", "req-abc123")   ← MDC = Mapped Diagnostic Context: ที่เก็บ context ของ log ต่อ thread (ดูบท 1)
   → Log: "Processing GET /orders for user 42"
   → Metric: http_requests_total++
   → Trace: span "order-service" (child of gateway span)

4. Backend → Database
   → Trace: span "db.query" (child)
   → SQL: SELECT * FROM orders WHERE user_id = 42
   → Metric: db_query_duration_seconds histogram

5. Response
   → Backend log: "Returning 5 orders for user 42, took 35ms"
   → Gateway log: "Request req-abc123 completed: 200, 50ms"

ใน Grafana:
- Loki query: {requestId="req-abc123"} → see all log
- Tempo: trace_id=abc123 → see all spans
- Mimir: aggregate metric

→ Correlate ทั้ง 3 pillars ผ่าน trace_id

21. Common Misconceptions

❌ "We have monitoring → we're observable" (มี monitoring แล้ว = observable แล้ว — ผิด)

Monitoring ≠ observability. Observability = ตอบคำถามใหม่ได้

❌ "More data = better visibility" (ข้อมูลยิ่งเยอะยิ่งเห็นชัด — ผิด)

More noise = harder to find signal. ต้อง curate

❌ "Vendor handle everything" (ซื้อ vendor แล้วจบ — ผิด)

Vendor ให้ tool — แต่ instrument app, define SLO, write runbook = งานของทีม

❌ "Tracing is for microservices only" (tracing ใช้กับ microservices เท่านั้น — ผิด)

Even monolith get benefit — ดู span ของ slow function

❌ "Self-host is cheap" (self-host = ถูก — ผิด)

Free software + engineering time = อาจแพงกว่า SaaS

22. Checkpoint

🛠️ Checkpoint 0.1 — Audit Current State
สำหรับ app ของคุณ:

มี logging ไหม? structured?
มี metric ไหม? อะไรบ้าง?
มี trace ไหม?
มี dashboard ไหม?
มี alert ไหม? เคย fire?
มี runbook ไหม?

ให้คะแนน Level 1-5

🛠️ Checkpoint 0.2 — Define Golden Signals
สำหรับ 1 service ของคุณ:

Latency: target?
Traffic: peak / avg?
Errors: acceptable rate?
Saturation: ใกล้เต็มที่ resource ไหน?

🛠️ Checkpoint 0.3 — Setup Local Stack

📋 ต้องมีก่อน: ✅ Docker + docker compose (ยังไม่มี ดู Docker บท 0) · ✅ Git สำหรับ clone repo
💻 Resource ขั้นต่ำ: stack intro-to-mltp รัน 10+ containers — แนะนำ RAM 12-16 GB (8 GB อาจไม่พอเมื่อรัน Tempo+Loki+Mimir+Pyroscope+Grafana+Prometheus+Vector+demo app พร้อมกัน), disk ว่าง ~20 GB, Docker Desktop 4.x ขึ้นไป
💡 mltp = ชื่อ repo สาธิตของ Grafana (Metrics / Logs / Traces / Profiles ในชุดเดียว — มี profile เพิ่มจาก 3 pillars ดั้งเดิม) — ไม่ใช่ industry term ใช้เฉพาะใน demo นี้

bash

git clone https://github.com/grafana/intro-to-mltp
cd intro-to-mltp
docker compose up

เปิด Grafana → explore demo data

✅ เมื่อสำเร็จคุณควรเห็น: เปิด http://localhost:3000 → ควรเห็น Grafana login page (admin/admin) → ใน Dashboards เห็น demo dashboard ที่มี metric/log/trace จาก demo app (รอ ~2-5 นาทีหลัง docker compose up ให้ container start ครบ)
🛠 Troubleshooting:
รัน 5 นาทีแล้วยังไม่ขึ้น → docker compose logs <container> ดู error
port 3000 ชน → ปิด Grafana อื่นก่อน หรือแก้ port mapping ใน docker-compose.yml
container restart loop → check RAM ที่ Docker Desktop จัดให้ (Settings → Resources)

🛠️ Checkpoint 0.4 — Read Real Postmortem
อ่าน:

Cloudflare incident report
GitHub status incidents
AWS Post-Event Summaries

เขียน "อะไรที่ดี" + "อะไรที่ไม่ดี" ใน communication

23. สรุปบท

✅ Observability ≠ Monitoring — observability = ตอบคำถามใหม่ได้ ในระบบ complex
✅ 3 Pillars: Logs (อะไรเกิดขึ้น — what), Metrics (มากแค่ไหน — how much), Traces (ผ่านที่ไหน — where) + Profile
✅ OpenTelemetry = standard ปี 2026 — vendor-agnostic
✅ High cardinality OK ใน log / trace, ไม่ OK ใน metric
✅ Golden Signals + RED (service) + USE (resource) = baseline metric
✅ SLI / SLO / Error Budget = data-driven reliability
✅ Maturity model 1-5 — start at 1, work up
✅ Anti-patterns: log everything, alert everything, high-cardinality metric
✅ Tool: Grafana stack (free) vs Datadog (paid, easy)
✅ Cost ของ observability อาจกินสัดส่วนใหญ่ของ infra (ตัวเลขจริงต่างกันตาม discipline) — ลดด้วย sampling + retention tier
✅ Observability เป็น built-in, ไม่ใช่ retrofit

บทถัดไป → Logging ลึก

Glossary: ../glossary.md · Style guide: ../CONTRIBUTING.md last_verified: 2026-06-03 · review report: ../REVIEW-2026-06-03.md

บทที่ 0 — Observability Mindset ​

เลือกเส้นทางอ่านตามระดับและบริบท ​

1. Monitoring vs Observability ​

2. ทำไม Observability สำคัญในยุคนี้ ​

3. 3 Pillars of Observability ​

+ Pillar ที่ 4 (สมัยใหม่): Profiling ​

4. ลำดับการ Debug ใน Production ​

5. Telemetry — ข้อมูลที่ต้องเก็บ ​

6. OpenTelemetry — Standard ​

7. Concept: High-Cardinality + Wide Events ​

Cardinality ​

Why It Matters ​

8. Sampling ​

9. Cost ของ Observability ​

ใช้เกินงบเพราะ: ​

วิธีลด cost: ​

10. SRE Concepts ที่เกี่ยวข้อง ​

SLI — Service Level Indicator ​

SLO — Service Level Objective ​

SLA — Service Level Agreement ​

Error Budget ​

11. Observability Maturity Model ​

12. Anti-Patterns ​

❌ "Log everything" (log ทุกอย่าง — ดูเหมือนปลอดภัยแต่จริง ๆ ทำลายระบบ) ​

❌ "Alert everything" (เตือนทุกอย่าง — สุดท้ายไม่มีใครฟัง) ​

❌ "More metric = better" (metric ยิ่งเยอะยิ่งดี — ผิด) ​

❌ "Dashboard for every team request" ​

❌ "Vanity metric" (เลขโชว์อวด — ดูเท่ห์แต่ไม่ได้บอกว่า user เจอปัญหาไหม) ​

13. Golden Signals (Google SRE) ​

14. RED Method (Service) ​

15. USE Method (Resource) ​

16. กฎทอง ​

"ถ้าไม่ measure → ไม่รู้ว่ามี problem" ​

"Telemetry ตั้งแต่ start ของ project" ​

"Production คือ source of truth" (แหล่งความจริงเดียว — เชื่อ prod เท่านั้น staging/CI ไม่นับ) ​

17. คำศัพท์ที่จะใช้ในเล่ม ​

18. Tool Landscape ปี 2026 ​

5 ตัวที่ basic ควรรู้ก่อน (เลือก 1 ตัวพอเริ่ม) ​

ตัวเลือกอื่น (appendix — รู้ไว้พอ ไม่ต้องลงทุนเวลาเรียน) ​

19. Roadmap ของ Observability ​

Week 1-2: Foundation ​

Week 3-4: Metrics ​

Week 5-6: Tracing ​

Month 2-3: SLO + Alerting ​

Month 4+: Optimize ​

20. Sample — End-to-End ของ 1 Request ​

21. Common Misconceptions ​

❌ "We have monitoring → we're observable" (มี monitoring แล้ว = observable แล้ว — ผิด) ​

❌ "More data = better visibility" (ข้อมูลยิ่งเยอะยิ่งเห็นชัด — ผิด) ​

❌ "Vendor handle everything" (ซื้อ vendor แล้วจบ — ผิด) ​

❌ "Tracing is for microservices only" (tracing ใช้กับ microservices เท่านั้น — ผิด) ​

❌ "Self-host is cheap" (self-host = ถูก — ผิด) ​

22. Checkpoint ​

23. สรุปบท ​